Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

NewPipe on Linux, Using Android_translation_layer

flathub.org

Post reply on HN
Print view View original

61–70 of 100 posts

Re: NewPipe on Linux, Using Android_translation_layer

#61

Post by pantalaimon »

yjftsjthsd-h wrote: post #2

I feel like the interesting part is mostly https://gitlab.com/android_translation_layer/android_transla... which is probably an alternative to waydroid, but maybe more like WINE so it doesn't need the binder kernel module? EDIT to add: I also think packaging up an application plus the compatibility layer using flatpak[0] is a really nice idea; it lets you 1. make those apps available in a way that nearly appears nati…

What’s wrong with binder?

The problem with Waydroid is that you need to boot up a whole Android system, which is not great for app startup time.

Re: NewPipe on Linux, Using Android_translation_layer

#62

Post by cyberax »

yjftsjthsd-h wrote: post #52
deaddodo wrote: post #50

Earlier quoted context omitted.

> At this point, an x86 Android image will be better and more reliable. Somewhat just as fast. I'm pretty sure the overhead for something like Windows Subsystem Android is a few percentage points max, assuming the video card supports the proper OpenGL subsystem (so doesn't require software fallbacks). In fact, given that most x86 laptop CPUs and GPUs offer much more performance than most phone ARM chips, it's basical…

> I'm still waiting for the day Linux offers something similar. Waiting? Waydroid is several years old at this point, and you've always been able to run Android in a VM via either Google's official device emulator in the SDK or just running https://www.android-x86.org/ et al. in whatever hypervisor you prefer.

Android-x86 is dead. The last commits are from years ago.

Waydroid is slightly more alive, but only barely. And it itself is a fork of now defunct Anbox.

Re: NewPipe on Linux, Using Android_translation_layer

#63

Post by squarefoot »

abnry wrote: post #39
squarefoot wrote: post #36

Earlier quoted context omitted.

> Never heard of Freetube, but it looks pretty snazzy. I've used it for several months now and am very happy with it. I'ts a Electron app, however, so don't expect it to be small; I hope they will consider rebuilding it using Tauri, which would reduce its size drastically.

I know a lot of people hate on the recommendations homepage on YouTube, but I discover a lot of content I like watching there. However, I can't watch all of it and what to save what I see there and otherwise find and search for in a playlist, but the watch later playlist is not user friendly. Does Freetube improve playlist management too? That would be a big plus.

I never used the playlist on FreeTube, but just gave it a look and the use seems straightforward to me. It probably depends a lot on user needs, anyway operations look lightning fast compared to the "original".

Re: NewPipe on Linux, Using Android_translation_layer

#64

Post by master-lincoln »

anthk wrote: post #16
ravenstine wrote: post #6

Earlier quoted context omitted.

Perhaps because one is accustomed to the NewPipe experience and would prefer consistency across devices? Never heard of Freetube, but it looks pretty snazzy.

Parabolic it's far better for desktop users.

That seems to be a tools for downloading youtube videos, but the others presented here were for browsing it and watching videos as well

Re: NewPipe on Linux, Using Android_translation_layer

#65

Post by adamddev1 »

throwaway81523 wrote: post #22
sureglymop wrote: post #17

This is amazing! Have been using Newpipe for years because of its ability to group subscribed channels into different feeds.

On the desktop, youtube in the browser is tolerable with ublock origin, so I use it in preference to youtube because of the ability to show search results most recent first. Newpipe (maybe due to technical obstacles, idk) doesn't do that and it makes things harder.

Ya that's always been a frustration of mine with Newpipe. I wish you could sort search results by date.

Re: NewPipe on Linux, Using Android_translation_layer

#66

Post by pjmlp »

sigh_again wrote: post #11
yjftsjthsd-h wrote: post #2

I feel like the interesting part is mostly https://gitlab.com/android_translation_layer/android_transla... which is probably an alternative to waydroid, but maybe more like WINE so it doesn't need the binder kernel module? EDIT to add: I also think packaging up an application plus the compatibility layer using flatpak[0] is a really nice idea; it lets you 1. make those apps available in a way that nearly appears nati…

