Google Explains the Delays in Bringing Android to Chromebook
- Paul Thurrott
- May 21, 2017
-
30
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.
Windows Intelligence In Your Inbox
Sign up for our new free newsletter to get three time-saving tips each Friday — and get free copies of Paul Thurrott's Windows 11 and Windows 10 Field Guides (normally $9.99) as a special welcome gift!
"*" indicates required fields
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).
(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
Conversation 30 comments
-
skane2600
<blockquote><a href="#118419"><em>In reply to Gary Moncrieff:</em></a></blockquote><p>Whose interest? Progressive web-apps are inside baseball to average users. Smart companies will do what makes sense to the bottom line without regard to the latest development craze. But it wouldn't be the first time developers pushed their company into adopting newer approaches they believe will enhance their resumes for future employment opportunities. That's not so say that progressive web apps are never the answer, but rather the decision to adopt them should not be simply based on the buzz.</p>
-
nicktitan46
<p>Amazing information providing by your article, thank you so much for taking the time to share a wonderful article.</p><p><br></p>
-
skane2600
<p>Applications are written for the platform they were designed for at that time. Developers aren't responsible for anticipating possible future changes that may or may not be made unilaterally by an OS vendor. </p><p><br></p><p>The entity that creates the breaking change is the one responsible for the poor performance.</p>
-
Bats
<p>That's it? This is old news. It's so old news, that Paul is the only one in the whole blogsphere reporting this. That's because most people already know this . I even mentioned it on Paul's previous post about this topic. Also, it's not true about Android Apps only in a few Chromebooks right now. There is about a dozen or so Chromebooks that already can be used with Android Apps. </p><p>It is also not true, this statement "<span style="color: rgb(0, 0, 0);">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." Why is it not true? Because Android Apps can be used on Chromebooks now. It's just that Google's vision of Android on Chromebook got more ambitious, since the announcement from last year. Late last year, there was already discussion about this topic from Techspot, Android Central, BGR and others about the portrait/landscape issue. Not only that, but I even mentioned last week or the week before on Paul's other post (I think it was regarding Samsung Chromebook). LOL….even I knew it. Why Paul is the only one reporting this as new news, is beyond me. Around that time, there was even talk about "Andromeda" OS. Again, this is all OLD NEWS.</span></p><p><span style="color: rgb(0, 0, 0);">WOW….talk about the "alternative facts." (LOL)</span></p>