Earlier this week, I shared information on what Chrome OS 100 brings to Chromebooks. Aside from new features, such as the improved Launcher, there’s a huge behind-the-scenes addition. The original three core principles of Speed, Simplicity, and Security in Chrome OS are now four. After more than a decade, Stability is a primary function of Chrome OS.
A more modular Chrome OS
Historically, this is big. Chrome OS has evolved so much since the first demo in 2009, that it’s now much more complex in how it works. I still
think it’s a simple user interface, however, Chrome OS is far more than “just a browser.” And under the hood, there are additional moving parts for Google to manage. More movement, as it were, can inject more instability.
Google obviously knows this because it’s the entity managing all of these moving parts. And it’s been working on improving this management.
Decoupling the Chrome browser from Chrome OS with Lacros is a good example. And that effort is near completion.
I still wouldn’t recommend you abandon the integrated Chrome OS browser for Lacros just yet, but it’s working well for me. And it already got my Chromebook patched from a severe potential exploit before most other devices.
A brief history lesson of Android on Chrome OS
Another example is the third iteration of how Android apps on Chromebooks are implemented.
Originally, Android apps were simply sandboxed through what Google called Native Client. It worked but required Android apps to be recompiled (remember ARC Welder?), so broad app availability was a challenge. That project ended in 2020 as Google introduced ARC++ in 2016.
ARC++ is how most Chromebooks today run Android apps: In a container.
This approach obviously works as well, and it doesn’t require any major modifications by Android developers. But, there’s a stability challenge as noted by Google:
With the container-based offering, we made Android work in conjunction with the host kernel, which may or may not be the same kernel version that the Android version we are shipping supports. This made the maintenance and quality guarantees of the kernel incredibly frustrating and required us to rebase a set of patches for each Chrome OS target that used a different host kernel version. It was also very difficult to scale to a wide range of devices and turned into a common source of bugs that required a large amount of effort to backport. Because of this, we had to be very conservative about upgrading Android, as the amount of effort required to upgrade each host kernel version required a superhuman effort.
How does ARCVM bring stability to Chrome OS?
Google learned much from implementing Linux on Chrome OS in a virtual machine (technically, a container inside a VM) and is now taking
the same a similar approach with Android.
How does this help Google in terms of stability? Let’s go to the source:
Now, we have control over the host, hypervisor, and guest kernel. This allows us to further optimize the behavior and performance of ARCVM, as the host and guest work in harmony to enable optimal performance characteristics and user experience for even the lowest-powered of devices.
Essentially, many of those complex “moving parts” I referenced earlier are under one umbrella as it were, where Google has a greater degree of control. And it adds more security as well.
Above, you can see the new architecture keeps Chrome separate from the Chrome OS kernel. It uses the Chrome OS VM (aka crosvm) to manage Android, its software, and kernel.
Not shown is Linux but it would be a container within the same crosvm area. Instead of separate, individual compartments for different functionality, they’re all grouped under one virtual machine that Google designed and built.
And that brings us back to stability. This architecture is less of a piecemeal effort that requires patches here and there that could affect other sub-systems.
This is a cohesive, modular approach that should bring stability benefits to Android, Linux, or whatever else arrives on Chrome OS in a future container. Like Steam, for example.
Put another way: This has such large implications for Chrome OS that Google turned its three pillars into four.
Think long term, not short term
Will you see any immediate impact when your Chromebook gets ARCVM?
Probably not although I’d expect more efficiency and less memory usage when using Android apps. You should also see fewer CPU cycles devoted to the Android subsystem upon boot up, but again, I doubt many would notice.
Ultimately, the benefits will come over time as this more cohesive approach rolls out and evolves. Android itself should be patched or updated more often and the Android app experience should improve and behave in a more stable fashion.
After seven years of Android on Chromebooks, I’m ready to see it.