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.
This is called ARCVM and it’s rolling out to newer devices now. I see it with Chrome OS 100 on the HP Chromebase 21.5, for example, which is now running Android 11.
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.
9 Comments
Very Cool. For all my moaning about Chrome OS at times, it’s still light years ahead of Win 11.
Unfortunately I have to buy some Windows machines soon š My Win7 machines are starting to be too slow. I rarely need Windows it’s mostly for my family and some games.
Reading about Win 11 sounds like it wont be any good until Win 12 is out š
Using Chrome OS is a joy compared to Windows.
“Using Chrome OS is a joy compared to Windows.”
?
If the ability to run Android apps inside an emulator becomes increasingly popular, but running the same Android apps on Chromebooks is a consistently better experience than on comparably priced Windows machines, then Windows advocates won’t be able to credibly claim that you can run Android apps on Windows “just like” you can on a Chromebook. This would be an increasingly important selling point. Users would probably define a better experience as being more stable and native-like. Given the popularity of running Android apps on Windows machines, it becomes evident that the decision to create ARC for Chrome OS was really a matter of survival rather than an innovative design elective.
Wow. After hearing years of Docker/Kubernetes advocates promote the advantages of moving apps from virtual machines to containers – platform independence! modular microservice architecture! fewer resources! – it is “interesting” to see this approach. For example, why does the container/host kernel need to match in the first place? Why does the ChromeOS (Gentoo Linux) kernel need those patches in the first place? It should be possible to put all the dependencies in the container and simply push all updates to the container independently.
“Not shown is Linux but it would be a container within the same crosvm area.”
I would rather Android and Crostini be run in separate VMs. Maybe putting both Crostini and Borealis containers in the same VM would make sense.
I meant to say this above: this new architecture also allows Google to ultimately ditch the Linux kernel if they decide to. It would permit Android (as well as Crostini and Borealis) to run on any OS that can host a hypervisor. While we are at it, the same could be done for the Chrome browser too, especially if it is LaCrOS.
>>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 approach with Android.<>Not shown is Linux but it would be a container within the same crosvm area.<<
I doubt that the rearchitecting of support for Android on Chrome OS will involve any changes to Linux support. Android apps and Linux apps won't (and can't) execute in the same virtual machine. The relationship between VMs (crosvm) and OS environments will continue to be one-to-one – Android apps run in an ARCVM environment (crosvm + Android OS guest) and Linux apps run in a Crostini/Linux VM environment (crosvm + Linux OS guest + Linux container). The address space of the Linux environment can be further divided up if applications call upon the containers feature of the Linux kernel.
>>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 approach with Android.<<
It is true that Android on Chrome OS, viz. on Chromebooks, Chromeboxes, etc., now fits more with Google's strategy for running Linux apps on Chrome OS – Android (like other versions of Linux) will now run as a guest OS environment in a virtual machine. Unfortunately, your comment is ambiguous. Did you mean to imply that Android will also be using the same container strategy that applies to Linux on Chrome OS? Whatever your view may be I seeing nothing in what Google has said about ARCVM that indicates that Android support on Chrome OS will be going down a path that is entirely in sync with Google's Crostini, container inside a VM, strategy to support Linux and Linux apps. Containers don't appear to be in the picture for Android. Android apps execute in the environment provided by ARCVM.
You’re correct that there’s no container in the ARCVM architecture; rather than saying the “same” approach, it would be more accurate to say a “similar” approach. I’ll edit that word for greater accuracy as I didn’t mean to imply ARCVM would implement a container in a VM. Thanks!
>>…Iād expect more efficiency and less memory usage when using Android apps<<
Perhaps, but I'm not so sure. I think there is a good chance that Android app performance will improve to a degree. That will happen (if it happens) not primarily due to architectural advantages of moving to ARCVM but rather because the sum of software optimisations accumulated over time in the form of refinements to applications and platforms simply work as they should because ARCVM offers a more stable environment for development. The current architecture is more brittle with programers stuck chasing down bugs and regressions that appear at a great rate. The new architecture offers the prospect that the scale of this problem will be reduced.
Still, moving away from a container based implementaion of Android on Chrome OS will probably come at a small to moderate resource cost. There is the fixed additional resource cost, viz. increased RAM requirements, of the extra Linux/Android Common Kernel (with VM patches), of course, and the cost of translating special calls (involving the already mentioned Android Common Kernel as well as crosvm) into something usable by the Chrome OS kernel and its KVM subsystem to achieve actual hardware control. The apps don't grow bigger but the amount of shuffling of binary code in the plumbing of the system, nevertheless, does increase. It is good if stability can be gained without a hit to resources but I don't think that is the case here.