(no title)
lfy_google | 5 years ago
So this is basically the simulator situation, but with easier management of which libraries the guest userspace can dlopen and files to read()/write().
It's much like current Android-on-ChromeOS capabilities where containers are used to isolate where the "guest" userspace libraries are stored, so that it's not necessary to interop well with things like the host version of libc for example.
However, the problems come when considering the interface to the host kernel and hardware. Here are just two of the showstoppers:
1. Android expects to run on a particular range of kernel versions and configs each release. Fidelity is sacrificed to run with a wide range of Linux host kernel configurations. It's also easy for components on the host system such as SELinux to interfere with guest operation (and Android itself expects to use its own version of SELinux...so which one wins in the end?).
2. Further customization in the guest userspace needs to be made to account for needing to interop with a regular Linux system; e.g., input/network/display will be much more code that touches various parts of guest userspace and potentially hurts fidelity versus the VM abstraction where they are fake hardware and no customization of guest userspace is needed.
There are also isolation issues that involve more delicate dances, such as how to prevent runaway resource usage in the container from hogging the whole system (VMs merely waste the #vcpus + RAM dedicated to them; while that can be a lot compared to the host, it's explicitly controllable).
These problems sound less serious on the surface versus porting the Android framework directly to the host OS, but in the end it's basically the same level of essential complexity; containers just let you remove the incidental complexity of guest userspace libraries leaking into your /usr/lib and interop w/ your filesyste.
And once we try to run on non-Linux systems we're back at square one needing to port all userspace code to the host OS (Unless you're running Docker on macOS/Windows in which case you'd be creating a VM again, sacrificing all the benefits of containers versus VMs while keeping the complex customizations).
This is probably why Microsoft is pushing WSL2, ChromeOS skipped Android 10 support and is looking into ARCVM, and anbox is still running Android 7.1.1 (w/ plans to update but skipping releases in the meantime).
No comments yet.