Getting Ready for ChromeOS
A bit over two weeks ago, I delivered an “Android on the Desktop” presentation to the NYC Android Developer Meetup.
A couple of weeks before that, I blogged about the signs that Android apps were coming to Chrome OS.
A year prior to that, I blogged about the new option for distributing Android apps to Chrome OS.
So, when last week’s announcement on this came out, while I don’t mean to say “I told you so”… but I told you so.
Admittedly, it is not happening quite as I expected. Reading between the lines of the announcements, the Ars Technica article, and the VentureBeat article, it appears that Google jettisoned the ARC approach. Instead, it seems as though our apps are going to be running in a beefed-up edition of the Android SDK emulator, one with some platform-specific hooks (e.g., integrated window management with Chrome OS-native windows). And they feel confident enough about this approach that your app will, indeed, wind up shipping to Chrome OS unless you take steps to block it.
So, now what? In particular, if you want to support Chrome OS, what should you do?
First, try to get your hands on compatible hardware. At least here in the US, two of the three near-term test devices are relatively inexpensive, in the $200-300 range. These devices should get the Android app support in June. Note that all three have touchscreens.
You will then want to review your <uses-feature> elements, along with
any implied <uses-feature> elements coming from your <uses-permission> elements.
Ideally, you have few of these, and those that you have are set for
android:required="false". The more that you require, the less likely
it is that your app will work on Chrome OS. In particular, pay attention
to hardware features that may not be on Chrome OS devices, remembering
that not all Chrome OS devices are notebook equivalents. Some are desktop
replacements (e.g., Chromebox). So, while many Chrome OS devices will
have a camera, some will not. Also, since your app cannot supply Chrome OS
with an input method editor, app widgets, live wallpaper, or a
replacement home screen, their corresponding <uses-feature> elements
should be set to not be required.
Next, confirm whether your app can work without a touchscreen. For example,
you might hook up a Bluetooth keyboard and mouse to a test tablet, then
try using your app. If you determine that your app can be used successfully without
a touchscreen, add the following to your manifest, as a child element
of the root <manifest> element:
<uses-feature android:name="android.hardware.touchscreen" required="false" />
This will allow your app to be used on Chrome OS devices that lack a touchscreen, when such devices start getting Android apps later this year.
Once your test Chromebook gets Android app capability, look for instructions for how to test your app on it. Ideally, it will work with our development tools the same way that devices and emulators do, but that is not assured. Note that this is supposed to arrive in M53 on the developer channel to these devices, so you may need to make some changes to your test Chromebook to pull in from the dev channel instead of the standard public channel.
If you decide that you do not want to deal with Chrome OS at all, you
will need to decide how you want to block such distribution. Presumably,
you will be able to do this via the Play Developer Console, but it might
not be that easy, if you have to block distribution on a device-by-device
basis. You might cheat and add in a <uses-feature> element that should
be supported by mobile devices but would not be supported by Chrome OS
(e.g., <uses-feature android:name="android.software.app_widget" />),
even if your app does not actually implement such a feature, just to tide
you over until you add Chrome OS support later.
And you will want to add Chrome OS support later. Chrome OS is interesting, but at its estimated install base, it is roughly equivalent to Froyo (0.1% of Android devices). On its own, therefore, it is not worth a lot of effort. However, it seems rather unlikely that Google will stop here. In the next couple of years, I expect Google to replicate this same approach on Windows, Mac, and Linux. That audience is substantially larger and therefore more compelling. Use Chrome OS as an extended test run for eventually supporting classic desktop operating systems in the future.
You can read more about all of this:
- The Chromium guide to writing Android apps for Chrome OS
- The roster of Android-supporting Chrome OS devices
- The announcement, as seen from the Google Chrome team
I will be updating my book to reflect these changes as they roll out over the next several months, so subscribers can keep up with how to support Chrome OS.
