Came across this very useful project. It provides Docker images with Android running directly in Docker, without qemu or an emulator. I've never seen this before, all other solutions that I'm aware of either run the Android emulator in Docker or use qemu directly (like Anbox).
Advantage of this is that it's very lightweight and does not require VT-X or AMD-V, ideal for running in cloud environments that typically do not expose this CPU capability.
Anbox doesn't use QEMU. It uses the same underlying kernel tech as Docker, LXC and other isolation tech. This is why you need the ashmem and "binder"(?) kernel modules to run Anbox.
I'm currently "trying" to get Anbox working on NixOS (It's currently broken on 5.x kernels but should be fixed by https://github.com/NixOS/nixpkgs/pull/102341) so that's why I know that Anbox is the "same" as this.
Consider taking a moment to look into the difference between "emulator" and "virtual machine".
What the link refers to is an kind of Android emulator, but not the virtual machine kind of emulator.
If you are tempted to write a rebuttal in the "reply" box, answer this question first: Why are programs like xterm and urxvt called "Terminal Emulator"? What do they emulate?
Does it not provide the mobile-like environment that apps expect?
I mean, cgroups, firewall rules, and chroot are also already provided by the kernel, but using them for running containers without Docker, or Podman, or LXD, or other piece of "fluff" is slightly unergonomic.
Interesting concept but seems to require custom android-specific kernel modules (ashmem, binderfs), which means the android containers aren't very containerized but leak into the host kernel.
The Anbox project relies on the exact same 2 modules: https://docs.anbox.io/userguide/install_kernel_modules.html. While these are "android-specific", they are present in the linux kernel tree, and even come pre-installed in Ubuntu 19.04 (and probably more distros).
The Docker container also needs to be run in privileged mode, so you should probably treat this as if it were an emulator running root. It does work around dependencies on VT-x and such, though, and cuts down on the performance overhead of virtualising an extra kernel.
This is interesting, but I don’t see this as something for use in development of Android apps. Given all Android’s quarks and fragmentation the use of real devices and Google’s emulators will provide a better surface to catch bugs during dev. What’s the primary use case for these containerized versions of Android?
It's just a parameter to let the Android OS know that it's running in an emulated environment as opposed to running natively on a physical device.
For example, the GPU stack has to be somehow emulated using a custom OpenGL driver (in this case `mesa3d`). There's software emulation (swiftshader) and host GPU mode (GLES).
For performance reasons when using the host GPU, the GLES commands from the guest have to be serialized and sent over a kernel pipe to the QEMU and to the host OS. The commands are deserialized on the host and executed on the physical host GPU through the Shader Translator library (taken from the Google ANGLE project). The Google's QEMU fork (aka Android Emulator) usually loads this library and then takes care of proper rendering, such that users can see the rendering output of the emulated OS properly inside the emulator window on the host machine. You can do the same for the docker, otherwise you'd have to implement some other trick to share the GPU. `virtio-gpu` is a Linux kernel facility that is meant to replace QEMU pipe in the future.
Yeah not reading anywhere in the docs that it works without qemu. Also the need for kennel modules to be available on the host and passed through makes it less portable than most containers.
How is this accomplished? Is this using Anbox or something similar
I don't understand how the Dockerfiles linked here end up running an instance of Android.
For development work I use the default Android emulator that comes with Android Studio.
Are any of these ones superior in terms of performance, resource utilization, etc? The cloud angle is mildly interesting although in my specific use-case I'd probably just end up paying for a service that can provide access to emulators in the cloud.
Is there more scope to do things like automating inputs etc this way? How would one go about that?
This one specifically seems to run Android in the Linux Kernel using the usual suspects of container tech. It should have next to zero performance impact so it will definitely have better performance compared to the default Android emulator considering that's using qemu, even if it's qemu-kvm.
Whether it's as reliable as running a VM, is something that'll need to be tested. Personally I got an error when trying to exit out of the shell (and thus was unable to exit), something I've never seen in the VM version of Android.
Trying to fix some Rust docker builds that are being killed by QEMU on Apple Silicon right now. I always believed Docker was cross platform, I had no idea how much of a pain it can be to use with buildx and --platform to get stuff working. SIGSEGV errors at random points, non-deterministic errors, GAH!
That you (and many others apparently) had the impression that docker was cross platform says a lot about docker's markering, considering docker as far as I know it is a wrapper for a series of extremely linux-kernel-specific APIs. :-/
Frankly I just install Island, and then run Whatsapp (and all not-always-needed apps) inside it. Plus bonus: you can freeze the apps you don't need and keep the island running.
Because alternatives have some requirements that may not suite some people.
1. VMs have relatively big resources overhead and this approach requires you to download some Android image first.
Of course you'd want some clean distribution and there simply aren't many such ones (that I know of) that are easily available. The ones I tried - were a 2-in-1 shitshow+slideshow for me. Maybe it's because I used ISO (for QEMU/KVM), as I didn't want to run proprietary crapware (VirtualBox/VMWare).
2. Going with Anbox requires having crapware snapd and their Android image is quite old (Android 7.1.1).
3. Going with Waydroid requires having Wayland, which if you don't use it - is an overkill to install just to have Android on your PC.
4. Going with Android from AndroidSDK - is probably an even harder way to get access to some Android on your PC (I don't really know, I haven't investigated that option).
PascalW|4 years ago
Advantage of this is that it's very lightweight and does not require VT-X or AMD-V, ideal for running in cloud environments that typically do not expose this CPU capability.
OJFord|4 years ago
https://github.com/anbox/anbox (https://news.ycombinator.com/item?id=24684187)
https://github.com/waydroid/waydroid (https://news.ycombinator.com/item?id=28616985)
lillecarl|4 years ago
I'm currently "trying" to get Anbox working on NixOS (It's currently broken on 5.x kernels but should be fixed by https://github.com/NixOS/nixpkgs/pull/102341) so that's why I know that Anbox is the "same" as this.
blueflow|4 years ago
What the link refers to is an kind of Android emulator, but not the virtual machine kind of emulator.
If you are tempted to write a rebuttal in the "reply" box, answer this question first: Why are programs like xterm and urxvt called "Terminal Emulator"? What do they emulate?
pengaru|4 years ago
Isn't the enabling technology here just kernel-level android bits? Docker is fluff, yet ends up dominating the headline.
nine_k|4 years ago
I mean, cgroups, firewall rules, and chroot are also already provided by the kernel, but using them for running containers without Docker, or Podman, or LXD, or other piece of "fluff" is slightly unergonomic.
0x0|4 years ago
captn3m0|4 years ago
The Anbox project relies on the exact same 2 modules: https://docs.anbox.io/userguide/install_kernel_modules.html. While these are "android-specific", they are present in the linux kernel tree, and even come pre-installed in Ubuntu 19.04 (and probably more distros).
jeroenhd|4 years ago
2OEH8eoCRo0|4 years ago
marcodiego|4 years ago
cranx|4 years ago
PascalW|4 years ago
[1] https://docs.mau.fi/bridges/go/whatsapp/android-vm-setup.htm...
paulcarroty|4 years ago
wwwhizz|4 years ago
testtesttestte|4 years ago
For example, the GPU stack has to be somehow emulated using a custom OpenGL driver (in this case `mesa3d`). There's software emulation (swiftshader) and host GPU mode (GLES).
For performance reasons when using the host GPU, the GLES commands from the guest have to be serialized and sent over a kernel pipe to the QEMU and to the host OS. The commands are deserialized on the host and executed on the physical host GPU through the Shader Translator library (taken from the Google ANGLE project). The Google's QEMU fork (aka Android Emulator) usually loads this library and then takes care of proper rendering, such that users can see the rendering output of the emulated OS properly inside the emulator window on the host machine. You can do the same for the docker, otherwise you'd have to implement some other trick to share the GPU. `virtio-gpu` is a Linux kernel facility that is meant to replace QEMU pipe in the future.
The high-level details of this OpenGL emulation mechanism are described here: https://android.googlesource.com/platform/external/qemu/+/ma...
You can find the implementation of the QEMU OpenGL pipe mechanism here: https://cs.android.com/android/platform/superproject/+/maste...
tgtweak|4 years ago
drran|4 years ago
AkshitGarg|4 years ago
manojlds|4 years ago
jeroenhd|4 years ago
j4hdufd8|4 years ago
See instructions to build it (or pull the published version)
https://github.com/remote-android/redroid-doc/tree/master/an...
Then you can run the Android container
domenukk|4 years ago
fareesh|4 years ago
Are any of these ones superior in terms of performance, resource utilization, etc? The cloud angle is mildly interesting although in my specific use-case I'd probably just end up paying for a service that can provide access to emulators in the cloud.
Is there more scope to do things like automating inputs etc this way? How would one go about that?
mkdirp|4 years ago
Whether it's as reliable as running a VM, is something that'll need to be tested. Personally I got an error when trying to exit out of the shell (and thus was unable to exit), something I've never seen in the VM version of Android.
j4hdufd8|4 years ago
adb or UIAutomator
exdsq|4 years ago
0x0|4 years ago
Tepix|4 years ago
yetanother-1|4 years ago
nik5|4 years ago
aunetx|4 years ago
j4hdufd8|4 years ago
goodpoint|4 years ago
junon|4 years ago
mathfailure|4 years ago
1. VMs have relatively big resources overhead and this approach requires you to download some Android image first.
Of course you'd want some clean distribution and there simply aren't many such ones (that I know of) that are easily available. The ones I tried - were a 2-in-1 shitshow+slideshow for me. Maybe it's because I used ISO (for QEMU/KVM), as I didn't want to run proprietary crapware (VirtualBox/VMWare).
2. Going with Anbox requires having crapware snapd and their Android image is quite old (Android 7.1.1).
3. Going with Waydroid requires having Wayland, which if you don't use it - is an overkill to install just to have Android on your PC.
4. Going with Android from AndroidSDK - is probably an even harder way to get access to some Android on your PC (I don't really know, I haven't investigated that option).