Android container in Chrome OS

I can&#x27;t wait for the day that phone operating systems development environments are a docker pull away. It&#x27;s encouraging to see Google approaching my ideal workflow using containerisation. Apple systems are great until you run into the garden walls and are forced to use closed-source single platform software like Xcode. Chrome OS and Android are a lot more open in many respects.<p>Hopefully efforts like this continue with Fuchsia and other Google products.

Better is ChromeOS 67 enables running your own containers without having to put CB in developer.<p>It uses the KVM to run a second Linux kernel. So you will be able to use GNU&#x2F;Linux applications including Steam. More to be shared at Google IO this year.

I just had a vision of all major OS projects providing developer containers for their projects. Like, you could just pull the latest Firefox dev container and run a single command to have a running debuggable app.<p>I know one of the major pains we have when on-boarding new people is the whole dance to get to that first working build &#x2F; first meaningful change. I can imagine this being significantly more simple if a working dev environment was shipped as a container.

By looking at the comments this article is creating confusion. So I thought I might provide an overview of the two things happening with ChromeOS.<p>1) Android apps have been enabled on many Chromebooks using a locked container that shares a Linux kernel with ChromeOS. You do NOT have access to the container mechanism that is being used. It ONLY supports a container locked by Google. It is NOT using Docker also.<p>This is available on both ARM and X86 Chromebooks and most recent models are now supported. It took a while.<p>All Android apps run in a single container.<p>2) Starting with ChromeOS 67 and only on Pixel books so far there is full GNU&#x2F;Linux capabilities on a Chromebook without having to put the Chromebook in developer mode.<p>Developer mode is how you turn off much of the security of a Chromebook and keeping in this state is a bit of a hassle as when you boot you MUST remember not to hit the wrong keys and wipe your CB.<p>What Google has done is enable the KVM on the Chromebook ChromeOS Linux kernel. So you can run a second Linux kernel where you have full control of the second Linux kernel.<p>Then on top of this VM Google is pushing the use of containers. So these containers are completely separate from the Android containers.<p>Then all the containers on the VM share a common Linux kernel that is separate from the Android and ChromeOS kernel.<p>What this does is keeps the highly secure aspect of ChromeOS while giving you full GNU&#x2F;Linux on the machine.<p>Google has also enabled forward GUI of the GNU&#x2F;Linux VM to the ChromeOS desktop.<p>So say you start XClock on the VM the window will open up on the ChromeOS desktop.<p>What is also confusing to people is GNU&#x2F;Linux has been available on Chromebooks for a long time. There has been a number of ways to use.<p>1) Put CB into developer, install Crouton and you have GNU&#x2F;Linux. But to use Docker you MUST use rkt to start the containers.<p>2) Install the Android GNURoot app. This gives you GNU&#x2F;Linux but in a fake chroot that breaks many things. You can also use the Android XSDL app for the GUI. Since Google implemented ALL Android apps in a common container the IP is the same for both GNURoot and the XSDL app.<p>In ChromeOS 67 Google has fixed the IPs used by the Android container and now using the NAT reserved IPs instead of private IPs. This solves a weird bug you would run into where you had a IP conflict if you used the same private IPs elsewhere.<p>Google is also using the NAT reserved IPs with the new GNU&#x2F;Linux support through a VM.<p>It looks like Google will be packaging GNU&#x2F;Linux applications like Android Studio in containers that you can then run on a Chromebook with just a click. But will they be in the play store is unclear. But these containers will run on the VM.<p>Google will have ChromeOS 67 hitting stable at the same time as Google IO where they are rumored to explain things better. All of this new GNU&#x2F;Linux support with a VM is in beta.

I&#x27;d really like this to evolve into a standard thing in our linux distros. By which I mean apt-get&#x27;able, which it looks very close to.<p>I have no interest in the play store but I would like my lineageos&#x2F;fdroid userspace available directly to my desktop.

I wonder how hard it would be to get this working on, say, Fedora...<p>At the very least, one would need to replace what sounds like a surfaceflinger &lt;-&gt; wayland proxy.

What about Binder? Do Chrome OS kernels come with Binder built in, or are they emulating it on top of another IPC mechanism?<p>Edit: yes, Chrome OS kernels come with the binder driver enabled.

Does anyone have a link to what Chromebooks will support ChromeOS 67? Is there a matrix somewhere?

This is incredible. Using this, going from Linux to Zirkon is just a Kernel-switch away. Potentially they could replace small parts of the Linux-parts of Chrome OS slowly and iteratively with Fuchsia.

I have an ARM64 React Native toolchain sitting on blocks for ChromeOS. Caret is the IDE for this but Android SDK is truly lacking for ARM the build tools are base level. There is a guide floating around out there to make your own too. Looking forward to more stuff like this because essentially you get realtime Native app development with this but hooking into the debugger via crosh terminal is hard. Smoothing out the rough edges on this and then wow! You will have a powerhouse. NativeScript? Even better in theory.

Interesting to see Chrome OS adopt process compartmentalization techniques such as this, specifically adopting `cgroups&#x27;. Afaik, cgroups isn&#x27;t enabled by default and requires customizing the kernel before you can enable it. At the very least, container tools such as Docker require symlinks too to invoke chroot-like filesystem isolation and this is also not available.<p>It&#x27;ll interesting to see where they&#x27;ll go with this, specifically since Google also work on Kubernetes and that new OS, Fuchsia.

Thanks for publishing. Very informative. Am just setting up NeverWare as a devenv for Android. With localhost ADB connections. Could prove a powerful platform for Android automation.<p>Also noticed there is a web &quot;demo&quot; of Fuschia experimental OS. That can be run in a single Chrome tab (click &quot;guest&quot;):<p><a href="https:&#x2F;&#x2F;mgoulao.github.io&#x2F;fuchsia-web-demo&#x2F;" rel="nofollow">https:&#x2F;&#x2F;mgoulao.github.io&#x2F;fuchsia-web-demo&#x2F;</a>

The recently announced Droplet containers extend on this idea with a supposedly commercial-ready multiplatform solution<p><a href="https:&#x2F;&#x2F;dropletcomputing.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;dropletcomputing.com&#x2F;</a>

You can use gnu&#x2F;Linux on Android with a CB. But you have to use a fake Chroot. Just go to play store and install GNUroot.<p>Then install the Android XSDL app for the GUI.

Theoretically, this container should be able to run in any host os supporting containers.<p>I&#x27;d like to be able to run native (via container) android apps on my desktop OS

When the hell are we going to get electron and node.js apps on chromeos. Those are far more important than these crappy blown up phone apps

Android need a kernel feature called binder which afaik is not part of vanilla kernels &#x2F; distro kernels.

Does this open the path to running android apps on gnu&#x2F;linux desktop?