If you were to design a client operating system with the goal of being used by two billion people, what would it look like?
We might soon find out what Alphabet’s looks like. Today’s announcement’s from Alphabet’s Google is expected to reveal "Andromeda", the merged Android/Chrome OS. Executives have been hyping today’s event as the most "significant" since the first Android device in 2008, and we already know they’re writing a new operating system from a clean slate. We can also have a good guess about what it looks like.
Google’s goal for the successor is to unify the rival Chrome and Android platforms while providing a clean code base free of the Java legacy. Google’s big advantage here is that it now has a blank slate.
After Google acquired Android in 2005, Sun Microsystems’ then CEO Jonathan Schwartz offered Google “congratulations on the announcement of their new Java/Linux phone platform”. Android founder Andy Rubin had already figured Java worked, and seen how it decreased time to market, and how much developers liked it. (Anything was preferable to writing for Symbian, the dominant smartphone platform of the time.)
But Google doesn’t need Java any more, and the more distance it puts between itself and its Java-based legacy, the better, particularly if (as it is reasonable to expect) Oracle ultimately prevails in the litigation on appeal. Nor does it need, at least not quite so much, the VM-based architecture designed to make porting easy. If OS abstraction is sufficiently well designed, then an easily-ported microkernel can suffice.
Microsoft took this approach designing Windows NT, although within three years Redmond had broken the microkernel design (moving graphics drivers into the kernel) and a couple of years after that, the last non-Intel port had been mothballed. By then it was, to all intents and purposes, a monolithic kernel Intel OS.
Computer history is littered with “Second System” effects, but Google’s “second system” looks promising. We already know what it looks like. The open source Fuchsia project is led by QNX and BeOS veterans, with plenty of experience designing Android. Fuchsia code boots on x86 hardware, and the source tree indicates it’s going to be backwards-compatible with key Android libraries.
Fuchsia has been touted as suitable primarily for embedded devices and its key developers have embedded experience. (And Fuchsia wouldn’t need to be running Android libraries if Google only wanted it to power watches and fridge magnets.)
Strong ARMed tech
You really need to look at demographics and the cost curve of client devices to see where Alphabet wants its Android successor to run. The ARM world is gradually superseding the x86/amd64 world, and PC sales are in a long-term decline. ARM has a huge cost advantage over Intel, and most first-time computer users are using ARM tablets and phones. So the opportunity here for “Andromeda” is to ensure the “next billion” coming on line, particularly in emerging economies, remain plugged into Google services, while expanding the capabilities of Android2 so it can run the next generation of creative and productivity applications. Why not just tweak Android to do that? Remix OS does just that, adding power management and overlapping windows to Android x86.
The Android architecture is already unwieldy, with much code moving into the GMS (Google Mobile Services) binary. Android has distanced itself from Dalvik with its ART runtime, but this is still an optimised Dalvik. The really serious performance (and user experience) wins are made by moving away from a byte code architecture completely to a new microkernel. Users won’t get that “optimizing apps” wait after a platform update (that’s a sure sign of an archaic platform).
Google will want to keep the Chrome brand and user base, but Chrome users themselves couldn’t really care less what it runs, as a Chromebook is just a dumb terminal for web-based Google services. That part is easy.
I’d expect to see Fuchsia make its début today, perhaps by borrowing a few ideas from Continuum, allowing a device to act smarter when it’s plugged into a remote display. ®