4 ms·

I feel like the interesting part is mostly https://gitlab.com/android_translation_layer/android_translation_layer/ https://gitlab.com/android_translation_layer/

I feel like the interesting part is mostly https://gitlab.com/android_translation_layer/android_translation_layer/ 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.

bubblesnort 2y ago
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_translation_layer/-/blob/master/doc/Semantics.md https://gitlab.com/android_translation_layer/android_transla...
- NoahKAndrews 2y ago
  Better link: https://gitlab.com/android_translation_layer/android_translation_layer/-/blob/master/doc/Architecture.md https://gitlab.com/android_translation_layer/android_transla...
NoahKAndrews 2y ago
Definitely. I'd never heard of this one before; I'd love to read a full comparison between the two.
sigh_again 2y ago
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.
- yjftsjthsd-h 2y ago
  > At this point, an x86 Android image will be better and more reliable. Somewhat just as fast. You mean a full VM?
  - sigh_again 2y ago
    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-commandline 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)
    - NoahKAndrews 2y ago
      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.
- mappu 2y ago
  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.
charlieboardman 2y ago
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
irunmyownemail 2y ago
I don't use flatpak, snap or appimage so it's good that it doesn't need flatpak or similar.
- OsrsNeedsf2P 2y ago
  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)
  - SXX 2y ago
    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.
  - yjftsjthsd-h 2y ago
    > 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.
pantalaimon 2y ago
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.
- xelamonster 2y ago
  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.
Cloudef 2y ago
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 https://github.com/Cloudef/android2gnulinux

bubblesnort 2y ago

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_translation_layer/-/blob/master/doc/Semantics.md https://gitlab.com/android_translation_layer/android_transla...

NoahKAndrews 2y ago
Better link: https://gitlab.com/android_translation_layer/android_translation_layer/-/blob/master/doc/Architecture.md https://gitlab.com/android_translation_layer/android_transla...

NoahKAndrews 2y ago

Definitely. I'd never heard of this one before; I'd love to read a full comparison between the two.

sigh_again 2y ago

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.

yjftsjthsd-h 2y ago
> At this point, an x86 Android image will be better and more reliable. Somewhat just as fast. You mean a full VM?
- sigh_again 2y ago
  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-commandline 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)
  - NoahKAndrews 2y ago
    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.
mappu 2y ago
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.

charlieboardman 2y ago

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

irunmyownemail 2y ago

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

OsrsNeedsf2P 2y ago
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)
- SXX 2y ago
  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.
- yjftsjthsd-h 2y ago
  > 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.

pantalaimon 2y ago

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.

xelamonster 2y ago
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.

Cloudef 2y ago

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 https://github.com/Cloudef/android2gnulinux