Trying to reimplement Android without Binder is a doomed plan. Everything about Android is so intrinsically linked to having Binder available that you're just going to end up piling hacks on hacks to have anything working. At this point, an x86 Android image will be better and more reliable. Somewhat just as fast. Services ? Binder. Intents (even internal ones) ? Binder. Play Services / microG which 90% of apps use ?…

Drivers? Binder. App extensions? Binder.

Re: NewPipe on Linux, Using Android_translation_layer

#67

Post by phh »

sigh_again wrote: post #60
phh wrote: post #38

Earlier quoted context omitted.

I disagree. Apps barely use Binder directly, but mostly call framework jar (which yes will do binder, but since they are reimplementing framework jar that's fine). Intents and permissions can be implemented without binder as the API is quite semantic. It may happen that the app uses Binder for same-app IPC, but since app does ser-des itself, you can easily replace Android.os.binder by whatever IPC you want, The only…

So, as I said, hacks on top of hacks on top of hacks :D If you're going to shim and reimplement, piece by piece some APIs like Binder... Just use Binder, that is already upstreamed in the kernel for so long.

You're confusing shiming with rewriting.

DirectX uses direct hardware access. DirectX uses direct hardware access. That doesn't mean you can't rewrite a DirectX-API implementation without direct hardware access. Likewise, Android's original implementation of MediaCodec uses binder. That doesn't mean that a reimplementation of MediaCodec API requires binder. The vast majority of Android public APIs do not assume binder. The only exception is Service binding, and even then, it's an assumption in name: It assumes that android.os.Binder will provide you an IPC. Most usages of android.os.Binder will be local to an app, so you can easily replace it with any IPC. Even the usage towards multiple app (whose only real usage would be Play Services) doesn't actually require binder. The requirement on that part is just the ""stable"" ser-des.

As an app developer, you (should) never connect directly to /dev/binder, because its API/ABI isn't stable. (it changed like 3 times in the last 6 years?)

Re: NewPipe on Linux, Using Android_translation_layer

#68

Post by stuaxo »

sigh_again wrote: post #11
yjftsjthsd-h wrote: post #2

I feel like the interesting part is mostly https://gitlab.com/android_translation_layer/android_transla... which is probably an alternative to waydroid, but maybe more like WINE so it doesn't need the binder kernel module? EDIT to add: I also think packaging up an application plus the compatibility layer using flatpak[0] is a really nice idea; it lets you 1. make those apps available in a way that nearly appears nati…

Trying to reimplement Android without Binder is a doomed plan. Everything about Android is so intrinsically linked to having Binder available that you're just going to end up piling hacks on hacks to have anything working. At this point, an x86 Android image will be better and more reliable. Somewhat just as fast. Services ? Binder. Intents (even internal ones) ? Binder. Play Services / microG which 90% of apps use ?…

I always have trouble with AnBox and Waydroid - when it comes to Binder.

It seems like there were changes made to Binder between the version in Linux mainline and the one in Android.

Until that is properly synched up then using something else will be easier.

Re: NewPipe on Linux, Using Android_translation_layer

#70

Post by kaba0 »

OsrsNeedsf2P wrote: post #45
irunmyownemail wrote: post #42

Earlier quoted context omitted.

I don't use flatpak, snap or appimage so it's good that it doesn't need flatpak or similar.

Can I ask why? A few years ago we stopped distributing on Linux outside of Flatpak. It was tiring getting bug reports that were only reproducible on certain drivers and setups, not to mention the weekly "how do I install this on ". We've seen people complain about the extra space it takes on disk, but after deduplication and compression the tradeoff to have Linux apps "just work" is worth it (imo)

Not the parent commenter, but I feel it mixes sandboxing and a non-ideal packaging method together.

Something like nix solves the second problem so much more elegantly.

Post reply on HN