> If you are trying to launch a random app, chances are that we are missing implementations for some stuff that it needs, and we also don't have (sufficiently real looking) stubs for the stuff it says it needs but doesn't really.
The workflow is basically to see where it fails (usually a Class or Method was not found) and to create stubs which sufficiently satisfy the app so that it continues trying to launch.
Once the app launches, you may find that some functionality (UI elements, ...) is missing. To enable such functionality, you need to convert the relevant stubs to actual implementation. You can look at simple widgets (e.g. TextView, or ImageView) to see how to implement a widget such that it shows up as a Gtk Widget.
I don't think the point of this is to get everything ever to work. Just getting well-behaved and free software apps to integrate better than with waydroid (by reimplementing a higher level of libraries, rather than running the entire OS) would already be huge.
These are usually simple heuristics based on device name, whether you're running a signed version of Android, etc. Thirty minutes on Stackoverflow will usually cover all the fingerprints most simple apps use.
If they're using Play Integrity, you're mostly out of luck. Xposed will usually have the latest bypass, but there's long periods where there aren't any.
It's not in a window, although you can launch it that way if you want. Each app is a separate window, mouse/keyboard/touch works just like with any other app, even the clipboard works as you'd expect.
I'm given to understand that it supports window-per-app? And I don't use it like that for reasons related to it requiring wayland, but even so it works fine for me with mouse+keyboard
this could be used in linux phones as well I suppose (waydroid requires linux-zen which just adds friction imo)
Though I like waydroid very much , I also really like this idea of having android apps as flatpak applications which I can install rather easily without having to configure to install a custom kernel and do 10 more different things (like maybe adding play store if app is not available) (a arm implementation if app isn't working)
lets hope that it works better than that and gives a plug n play experience
Yes, the implementation looks philosophically similar and seems to cleave at the same layer (the interface between app code and platform libraries). Basically, an implementation of everything Dalvik calls out to via JNI and a bionic <-> glibc libc shim for native Android libraries.
No, you’re right, ART now (I think they started using Dalvik, actually, but switched, just like Android itself). I guess I forgot what year it was for a minute there :)
From a quick look at the gitlab I don't see any mention of similar requirements. If that's the case, it would be easier to run. Also bonus if gpu support is better than "NVIDIA GPUs do not work currently"
But I thought the experience with waydroid is running an android system in a window? You can run android applications directly in Linux as their own "native" window using waydroid?
Discussion started here:
NewPipe on Linux, Using Android_translation_layer (27.10.2024)
https://news.ycombinator.com/item?id=41963932
Cool! But not exactly plug n play at this point:
> If you are trying to launch a random app, chances are that we are missing implementations for some stuff that it needs, and we also don't have (sufficiently real looking) stubs for the stuff it says it needs but doesn't really. The workflow is basically to see where it fails (usually a Class or Method was not found) and to create stubs which sufficiently satisfy the app so that it continues trying to launch. Once the app launches, you may find that some functionality (UI elements, ...) is missing. To enable such functionality, you need to convert the relevant stubs to actual implementation. You can look at simple widgets (e.g. TextView, or ImageView) to see how to implement a widget such that it shows up as a Gtk Widget.
Any easy way to make apps not recognize they're not running on an actual android phone?
I've read some apps that love to take too much control run CPU related checks amongst other things.
No android experience or usecase, just wonder how that works and how one would workaround that.
I don't think the point of this is to get everything ever to work. Just getting well-behaved and free software apps to integrate better than with waydroid (by reimplementing a higher level of libraries, rather than running the entire OS) would already be huge.
These are usually simple heuristics based on device name, whether you're running a signed version of Android, etc. Thirty minutes on Stackoverflow will usually cover all the fingerprints most simple apps use.
If they're using Play Integrity, you're mostly out of luck. Xposed will usually have the latest bypass, but there's long periods where there aren't any.
Was going to ask "how is this different from Anbox", but apparently Anbox got discontinued by its developer more than a year ago.
There is waydriod as a successor thou.
But waydroid is just an android system in a window. That's really not as useful as it could be, especially with a mouse and keyboard.
It's not in a window, although you can launch it that way if you want. Each app is a separate window, mouse/keyboard/touch works just like with any other app, even the clipboard works as you'd expect.
It is EXTREMELY useful (and built in/well integrated) on the FLX1. Could be interesting to see how handy ATL could be on mobile
I'm given to understand that it supports window-per-app? And I don't use it like that for reasons related to it requiring wayland, but even so it works fine for me with mouse+keyboard
this could be used in linux phones as well I suppose (waydroid requires linux-zen which just adds friction imo)
Though I like waydroid very much , I also really like this idea of having android apps as flatpak applications which I can install rather easily without having to configure to install a custom kernel and do 10 more different things (like maybe adding play store if app is not available) (a arm implementation if app isn't working)
lets hope that it works better than that and gives a plug n play experience
Waydroid does not require linux-zen. It requires a kernel with the binder kernel modules. They can be managed with dkms on a normal kernel.
...or just included in the "normal kernel", as binder is mainline.
Is this like Wine/Proton, but for Android instead of Windows/DirectX?
Yes, the implementation looks philosophically similar and seems to cleave at the same layer (the interface between app code and platform libraries). Basically, an implementation of everything Dalvik calls out to via JNI and a bionic <-> glibc libc shim for native Android libraries.
Wait, Dalvik? Not ART?
No, you’re right, ART now (I think they started using Dalvik, actually, but switched, just like Android itself). I guess I forgot what year it was for a minute there :)
It seems like it, at least based on the bit in the README about stubbing out and implementing classes & methods that apps need.
If Android binaries are for ARM and Linux runs on x86, you need another layer of translation from Arm to x86.
That's included in Android.
how is this different from waydriod?
waydroid requires a kernel module or a kernel with support built in like zen https://wiki.archlinux.org/title/Waydroid#Kernel_Modules
From a quick look at the gitlab I don't see any mention of similar requirements. If that's the case, it would be easier to run. Also bonus if gpu support is better than "NVIDIA GPUs do not work currently"
But I thought the experience with waydroid is running an android system in a window? You can run android applications directly in Linux as their own "native" window using waydroid?
native wayland windows maybe you're thinking? still, it has the requirements that it does (see the wiki link)
you still need to be on linux-zen kernel to make this work.
I use wayland but I am interested in atl as well
Great news for Pinephone users!
Wait; isn't Android a layer to run Android apps on Linux?
See, this is where it's useful to use terms like GNU/Linux for reasons other than free software advocacy.
Android apps run on a Linux kernel, but not on a GNU/Linux distribution.