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.

See https://gitlab.com/android_translation_layer/android_transla...

Services ? Binder. Intents (even internal ones) ? Binder. Play Services / microG which 90% of apps use ? Binder. Permissions ? Binder.

You mean a full VM?

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)

A new strategy is used that is much faster: https://www.phoronix.com/news/Syscall-User-Dispatch-Queued

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?)

https://learn.microsoft.com/en-us/cpp/intrinsics/fastfail?vi...

[1]: https://aur.archlinux.org/packages/binder_linux-dkms

1. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

2. https://packages.debian.org/search?suite=buster&arch=any&mod...

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?)

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.

But I feel I don't know much about binder/kernel/IPC: maybe I overestimate what that means?

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.

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.

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

I'm still waiting for Linux to offer a good version of that. I currently use waydroid, and it's barely functional.

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.

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)

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 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.

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.

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

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

https://github.com/Cloudef/android2gnulinux

https://gitlab.com/android_translation_layer/android_transla...

I wonder how well this approach works over anbox/waydroid's approach.

Oddly enough the video itself looks fine when playing, but not the browser interface.

Never heard of Freetube, but it looks pretty snazzy.

Having said that, newpipe is not only a youtube client but also a soundcloud, bandcamp and a few others too.

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.

https://github.com/FreeTubeApp/FreeTube

$ 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!

https://aur.archlinux.org/packages/android_translation_layer...

https://flathub.org/apps/io.mrarm.mcpelauncher

[0] https://appimage.org/

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.

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.

Pity, I love Newpipe on my phone.

https://github.com/darlinghq/darling

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.

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/