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 native, 2. lets you get users/testers on your compat layer easily, while 3. scoping it to a single app at a time to make it easier to do things like "well we've got this one app working, but how do we tell people that without them expecting other things to work that aren't implemented yet?". Excellent symbiosis:)
[0] Strictly speaking there shouldn't be anything requiring flatpak here... I think there's no technical blocker preventing you making a debian package for the ATL and another for NewPipe and sticking them in a repo/PPA that people could add. But I do somewhat feel that flatpak lends itself to this usecase.
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 ? Binder. Permissions ? Binder.
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 "real" issue I can see , and you're right there, is Play Services. I think that handling that case specifically later (once floss apps/apps that don't require play services work properly), is not too horrific (it basically needs to compile the aidl into not calling binder, but redirecting it to a custom lib)
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.
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?)
> Most usages of android.os.Binder will be local to an app, so you can easily replace it with any IPC.
I'd be absolutely shocked if that was even a little bit true. Android's binder & AIDL generated code will absolutely do in-process passthrough to avoid the syscall for local calls, but ~nobody is bothering with AIDL unless it's to enable IPC. So that local pass-through is almost certainly rarely if ever used except on "accident" when components nominally support being passed over IPC, but in some cases aren't. An example would be Android's Surface + SurfaceTexture. Normally you're using Surface over IPC either to the display or to media codec or from camera. But if you're using SurfaceTexture, then in that rare scenario it might be local to the process.
But that's definitely a lot less common than IPC binder + AIDL.
What'd be a lot harder is handling some of the more advanced graphics & multimedia features. Android's gralloc HAL in particular is likely borderline impossible to implement on Linux as it assumes tight integration between all of the camera, media/video, GPU, and display stacks, and also largely assumes it's on unified memory.
For most of Wine's life it was sufficient to implement the system library ABI, but recent developments mean they also have to trap the (unstable) syscall ABI with ptrace. You could mimic Binder in userspace the same way, without the kernel module. But even that's not a problem since Binder is upstream and enabled by default in many distro kernels now.
> Games avoiding the Windows API and performing system calls directly is an increasingly common occurrence by modern Windows games, seemingly in the name of Digital Rights Management schemes and similar protected modes.
Yuck. Windows system call numbers are not contractual. At all. Microsoft should try harder to kill any code outside ntdll.dll that makes a system call. It's obnoxious for a developer to deliberately use unstable interfaces and then demand indefinite compatibility.
Not infinite – long enough for the game to bring in most revenue is enough.
Who cares that it stops running one or two Windows updates later for totally avoidable reasons? Definitely not the publisher. (In fact, isn't it about time for an HD remaster again?)
Microsoft cares, though, because if a game stops working when you upgrade Windows, you blame the Windows upgrade, not Microsoft. So now Microsoft has to maintain these legacy system calls even though they never signed up to do that.
I'd call that a special ABI feature, not a stable system call. Note that it's a software interrupt, not a regular SYSENTER. But sure. Maybe I'm splitting hairs.
I don't think binder is upstream, nor is the default in many distros. AFAIK support is very limited as not a lot of people use it. In arch it is provided only as a community package (AUR) [1]. This was a major blocker for me when trying to install anbox or waydroid, custom compiled kernel modules is a no-no for me, not because of security issues (which could exist), but because they can break a lot of stuff and fixing kernel modules is not a stroll in the park.
It was moved from linux-staging to proper Linux in 2014 [1], and it's included with Debian oldoldstable, oldstable, and stable as well as Ubuntu linux-image packages, as a module binder_linux.ko; just need to modprobe binder.
I'm reasonably confident that it is upstream: https://github.com/torvalds/linux/blob/master/drivers/androi... looks like the most obvious bit, though there are other pieces. (And now I'm curious why waydroid is maintaining their own dkms code separate from that; perhaps it's to better target a range of kernel versions?) I will agree that it's not generally actually built/used by distros.
> 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 basically a moot point. The big problem is finding packages built universally or specifically for x86 (not sure what the status is for WSA on Windows ARM, but that could be an option too).
I'm still waiting for the day Linux offers something similar. Or FreeBSD does something similar to their Linux ABI compatibility.
Edit: looks like WSA is being ended in early 2025:
> 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.
No, merely using the standard Android emulator, as well as the x86_64 images that have been available for a while (or the ARM64 ones if you're on an M1 and others). With hardware acceleration properly setup, it's a nice experience. https://developer.android.com/studio/run/emulator-commandlin...
It does tend to be very unhappy when the system gets under load though, and might be sluggish if you're running a dozen IDEs on the side.
(Which, as comment under says, is technically a VM. But QEMU gets a pass at pretending not to be a VM and rather just black wizardry that makes bytes happy)
The project seems to be built on top of my android2gnulinux project from way back. Nice to see someone picking up the pieces and making it more functional.
I have been hoping for compatibility layer + application flatpaks for a while so it’s nice to see someone doing it. My dream is to have a bunch of flatpaks for the Microsoft office suite
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 <new distro here>".
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)
I dislike the way flatpak is effectively a second distro on top of whatever else I'm running; it eats a rather lot of additional disk space (and network bandwidth), requires that I run updates for it in addition to everything else, and I'm not sold on its security patching story (last I looked, it strongly favored everyone effectively vendoring most dependencies and I don't trust them to keep up with patches like my actual distro).
To be fair, there's also a list of reasons I do like it, just... both pros and cons.
> It was tiring getting bug reports that were only reproducible on certain drivers and setups
I'll give you userspace, but drivers should be like the one thing that flatpak doesn't help with? It's the same kernel, not a VM.
Not someone you asked, but I personally tend to avoid it because it makes my system less transparent to me.
Isolated self contained containers are cool for enterprise setting with huge fleets of machines, frequent updates, etc. But it's not optimal for desktop Linux atm because no one secured any of desktop APIs and there are no easy way to inspect WTF each container is doing and why. Is it ships outdated deps? Is there crypto miner in or its just random hung process eating 100% of one cpu core?
Basically each app in self contained container have its own universe and you will never figure out what exactly its doing. So its turn your system into a black box.
As maintainer of OSS software and game developer I totally get the appeal, but as user I love Linux exactly because it's give me more transparency and I dont want to lose it.
I have no idea if all flatpack apps update their own vulnerabilities once they are discovered. The distribution usually does it. Then I hate the idea of having boundaries between apps and imperfect integration with the desktop environment. Furthermore I don't really need any app distributed as flatpack so far, so I don't care. When I see one I only miss giving it a try but I don't miss using it to do my daily job. I could even said that flatpack is a good thing for me because it encapsulates all the possible distractions and makes them unreachable.
Anyway, I'd rather use flatpack than snap. I left Ubuntu for Debian because of it. I hope it goes the way of the other Canonical's unsuccessful attempts at building their own proprietary system and moat.
I read through the commenters who responded before I saw your question this morning and feel they all did a great job with their answers and agree with them.
I keep my Waydroid session running in the background, managed by a systemd user-level service. Works great, and if it increases resource usage I don't notice--this is on a converted Chromebook so pretty low specs.
If you have a device running postmarketOS or Alpine Linux you can try this out yourself with other Android apps. Just "sudo apk add android-translation-layer" and then run
$ android-translation-layer some-app.apk
I tried a few (F-Droid, Spotify, Megalodon) but they all failed with various issues, looks like there's a lot of API surface still not covered. Hopefully a lot of it is fairly easy to add now that the foundational work has been done!
> 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".
I have been enjoying the new version that just came out yesterday, they implemented a new video player and IMHO the user experience is much improved, if the UI glitches you mentioned were related to the player, maybe you could give it a try.
It was an actual question for the community as these kind of questions usually generate perspectives and alternatives. There’s no need to read anything else into it.
I have used FreeTube on wayland now for a long time without any issues. Electron still uses x11 as the default on wayland so you need to enable the wayland mode manually. You can easily do that by setting the ELECTRON_OZONE_PLATFORM_HINT=auto
environment variable.
Thanks, that fixed the resolution issue! I also had to give it access to the dbus system socket and wayland for it to work. Wasn't sure how to do that but the flatseal app made it easy.
They fixed a few bugs already I think. But it still looks like crap (lower resolution?) on my tablet and I have to force the onscreen keyboard on manually (normally comes on by itself).
Oddly enough the video itself looks fine when playing, but not the browser interface.
Very cool stuff! I wonder if you can switch out the newpipe app for the Tubular (https://github.com/polymorphicshade/Tubular) fork which has SponsorBlock and ReturnYoutubeDislike built into it.
Waydroid needs to run a full OS; this is just a single application; the first approach allows you to integrate well with other apps you might use. Though for ATL, when you open in a browser, it will open your actual desktop browse. Downloading will happen to your chosen folder on the desktop. It feels more like APKs for a desktop; like Google's "ARC Welder" without using the browser as the runtime.
I have finally been able to install it and have to say I am really impressed how well this works. Sure, you can not really 'fullscreen'? There are some glitches; margins. But mostly it just works. It is so much more efficient than starting up Waydroid... I am even considering trying this with some of my other go-to applications.
Note; FreeTube is also a good client. Though at three times the size due to Electron, I like NewPipe more. It feels way more snappy to use.
Running it on Fedora. You? (Also use it in Bazzite from a Legion Go; touch input only)
Graphics, like buttons are problematic (small, misplaced), but functional
Great news! I'm fiddling way too much with a Surface Go 2, and a translation layer for Android is perfect when all you have is a touchscreen, very little ram, an incredibly slow eMMC, and a battery that'll last 8 hours if you're lucky.
Especially because there aren't many Linux apps that are touch friendly. Everything kirigami/touch friendly apps in KDE is very much work in progress and are barely good enough for daily usage. Electron apps are no-go because they don't work with a virtual keyboard. Flutter apps are useless because they don't support high dpi on Linux. Gnome has bad support for fractional scaling, issues in some menus for touchscreens, and the space for fonts in the launcher doesn't scale making them display as "Firef..." on a high dpi. I am running Debian Bookworm by the way.
So I wasn't happy to see that android_translation_layer uses Gtk, but I think scaling is improved in Gtk4. Looking forward to try it out either way.
Mmmh, I'm using it on Android for some time now, installed as F-Droid app. Problem is, there is some friction regarding Countermeasures of YT and a new version adjusting to them. Often, I'm unable to use the alternative Client on Android for months until this is fixed. Will this be a problem on Linux too?
The problem is that F-Droid takes time to review new releases, when they're already available from other (direct) sources.
I have discovered Obtainium[1] not too long ago. Allows you to install and update apps from pretty much any source you want (e.g., directly from GitHub releases, as in NewPipe's case).
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.
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 native, 2. lets you get users/testers on your compat layer easily, while 3. scoping it to a single app at a time to make it easier to do things like "well we've got this one app working, but how do we tell people that without them expecting other things to work that aren't implemented yet?". Excellent symbiosis:)
[0] Strictly speaking there shouldn't be anything requiring flatpak here... I think there's no technical blocker preventing you making a debian package for the ATL and another for NewPipe and sticking them in a repo/PPA that people could add. But I do somewhat feel that flatpak lends itself to this usecase.
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 ? Binder. Permissions ? Binder.
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 "real" issue I can see , and you're right there, is Play Services. I think that handling that case specifically later (once floss apps/apps that don't require play services work properly), is not too horrific (it basically needs to compile the aidl into not calling binder, but redirecting it to a custom lib)
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?)
> Most usages of android.os.Binder will be local to an app, so you can easily replace it with any IPC.
I'd be absolutely shocked if that was even a little bit true. Android's binder & AIDL generated code will absolutely do in-process passthrough to avoid the syscall for local calls, but ~nobody is bothering with AIDL unless it's to enable IPC. So that local pass-through is almost certainly rarely if ever used except on "accident" when components nominally support being passed over IPC, but in some cases aren't. An example would be Android's Surface + SurfaceTexture. Normally you're using Surface over IPC either to the display or to media codec or from camera. But if you're using SurfaceTexture, then in that rare scenario it might be local to the process.
But that's definitely a lot less common than IPC binder + AIDL.
All that said, you could almost certainly make a Binder driver shim that just uses unix domain sockets. Heck, Android itself even has one: https://cs.android.com/android/platform/superproject/main/+/...
What'd be a lot harder is handling some of the more advanced graphics & multimedia features. Android's gralloc HAL in particular is likely borderline impossible to implement on Linux as it assumes tight integration between all of the camera, media/video, GPU, and display stacks, and also largely assumes it's on unified memory.
For most of Wine's life it was sufficient to implement the system library ABI, but recent developments mean they also have to trap the (unstable) syscall ABI with ptrace. You could mimic Binder in userspace the same way, without the kernel module. But even that's not a problem since Binder is upstream and enabled by default in many distro kernels now.
When did WINE start doing this? I always love a good read on ptrace hacks.
https://github.com/wine-staging/wine-staging/commit/595f2f98...
A new strategy is used that is much faster: https://www.phoronix.com/news/Syscall-User-Dispatch-Queued
> Games avoiding the Windows API and performing system calls directly is an increasingly common occurrence by modern Windows games, seemingly in the name of Digital Rights Management schemes and similar protected modes.
Yuck. Windows system call numbers are not contractual. At all. Microsoft should try harder to kill any code outside ntdll.dll that makes a system call. It's obnoxious for a developer to deliberately use unstable interfaces and then demand indefinite compatibility.
> demand indefinite compatibility.
Not infinite – long enough for the game to bring in most revenue is enough.
Who cares that it stops running one or two Windows updates later for totally avoidable reasons? Definitely not the publisher. (In fact, isn't it about time for an HD remaster again?)
Microsoft cares, though, because if a game stops working when you upgrade Windows, you blame the Windows upgrade, not Microsoft. So now Microsoft has to maintain these legacy system calls even though they never signed up to do that.
Microsoft does not. This is the one area where they don't compromise: system call numbers regularly change between Windows builds.
There is now at least one public windows kernel call listed on MSDN: __fastfail
https://learn.microsoft.com/en-us/cpp/intrinsics/fastfail?vi...
I'd call that a special ABI feature, not a stable system call. Note that it's a software interrupt, not a regular SYSENTER. But sure. Maybe I'm splitting hairs.
I don't think binder is upstream, nor is the default in many distros. AFAIK support is very limited as not a lot of people use it. In arch it is provided only as a community package (AUR) [1]. This was a major blocker for me when trying to install anbox or waydroid, custom compiled kernel modules is a no-no for me, not because of security issues (which could exist), but because they can break a lot of stuff and fixing kernel modules is not a stroll in the park.
[1]: https://aur.archlinux.org/packages/binder_linux-dkms
It was moved from linux-staging to proper Linux in 2014 [1], and it's included with Debian oldoldstable, oldstable, and stable as well as Ubuntu linux-image packages, as a module binder_linux.ko; just need to modprobe binder.
1. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
2. https://packages.debian.org/search?suite=buster&arch=any&mod...
It is upstream and Arch gives directions for enabling it in the standard kernel: https://wiki.archlinux.org/title/Waydroid#Building_a_kernel
I'm reasonably confident that it is upstream: https://github.com/torvalds/linux/blob/master/drivers/androi... looks like the most obvious bit, though there are other pieces. (And now I'm curious why waydroid is maintaining their own dkms code separate from that; perhaps it's to better target a range of kernel versions?) I will agree that it's not generally actually built/used by distros.
> 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 basically a moot point. The big problem is finding packages built universally or specifically for x86 (not sure what the status is for WSA on Windows ARM, but that could be an option too).
I'm still waiting for the day Linux offers something similar. Or FreeBSD does something similar to their Linux ABI compatibility.
Edit: looks like WSA is being ended in early 2025:
https://learn.microsoft.com/en-us/windows/android/wsa/
Due to not being able to integrate a store and make revenuue:
https://www.windowscentral.com/software-apps/windows-11/here...
What a shame.
> 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.
Sorry, I should have rephrased that:
I'm still waiting for Linux to offer a good version of that. I currently use waydroid, and it's barely functional.
Google launched the play store on Windows without wsa. I assume that's a big reason it collapsed.
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.
> At this point, an x86 Android image will be better and more reliable. Somewhat just as fast.
You mean a full VM?
No, merely using the standard Android emulator, as well as the x86_64 images that have been available for a while (or the ARM64 ones if you're on an M1 and others). With hardware acceleration properly setup, it's a nice experience. https://developer.android.com/studio/run/emulator-commandlin...
It does tend to be very unhappy when the system gets under load though, and might be sluggish if you're running a dozen IDEs on the side.
(Which, as comment under says, is technically a VM. But QEMU gets a pass at pretending not to be a VM and rather just black wizardry that makes bytes happy)
The Android Emulator is a full VM under the hood. Waydroid is a lighter-weight alternative that uses the Binder implementation in the Linux kernel.
Binder is upstreamed into Linux.
But I feel I don't know much about binder/kernel/IPC: maybe I overestimate what that means?
Binder is in mainline Linux, but I was under the impression that most distros aren't building it by default?
Plus, Linux itself should adopt binder. It's already upstream and actually pretty good.
Drivers? Binder. App extensions? Binder.
The project seems to be built on top of my android2gnulinux project from way back. Nice to see someone picking up the pieces and making it more functional.
https://github.com/Cloudef/android2gnulinux
I have been hoping for compatibility layer + application flatpaks for a while so it’s nice to see someone doing it. My dream is to have a bunch of flatpaks for the Microsoft office suite
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 <new distro here>".
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)
> Can I ask why?
I dislike the way flatpak is effectively a second distro on top of whatever else I'm running; it eats a rather lot of additional disk space (and network bandwidth), requires that I run updates for it in addition to everything else, and I'm not sold on its security patching story (last I looked, it strongly favored everyone effectively vendoring most dependencies and I don't trust them to keep up with patches like my actual distro).
To be fair, there's also a list of reasons I do like it, just... both pros and cons.
> It was tiring getting bug reports that were only reproducible on certain drivers and setups
I'll give you userspace, but drivers should be like the one thing that flatpak doesn't help with? It's the same kernel, not a VM.
Not someone you asked, but I personally tend to avoid it because it makes my system less transparent to me.
Isolated self contained containers are cool for enterprise setting with huge fleets of machines, frequent updates, etc. But it's not optimal for desktop Linux atm because no one secured any of desktop APIs and there are no easy way to inspect WTF each container is doing and why. Is it ships outdated deps? Is there crypto miner in or its just random hung process eating 100% of one cpu core?
Basically each app in self contained container have its own universe and you will never figure out what exactly its doing. So its turn your system into a black box.
As maintainer of OSS software and game developer I totally get the appeal, but as user I love Linux exactly because it's give me more transparency and I dont want to lose it.
I have no idea if all flatpack apps update their own vulnerabilities once they are discovered. The distribution usually does it. Then I hate the idea of having boundaries between apps and imperfect integration with the desktop environment. Furthermore I don't really need any app distributed as flatpack so far, so I don't care. When I see one I only miss giving it a try but I don't miss using it to do my daily job. I could even said that flatpack is a good thing for me because it encapsulates all the possible distractions and makes them unreachable.
Anyway, I'd rather use flatpack than snap. I left Ubuntu for Debian because of it. I hope it goes the way of the other Canonical's unsuccessful attempts at building their own proprietary system and moat.
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.
I read through the commenters who responded before I saw your question this morning and feel they all did a great job with their answers and agree with them.
It's conceptually similar to wine, but rather a reimplementation of the reference Android, which is AOSP.
See https://gitlab.com/android_translation_layer/android_transla...
Better link: https://gitlab.com/android_translation_layer/android_transla...
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.
I keep my Waydroid session running in the background, managed by a systemd user-level service. Works great, and if it increases resource usage I don't notice--this is on a converted Chromebook so pretty low specs.
Definitely. I'd never heard of this one before; I'd love to read a full comparison between the two.
If you have a device running postmarketOS or Alpine Linux you can try this out yourself with other Android apps. Just "sudo apk add android-translation-layer" and then run
$ android-translation-layer some-app.apk
I tried a few (F-Droid, Spotify, Megalodon) but they all failed with various issues, looks like there's a lot of API surface still not covered. Hopefully a lot of it is fairly easy to add now that the foundational work has been done!
I'm going to try and get android_translation_layer building on Arch and then we can have a third distro to add to the list!
It is done!
https://aur.archlinux.org/packages/android_translation_layer...
Why would one want NewPipe on desktop when there's https://freetubeapp.io/
Perhaps because one is accustomed to the NewPipe experience and would prefer consistency across devices?
Never heard of Freetube, but it looks pretty snazzy.
> 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".
I don't know, it makes sense that UI between desktop and mobile would be different. I use Freetube on desktop and newpipe on mobile.
Having said that, newpipe is not only a youtube client but also a soundcloud, bandcamp and a few others too.
I tried it, it didn't feel like what you get on android and had ui glitches
I have been enjoying the new version that just came out yesterday, they implemented a new video player and IMHO the user experience is much improved, if the UI glitches you mentioned were related to the player, maybe you could give it a try.
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
Freetube is terribly unoptimized. Even though it supports hw video playback, I decided to skip it as it had too much CPU overhead.
You know you could drop a recommendation without being so damn submissive of OP. Let a thousand alternative clients bloom.
It was an actual question for the community as these kind of questions usually generate perspectives and alternatives. There’s no need to read anything else into it.
Doesn’t work well on Wayland unfortunately. Don’t know if this one does but worth a shot.
I have used FreeTube on wayland now for a long time without any issues. Electron still uses x11 as the default on wayland so you need to enable the wayland mode manually. You can easily do that by setting the ELECTRON_OZONE_PLATFORM_HINT=auto environment variable.
Thanks, that fixed the resolution issue! I also had to give it access to the dbus system socket and wayland for it to work. Wasn't sure how to do that but the flatseal app made it easy.
I use Freetube on Wayland with 0 issues.
Same here.
They fixed a few bugs already I think. But it still looks like crap (lower resolution?) on my tablet and I have to force the onscreen keyboard on manually (normally comes on by itself).
Oddly enough the video itself looks fine when playing, but not the browser interface.
no "fast-foward through silence" feature
in one phrase "skip silences" feature!
Very cool stuff! I wonder if you can switch out the newpipe app for the Tubular (https://github.com/polymorphicshade/Tubular) fork which has SponsorBlock and ReturnYoutubeDislike built into it.
He can't but you probably can.
https://gitlab.com/android_translation_layer/android_transla...
https://gitlab.com/android_translation_layer/android_transla...
I wonder how well this approach works over anbox/waydroid's approach.
Waydroid needs to run a full OS; this is just a single application; the first approach allows you to integrate well with other apps you might use. Though for ATL, when you open in a browser, it will open your actual desktop browse. Downloading will happen to your chosen folder on the desktop. It feels more like APKs for a desktop; like Google's "ARC Welder" without using the browser as the runtime.
I have finally been able to install it and have to say I am really impressed how well this works. Sure, you can not really 'fullscreen'? There are some glitches; margins. But mostly it just works. It is so much more efficient than starting up Waydroid... I am even considering trying this with some of my other go-to applications.
Note; FreeTube is also a good client. Though at three times the size due to Electron, I like NewPipe more. It feels way more snappy to use.
I see tons of glitches: cant load settings, loading a vid may work or not, and the gui gets glitchy regardless.
Pity, I love Newpipe on my phone.
Running it on Fedora. You? (Also use it in Bazzite from a Legion Go; touch input only) Graphics, like buttons are problematic (small, misplaced), but functional
Great news! I'm fiddling way too much with a Surface Go 2, and a translation layer for Android is perfect when all you have is a touchscreen, very little ram, an incredibly slow eMMC, and a battery that'll last 8 hours if you're lucky.
Especially because there aren't many Linux apps that are touch friendly. Everything kirigami/touch friendly apps in KDE is very much work in progress and are barely good enough for daily usage. Electron apps are no-go because they don't work with a virtual keyboard. Flutter apps are useless because they don't support high dpi on Linux. Gnome has bad support for fractional scaling, issues in some menus for touchscreens, and the space for fonts in the launcher doesn't scale making them display as "Firef..." on a high dpi. I am running Debian Bookworm by the way.
So I wasn't happy to see that android_translation_layer uses Gtk, but I think scaling is improved in Gtk4. Looking forward to try it out either way.
Exciting. I'd love to see AppImage [0] builds of applications produced with this library.
[0] https://appimage.org/
for me freetube in the arch repo works great
https://github.com/FreeTubeApp/FreeTube
I think it is in the AUR not arch official repos
Mmmh, I'm using it on Android for some time now, installed as F-Droid app. Problem is, there is some friction regarding Countermeasures of YT and a new version adjusting to them. Often, I'm unable to use the alternative Client on Android for months until this is fixed. Will this be a problem on Linux too?
The problem is that F-Droid takes time to review new releases, when they're already available from other (direct) sources.
I have discovered Obtainium[1] not too long ago. Allows you to install and update apps from pretty much any source you want (e.g., directly from GitHub releases, as in NewPipe's case).
[1] https://obtainium.imranr.dev/
have a look at NewPipe's own fdroid repo: https://newpipe.net/FAQ/tutorials/install-add-fdroid-repo/
Thanks! Shows the same version as the installed app from the main F-Droid repository - but this one works.
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.
Semi related, there is a Minecraft Bedrock Launcher that ports the Minecraft for Android app to *nix.
https://flathub.org/apps/io.mrarm.mcpelauncher
On this topic, similar to Wine, there is also Darling which brings Darwin to Linux.
https://github.com/darlinghq/darling
I've wanted this for several years now solely for the "fast-forward through silences" feature that newpipe has.
3.6 GB installed! This is why I dislike Flatpak.
The page says "Installed Size ~60.95 MiB". Is that inaccurate?
That figure does not include the dependencies like org.freedesktop.Platform and org.gnome.Platform which can add up to GBs.
But they are shared between apps, and those platform packages are almost certainly used by most of your apps.
YESSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS!