
I think it’s fair to say that I’ve been semi-obsessed by Google’s decision to add Android app support to Chrome OS: I see this combined platform as a clear and present danger to Windows 10 and, more important, the most aggressive step yet taken by a competitor to unseat Microsoft’s desktop platform in its core remaining markets.
Microsoft’s response to this threat has often been tone-deaf, mirroring, in some ways, its absurd response to the iPhone and multi-touch smartphones a decade ago. And it has done itself no favors by making the Windows experience less bearable with in-product advertising, crapware bundling, Windows 10 S/S mode, and other initiatives aimed at reinventing the product at the expense of its users.
Fortunately for Microsoft, however, the combination of the Android apps platform has required far more time and effort than Google originally anticipated. The online giant announced this effort two years ago and said at the time that it expected to fully deliver on this combined experience by the end of 2016.
Nope. 2016 came and went with just basic Android app support, in beta form, and on a small range of devices. And I then spent all of 2017 waiting for the revolution that never came. At Google I/O one year ago, the firm provided an update on the situation, implicitly admitting to the difficulties.
Done correctly, Android apps running on Chrome OS should be hugely disruptive, and have the opportunity, as I called it before this initiative was announced, to pull the plug on the PC industry.
And we did finally see signs of life from late 2017 onward, from Google’s amazing Pixelbook, which provides an elegant, convertible PC form factor on which to run this hybrid platform, to various system improvements like split-screen support, improved tethering, full tablet support, and more. Things have heated up quite a bit in recent months.
And I/O 2018 was last week. As expected, Google provided an update on the ability of Chrome OS to run Android apps. This session was a continuation of a talk from last year’s I/O, and it provides an interesting update on the platform’s progress at the 2-year mark of the original announcement.
So where are we at?
First, Google provided an interesting look at its Chrome OS milestones over the past year. The system is now the most popular in the education market in the United States, with Chromebooks outselling all other PC platforms combined. And it’s not just in the U.S.: As discussed previously, Chromebooks are making inroads in education in places like western Europe, Australia, Canada, and elsewhere too. Its success is spreading.
But it’s not just education: In Q4 2017, over 17 percent of all notebooks sold in the U.S. were Chromebooks, Google noted at I/O. The success of this system is spreading beyond education too.
From a technological perspective, Google has spent two years fine-tuning—-I’d say “fixing”—the user experience of running Android apps on Chrome. Most Android apps will “work” to some degree in Chrome OS, since the system provides native compatibility with the Android apps platform and the Google Play Store via a container-based system. But making them work well, making them seem more native, has proven challenging.
Google provides Android app developers with the programming hooks they need to optimize their apps for Chromebooks and the form factors, bigger screens, and unique capabilities that these systems provide. And that’s great: Developers who see the benefits of this integration can do some work to make it pay off in useful ways for users.
According to Google, there are four key differences between an Android device and a Chromebook from the perspective of an app developer: Chromebooks have wider screens, they default to landscape from a display orientation perspective, they provide more sophisticated window management capabilities (including the ability to arbitrarily resize app windows), and they can include a keyboard, touchpad/pointer, and pen.
Google provided a nice peek at the work it’s doing to make the experience of running Android apps on Chromebooks here in 2018 more seamless for developers and, thus, for users as well.
We’ve heard some of this before. Google has introduced a tablet mode for Chrome OS because there are now pure tablet devices and hybrid devices, like the Pixelbook, that can be used as a tablet. And Chrome OS now displays Chrome and Android notifications side-by-side and the two are essentially integrated into a single system with an identical look and feel.
In Chrome OS 65, Google added support for MIDI, and it will add support for other pro audio features like multi-channel audio and multi-channel USB audio in Chrome OS 69.
Google will also build on the Snap-like split screen mode it supports now by adding the ability for apps to detect that they are running in this mode. With Android P, it will also let Android apps to utilize a Picture-in-Picture (PiP) display mode so that they can run on top of fullscreen apps, be resized, and be moved around the screen.
And in Chrome OS 69, the system will pick up the Android IME virtual keyboard, which provides the full range of functionality—emojis, GIFs, etc.—that we see today on Android. Many users will simply prefer the Android keyboard over the Chrome keyboard.
But the issue here is that Google can only do so much: App developers will have to adapt their Android apps to work seamlessly on Chrome OS manually. Many are doing so, I guess. But until this support is (near) universal, the experience of running Android apps on Chrome will be a mixed bag.
And that’s the rub.
When I wrote about Windows 10 on ARM recently in my HP Envy x2 (Qualcomm) Review, I noted that the central issue of this platform is the gotcha of application compatibility. Normal users will never know if certain apps will work at all until they try to run them. And when things don’t work, the resulting error message is nonsensical and won’t help resolve the issue.
The issue is similar with Android apps on Chrome. Worse, maybe. Most Android apps should “work,” but those quotes around work are deliberate: They’ll be like Pet Sematary versions of the originals, not quite the same, not quite right. They won’t work well on Chrome. Or they will randomly crash and can’t be trusted.
Too, there is the weird duplicitous nature of apps for which there are two versions, one on Chrome (a web app) and one on Android. Which should the user use? Does it vary by app? Is it up to them to do the testing, to even understand this situation? (We see this a little bit on Windows 10, where there are sometimes web or native versions of some apps and mobile apps, too, as with Microsoft Word.)
Ultimately, what Google has discovered is that adding an established and dominant mobile platform to a new desktop platform is as hard, if not harder, than what Microsoft did first with Windows 8, which was to add a new mobile app platform to an established and dominant desktop platform. Users have expectations, after all. And the basics need to just work.
Speaking recently to a source at Microsoft, I also discovered that the software giant is actually overjoyed that Google has added Android to Chrome OS. The source cited the Android fragmentation and security issues that this change brought to a platform that had been, to that point, more secure, simpler, easier to manage, and a real threat. But with Android integration, Chrome OS is suddenly as much of a mess as Windows is. That’s an interesting angle I had never fully considered. I’m not 100 percent sure it matters, to be honest. But still interesting.
Anyway, Google is pushing ahead with Android apps on Chrome OS. And the session noted above provides tons of information about how developers can adapt their Android apps to work well on Chrome OS. It seems like a lot of work, frankly. But two years in, things seem to be coming together in a meaningful way. Overall, I’d say that Microsoft’s window is closing.
With technology shaping our everyday lives, how could we not dig deeper?
Thurrott Premium delivers an honest and thorough perspective about the technologies we use and rely on everyday. Discover deeper content as a Premium member.