Waydroid – Android in a Linux container
waydro.id
waydro.id
It's unfortunate that there are no Google-vended images (e.g. the generic system image) that run on Waydroid. Typing my password into random ROMs from the internet sketches me out.
Over a number of years, Google have progressively removed many of the original parts of AOSP (the FOSS foundation upon which Android is based), which means that alternative components have to be developed by projects like LineageOS. In spite of this, I suspect that LineageOS makes fewer modifications to AOSP than most phone vendors do, including Google themselves!
/? Android play store APK GitHub actions
It looks like Android Emulator has the most current version of Android that will run on x86?
Because that is the purpose of 'bonded and insured'.
I haven't looked at every EULA and license of every piece of software I use, but I bet that "without warranty" clauses are part of every single one of them.
You’re sidestepping their point of professionalism and attempting to shove in something else.
They are saying they want a verified authority, not "the community".
[1]: https://utcc.utoronto.ca/~cks/space/blog/linux/Ubuntu2404Bpf...
If I get Ubuntu or Debian or download the mainline kernel, I'm trusting specific entities. That's very different from a vague idea that it's open source and hopefully someone checked if this particular random guy on github is putting out legitimate builds.
"You can view the source on GitHub" is very different than "A knowledgable person has audited the millions of lines of source code and confirmed that nobody added anything shady or stupid." People often don't take the time to comprehend all the source of the things they depend on, especially for large dependencies and/or prototyping-scale projects.
Outside of open source, it was a NYT excuse for the NYPD failing to save Kitty Genovese. The number of witnesses was greatly exaggerated, and the police were called at least once.
I don't think you mean to refer to the bystander effect, because the bystander effect says that the likelihood of intervention goes down as the number of bystanders goes up. You don't seem to be arguing that people are less likely to look at the source because the source is available to more people. More just claiming that people don't look at the source as often as you would like? That open source isn't always perfectly bug and backdoor free? Because I don't know if:
> "A knowledgable person has audited the millions of lines of source code and confirmed that nobody added anything shady or stupid."
Has been claimed about many large pieces of software, proprietary or not.
1. Fully automated and reproducible builds, bootstrapped through a verifiable chain. GNU Guix has done this: https://guix.gnu.org/en/blog/2023/the-full-source-bootstrap-...
2. Unapologetically, ruthlessly, and tirelessly simplify the software. Suckless.org is a bit on the extreme end, but I continue to be impressed by OpenBSD - it strikes a beautiful balance between clarity and function. They've also meticulously combed the entire source tree around 2010, looking for any signs of the supposed FBI backdoor.
It takes a lot of motivation to do either, let alone both. The financial incentives are elsewhere. But it's been (and being) done.
You can for sure like whatever homegrown community Linux distro you want. It doesn't remove the work those players have done. :)
Whatever track record these companies might have had, doesn't justify their current stance or actions. Hans Reiser also made a pretty darn good filesystem - before he murdered his wife.
The "you can just read the code" mindset is completely unrealistic, even for software that's orders of magnitudes smaller. If the issue at hand is entering my Google password, I'd rather do it in a ROM built by Google.
Community reputation is the current _de facto_ standard for consumer-facing software, even for stuff sold by big corporations. There's not much else to rely on.
sudo ip netns exec <netns> wireshark
To get the traffic routed right, the Wireguard option for mitmproxy is pretty useful in my experience. Not sure how well Waydroid + Android VPNs work together, though.
If root is not an option, injecting Frida into the APK will work (but that might break applications that verify signatures).
EDIT: Oh, look at this https://mitmproxy.org/posts/wireguard-mode/. TIL.
Ok, here’s a more typical question: I’ve heard your phone uses halium, what exactly is it? Some kind of hardware abstraction layer? Some people online appear to dislike it. (And googling unfortunately gives very few links that aren’t super technical.)
Halium/libhybris are basically layers that allow us to use Android hardware drivers with a GNU/Linux userspace. Some Android bits run inside a container to provide support for peripherals. This is kinda a stop gap solution since we're working on native implementations and replacements for much of this stuff.
Some people dislike it because it's not a "pure Linux phone". But the alternative would be to ship a device that can't even place calls or take pictures, so... I think it's a good middle ground that allows us to ship something useful today.
... Which phones would that be? Even the original pinephone exceeds an hour and has a pretty good collection of apps even without compatibility layers.
> "The only apps that won’t work are ones that require the full Google Play Store and all it’s requirements. This includes some banking apps"
Sigh. It looks like I'd have to carry two phones.
Banking and credit card apps are essential daily apps for me. I can't even log in to some of my accounts on a desktop browser without their phone app to authenticate, and quite often individual payments require phone app confirmation. Unfortunately I'm not in a position to switch accounts for a freer user experience.
Separately from finance, I also have to use the Google suite for my main job, and I've had to use Discord for another job. I guess those can run in a browser with reduced functionality, though. Not so for the banking/credit card apps, unfortunately.
This isn't a complaint about Waydroid or FLX1. I appreciate the work and creativity! I've long dreamed of owning (and building) a completely FLOSS phone, and seen how much work is involved. I owned two Nokia N900s back in the day.
But times have changed, and I wish and hope a way can be found to run the apps or protocols daily life seems to require now, on top of (or side by side with) a base FLOSS system.
There's a review from The Register that just came out: https://www.theregister.com/2025/02/03/furiphone_flx1/
I love it.
No DP Alt mode.
It's a little frustrating because "Convergence" options are exposed in the UI.
The Telegram and Matrix channels have been great for people sharing tips like this.
They are still installable, but not available in the app store. The company (Norstedts) went over to a subscription style (of course).
I use waydroid to have them on my desktop and I love it.
Organic Maps has a desktop linux version but it's far from having feature parity.
Although it might change with this grant [1] aiming to build a nice desktop UI for Organic Maps.
The other useful feature for me is using the Android apps for media subscriptions that only enable offline downloads in the app and not in the browser so I can use them on the go.
If not, it's just a Linux container, so with some udev rules you should be able to make it work regardless.
It also seems that expected arm support on device is increasing (along with expected throughput) and that the capability of the x86 host device you need to emulate even a modest modern mobile ARM soc is getting higher and higher.
Lastly, the android version supported is almost always 3-4 generations behind the current Android. Apps are quick to drop legacy android support or run with fewer features/less optimizations on older versions of the OS. The android base version in this project is from 2020.
Anecdotally, using bluestacks (which indisputably has the most compatible and optimized emulation stack in the entire space) with a 7800X3D / RTX 3090 still runs most games slower than a snapdragon 8 phone from yesteryear running natively.
virtio-gpu-rutabaga: https://www.qemu.org/docs/master/system/devices/virtio-gpu.h...
Rutabaga Virtual Graphics Interface: https://crosvm.dev/book/appendix/rutabaga_gfx.html
gfxstream: https://android.googlesource.com/platform/hardware/google/gf...
"Gfxstream Merged Into Mesa For Vulkan Virtualization" (2024-09) https://www.phoronix.com/news/Mesa-Gfxstream-Merged
I don't understand why there is not an official x86 container / ROM for Android development? Do CI builds of Android apps not run tests with recent versions of Android? How do CI builds of APKs run GUI tests without an Android container?
For apps that use Vulkan natively, it's easy - but many still use and rely on OpenGL ES. It's a weird scenario where you have apps that are now supporting Vulkan, but they have higher minimum OS requirements as a result... but those versions of Android aren't supported by these type of projects.
It also liked to trigger kernel panics for me on Ubuntu 22.04, but that could be a weird hardware issue.
I guess I'm still grokking software complexity, Linux, and how much work an OS is truly is, 25 years after I built my first Linux box...because in another sense, of course that could happen.
A binder transaction behaves sort of like a syscall, in the sense that a client process can immediately, synchronously transfer control to a server thread, rather than just enqueueing a message to be processed whenever the server gets around to it.
This enables Android to separate many of its components into different processes (at different privilege levels), and use binder for RPCs that are on the "critical path" for user interaction, without incurring impractical amounts of overhead or latency.
https://en.wikipedia.org/wiki/OpenBinder
It's more like a micro services framework that abstracts threads and processes.
Fuchsia takes the approach to the conclusion and powers the entire OS through a similar system:
I think the hardest part of the whole setup was setting the screen resolution to something the ig app would run under (it wouldn't run in landscape mode) and getting ssh/scp running to move files from the computer to the vm.
[0] for professional reasons. Link in profile if you're interested. My insta posting had been greatly reduced since I'm still not convinced that anyone has truly found a way to redeem imaginary internet points for dollars. At least not at my level of effort I'm willing to put into accumulating imaginary internet points.
> We removed the Android pre-built images because Android does not run well on QEMU/UTM and created a lot of confusion. Advanced users can build their own Android VM from scratch but it is not recommended.
[0] - https://learn.microsoft.com/en-us/windows/android/wsa/ [1] - https://github.com/LSPosed/MagiskOnWSALocal
- (pro) It run on a laptop/desktop so it's performance will be a lot better
- (con) If the app has any native code inside it, it will need to support x86_64 or you'll need to have an ARM laptop
- (con) Like many in the thread mentioned, some apps will require Google features to even start.
- (con) I'm not sure if Waydroid will report secure boot features to the apps that require it.
So I'd expect CPU performance to be very similar if not basically identical.
GPU performance would be the bigger question, and the emulator has put a lot of work in that direction. Is this better or worse than that would be the biggest difference performance-wise.
Quite a big difference.
(One might say "but it's the same OS!" - but it's only really a similar kernel, and even that is heavily customized and not at all the same as your laptop runs. The graphical stack is also nothing like neither X nor Wayland.)
Also, rant: it's not KVM, but QEMU. KVM is a small API to deal with virtualization instructions, but while that makes VMs much faster than without (similar to how floating point is much faster with hardware support), it does very little on its own. The virtualization instructions are basically a way to let QEMU run code as is but intercept everything important - syscalls, faults, you name it - whereas without, it would have to instrument or outright interpret the executed program.
It's QEMU that micro-manages setup, execution and importantly is responsible for emulating all the VM devices - KVM just exposes memory mapped into the virtual CPU's memory space.
False equivalence. WINE reimplements windows libraries and higher level APIs to convert to Linux-native ASAP.
Waydroid/containers operate at a kernel level. The entire userspace is "virtualized".
> One might say "but it's the same OS!" - but it's only really a similar kernel, and even that is heavily customized and not at all the same as your laptop runs.
Exactly my point. The only difference is whether or not the kernel is shared, which is a very, very small fraction of the OS.
Waydroid reimplements Android libraries and higher level APIs to convert them to something compatible with your host kernel, providing as full a glue Android user-space as need to support Android user-space applications integrating into your host system (such as by providing a Wayland-backed implementation of SurfaceFlinger or HWComposer). This includes a full, Android-centric emulated filesystem hieararchy.
They are equivalent, even if their targets are different. And most importantly, they are both the polar opposite of a VM setup, as the user-space is not the user-space of the VM, but a dedicated user-space that presents Windows and Android behaviors respecitvely, but implementing them in terms of your host system's window management, input management, audio management, etc.
(That waydroid relies heavily on namespaces is a technical detail, not a relevant difference between WINE and Waydroid. WINE if implemented again today would likely do the same.)
> Exactly my point. The only difference is whether or not the kernel is shared, which is a very, very small fraction of the OS.
No, the main difference is whether the user-space is deeply integrated through various glue, or whether you're emulating the whole system as-is, with its original user-space and kernel, with just a virtual screen to interact with.
This is simply incorrect, though, negating the entirety of the rest of your argument.
> No, the main difference is whether the user-space is deeply integrated through various glue, or whether you're emulating the whole system as-is
Okay, sure, but then again waydroid and a VM are kissing cousins going off of that definition anyway. Both emulate the whole system. The only difference is whether or not the kernel is replaced.
> That waydroid relies heavily on namespaces is a technical detail, not a relevant difference between WINE and Waydroid. WINE if implemented again today would likely do the same.
No, it wouldn't. WINE does the approach it does to avoid redistribution of any Microsoft binaries. Simply containerizing & emulating the kernel API would be useless for WINE as a result
https://github.com/1999AZZAR/use-waydroid-on-x11
If you try it please let me know how it went.