Google only made a single, brief mention of its efforts to add Android apps to Chromebooks during last week’s Google I/O keynote address. But a Google I/O session went much deeper. And helps to explain what’s taking so long.

You may recall that Google announced one year ago that it would bring Android apps and the Google Play Store to Chromebooks. The plan at the time was for this work to be done by the end of the year. But as 2016 turned into 2017, only a few Chromebooks could run Android apps as part of a pre-release program, leading to questions about Google’s ability to even pull off this feat.

The questions continued in early 2017 when Samsung announced its Chromebook Plus and Chromebook Pro 2-in-1 devices, which were marketed as the first Chromebooks to ship with an integrated pen support. The Chromebook Plus shipped in February, but the Intel-based Pro model was delayed repeatedly—from March to April and then to May—and is now expected to ship in the next few weeks. The reason? Android integration with Chromebook.

Speculation about the cause of these delays was correct in the broad strokes: The work of integrating Androids apps with Chromebook proved to be far more difficult than Google had originally expected.

But now we know a bit more about the problems Google faced. And, in some cases, what they have done to address them.

You can find out more from the Android Apps for Chromebooks and Large Screen Devices session from Google I/O 2017. But here’s a rundown tailored for end users, not programmers.

In many ways, these issues with Android apps on Chromebook parallel the problems Windows 10 has today with legacy desktop applications on high DPI screens: Those apps were written at a time when you could assume screen sizes and resolutions, and they used hard-coded graphics and text that don’t scale well on modern hardware. With Android, many legacy apps make all kinds of assumptions—that they will always be displayed full screen, for example, or in portrait mode—and their creators never imagined that they would run on Chromebooks with hardware keyboards, big landscape displays, and pens.

Getting Android apps updated to support Chromebooks is obviously a priority, and Google has some obvious steps that developers can take to make that happen. (Or to create new Android apps that understand Chromebooks and other large screen devices right from the start.) They should support both portrait and landscape modes, resizable windows, and keyboard, mouse, and, optionally, pen, plus drag and drop.

But the reality is that not all apps will be updated to accommodate these changes, at least not immediately. And so Google has been doing work to improve Chromebook’s support of Android apps in a way that short circuits bad behavior.

For example, Chrome OS will now examine the version of Android that an app has been written for and then handle window management accordingly. An app written for a pre-Android M version, for example, will always be displayed maximized, while Android M-targeted apps can be switched between two fixed sizes: Windowed and fullscreen. But apps written to Android N or later can be freely resized by the user and will thus look and feel more native on Chromebook. In the latter two cases, Chrome OS will display the applicable window controls (Maximize, Minimize).

An Android app, designed for a phone, running on Chromebook. You can grab the window edges with the mouse cursor and resize it.

(Modern Android apps can also specify window size and position, if needed, and Chrome OS will respect that. Too, games, are a special case that are handled in a specific manner to ensure the best experience.)

Windows resizing is one of the biggest hurdles, and in some extreme cases, these kinds of unexpected changes actually cause data loss or crashes. There’s not much Google can do about apps that are this poorly-written, but this speaks to the problem here nicely: This is such a basic feature, but it’s one that many Android apps were not written to expect.

Keyboard navigation is a bit better: Android already uses defaults based on layout to determine which control should have the focus in an app, and developers can, of course, specify that as well. If they do, the app will automatically support keyboard
navigation (using TAB) and other niceties. Apps can also handle keyboard actions, including shortcuts.

Finally, Google has belatedly realized that they need to offer a Chromebook emulator so that developers can test their apps in this environment right from Android Studio. That emulator will be available soon, it says. Developers can find out more here.

All this said, I find Google’s silence about this work during the I/O keynote to be somewhat telling. And it wouldn’t surprise me if this effort of combining Android with Chromebook continued at a slow pace. Further, I’m wondering now if Google will eventually leave behind “legacy” Chromebooks that do not support at least a touch screen because of the amount of work involved.

Tagged with Chrome OS, Chromebook