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.
https://github.com/anbox/anbox (https://news.ycombinator.com/item?id=24684187)
https://github.com/waydroid/waydroid (https://news.ycombinator.com/item?id=28616985)
Anbox: Requires 'snapd'. The image is based on AOSP based on Android 7.1.1.
Waydroid: Requires Wayland. The image is based on LineageOS that is based on Android 10.
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.
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?
The issue here is context. What GP means by Android Emulator refers to specific piece of software, the AVD emulator provided by Google which emulates full android device, it emulates more than just VM, it's also have skins and physcal buttons.
Isn't the enabling technology here just kernel-level android bits? Docker is fluff, yet ends up dominating the headline.
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.
It's the Linux kernel, configured with the appropriate Android modules, not Docker making this happen.
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).
[1] https://docs.mau.fi/bridges/go/whatsapp/android-vm-setup.htm...
qemu=1
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...
From the ReDroid kernel modules readme:
>Custom Kernel
>If use custom kernel (5.0+), you can enable binderfs and ashmem configs; So the kernel modules in this repo are not needed any more.
https://github.com/remote-android/redroid-modules#custom-ker...
More info here on Android-specific kernel modules here:
https://elinux.org/Android_Kernel_Features#List_of_kernel_fe...
[1] ashmem
https://github.com/torvalds/linux/blob/master/drivers/stagin...
[2] hwbinder
https://github.com/torvalds/linux/tree/master/drivers/androi...
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
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?
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.
adb or UIAutomator
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).