Android on Chromebooks...Does it make sense?

Let me start this blog by saying that I am not slamming Android. I've been an Android user ever since getting an Ion phone at Google I/O 2009. I still have that phone, in fact. It can be an interesting experience to compare the Android Cupcake running on it to the current Android versions like KitKat, Lollipop, and Marshmallow. Android has come a long way in seven years! I've also been an Android developer, with varying degrees of regularity, since the platform was introduced. I love the object-oriented design of the system and the elegant message-passing mechanism of Intents. A Smalltalk programmer would feel right at home working with Android. So, my concerns are not because of some hatred of Android. Far from it.

The idea of integrating Chrome OS and Android OS is an old one. Some of the earliest posts in the Chromebook forum were speculating about adding Android to Chromebooks. Some thought that there should be Chromebooks with keyboards that could rotate under the display (like today's Asus Flip) or where the keyboard could detach from what was essentially a tablet (the Pixel C). With the keyboard detached or the display rotated to portrait mode, the Hybridbook would boot Android OS instead of Chrome OS. Others just wanted to see Android OS and Chrome OS merged somehow, so that you could run both Android and Chrome apps on the same device. (This was largely realized on the Android side when the Chrome browser finally came to Android.)

My issues with Android OS on Chromebooks mostly come down to four things: incompatible user cases, usefulness of Android apps on a Chromebook, the Chromebook as reference implementation for the web platform, and security.

Incompatible Use Cases

Think about how you use mobile devices - especially your cell phone. When you use your phone you want to do something quickly: make a phone call, check your email, send a text, look up a movie time, find a restaurant, order some food, do a search, maybe play a game or watch a video if you have a few minutes to kill. What do all of these use cases have in common? You need some information quickly, so you want a highly focused app that starts up fast and gets you the information you need with a minimum number of required interactions. Most of what you do on your Android device is consume content. You're probably not writing the next great novel or even putting together the presentation you're planning to give at work on your Android device.

Now think about how you use your Chromebook. If you're like me, it's the first device you reach for when you want to write a document or create the slides for a presentation. I'm writing this blog on a Chromebook. I prefer it for doing research. It's much easier to open a number of webpages to be able to locate, read, and reference information on a Chromebook than it is on an Android device. I use it for taking online classes (I have yet to encounter an online education platform that doesn't run beautifully on a Chromebook). I use it to edit video with WeVideo. In concert with my Android phone and Google Photos, it is my photo album. I view, edit, and post my photos - all with a Chromebook. I even do what I didn't imagine would be possible on a Chromebook: program! The Chrome Dev Editor is a really nice local code editor with good GitHub integration, a built-in bower build system, and an integrated localhost. It is great for web programming, including with Polymer. Unfortunately, Google stopped developing it (more on this trend in a bit). Never fear though, there are still good options, like Cloud9, where you can use any tool you are used to using in Ubuntu through your Chromebook. You can program with 40 different languages and they have templates for HTML, Node, Ruby, Python, C++, Django, PHP and Apache, even Wordpress. And, it works offline. The big difference with my Chromebook is that I'm creating content - not consuming it.

Microsoft learned this lesson with Windows 8. They tried to integrate mobile devices and the desktop. but desktop users didn't want to have to tap icons and use swipe gestures to get their work done. The metro (modern) interface apps were generally pretty lame, especially to users who were used to traditional Windows programs. On the other hand, apps originally designed for the desktop didn't translate well to mobile - even if they did make the touch areas and icons larger. The clash of the incompatible desktop and mobile use cases made for a user experience that was painful for all Windows users. Microsoft seems to have learned their lesson with Windows 10, which defaults to a desktop interface on the desktop and a mobile interface on mobile, but it cost them a lot of customer support in the process.

Usefulness of Android Apps on a Chromebook

When you look at the specs for one of the Chromebooks that will be the first to allow running Android apps, the Chromebook Pixel 2, what is missing? Do you see an accelerometer? A gyroscope? A GPS receiver? A front-facing camera? No. Because those aren't normal sensors for a laptop. But, many Android apps rely on one or more of those sensors, because they are standard in mobile devices. 

I have been searching my brain (and the apps installed on my Android devices) to try to figure out which apps I would want to run on a Chromebook. Ingress? Nope. Won't work without GPS. Cardboard Camera? Won't work without a gyroscope, an accelerometer, or a GPS receiver. It would also be pretty hard to strap a Chromebook onto your head. Minecraft PE? We may be on to something here. A common complaint about Chromebooks is that they don't allow Java to be installed. Minecraft PE might finally be the way for all those Minecraft fans to get MC on their Chromebooks. Except that Minecraft PE isn't really the full-fledged Minecraft and the mobile-optimized controls are likely to get irritating very quickly on a Chromebook. Outlook? The mobile app is better than the web app, but I only use it to check office emails during my commute to work. Not really a compelling reason to run it on a Chromebook.

I really can't think of a single app I want to use on a Chromebook. And any app I did try to run would undoubtedly be a second-class experience on a Chromebook. Few apps are designed with a desktop mode in mind.

Can you think of an Android app you really want to run on Chrome OS?

Chromebook as Reference Implementation for the Web Platform

When the rocket hamster-adorned box first appeared on my doorstep back in late November 2010, I really wasn't sure what to think of it. A laptop that only runs the Chrome browser? What was the point? I waited for nearly a week before I finally opened the box and charged the battery. Then I tried it out. It took a little while, but I rapidly began to see that this was a new paradigm. It was a gateway to the web as a platform. It truly was a revolutionary idea that Google was trying to advance.

OK, maybe I'm being a bit hyperbolic. Anyone who has used a VT-100 "smart terminal" hooked up to some big iron in a computer center in a basement has seen the concept before. The difference was that the terminal really was smart (much more powerful than the VT-120s I used to use when I was an undergrad), the ethernet cables had been replaced by TCP/IP over WiFi or cellular service, and the VAX computer in the basement had been replaced by a multitude of server farms. But the advantages are all the same: your data is readily available on any machine with an Internet connection, applications are always the latest version, security patches are applied automatically, and you don't need to worry about a disk drive failure or losing a flash drive. Everything is there, waiting for you in the cloud when you need it. 

Google explained their vision of Chromebooks in a video during the Google I/O 2011 keynote in what I still consider to be the best design description I have seen done by any project. Entertaining, yet thoroughly describes the concept of Chrome OS in just under two minutes. Brilliant!

Sadly, Google seems to have lost this vision that was so clearly articulated in 2011. By 2012, the Chromebook was "for everyone" and the rolling fields of green were on the background of Chromebooks. Google was making Chrome OS look more like a standard OS with windows and a desktop and all the things we've come to take for granted after 30 years of the "personal computer." But these changes added complexity and detracted from the mental shift that is cloud computing. As succeeding years have gone by, Google seems to be focusing more and more on Android (only about 40 sessions at this year's I/O were related in any way to the web platform - that may seem like a lot, but that's less than a quarter of all the sessions at I/O 2016). Google's Dart language, which was launched to great fanfare at Google I/O 2012 as the modern tool for building scalable apps for the web platform, has been effectively reduced to a second-class language: it isn't a priority for Firebase integration (one of the hottest topics at I/O), new language updates seem to have slowed down, there wasn't a single Dart session at I/O this year, and Dartpad (the recommended IDE for Dart development) hasn't been updated to the current version of the Dart SDK. Google's Polymer project is getting a little bit more love as an essential component of Progressive Web Apps (which were the majority of the Web Platform presentations at this year's I/O), but there has been no replacement for the now abandoned Chrome Dev Editor and the Google Developer outreach for Polymer is just a shadow of the outreach for other Google products.

From the standpoint of the numbers (and Google prides themselves on being data-driven), the focus on Android is understandable. As of the date I am writing this, Android holds nearly 71% of the global mobile market share, more than three times the global share of iOS. That is a market dominance that is hard to ignore, but failing to put resources into the web platform seems a very short-sighted policy on Google's part. Especially since they were the first ones to really clearly articulate and demonstrate a vision of the web as a platform.

Security

I've saved one of my biggest concerns for last. Security. One of the things I love about my Chromebooks is their security. It was built in to Chrome OS from the beginning: Sandboxed execution for browser tabs, verified boot, and the ability to restore to factory condition, if needed. No operating system is 100% secure (unless you never power it up), but Chrome OS has been the most secure system I've ever used. Android, on the other hand, has had a focus on being open and easy for developers to use. This isn't to say that Android doesn't take security into account, but the Android approach is the more traditional OS approach: sign apps to try to identify where they've come from, respond quickly to identified vulnerabilities, and maintain the integrity of the core OS. But, that doesn't mean there aren't plenty of vulnerabilities that could be exploited. Android is more like Windows than Chrome OS when it comes to security.

So, how is Google going to integrate Android into Chrome OS? Details are difficult to track down, but it appears that the approach is to integrate a container (ala Docker) containing a full implementation of the latest Android runtime into future builds of Chrome OS. I love Docker containers. We are in the process of "containerizing" some of the open source projects I am working on to make it easier for new contributors to onboard: the entire development environment they need to get started can be put into the container. But a container is not like the Native Client (NaCl) approach the Chrome OS team was taking before (which allowed native execution of code within a sandboxed execution environment) and it is also not like a virtual machine, which is essentially a virtual computer running in a sandbox. Containers access the underlying operating system directly and rely on hashed user ids and permission controls to prevent users (apps) from acting maliciously. 

The problem with containers is there are concerns about how effective their security is. Even proponents of containers point out that they have to be implemented very carefully to prevent introducing vulnerabilities. Now, I know that the Chrome OS team are very talented engineers and I have the utmost respect for their capabilities, but containers are relatively new to production applications. Do they really know all the possible vulnerabilities? I already mentioned the vulnerabilities in Android. Now, if we combine those with the potential vulnerabilities of containers, will it really be possible to consider Chrome OS secure? If Chromebooks start getting compromised, how long will it take to damage their reputation for security? And, even if I don't enable the Android integration on my Chromebooks, the code is still there in the Chrome OS image installed on my Chromebook. How secure will it be?

Pardon my not dancing

So, with all of these things considered, you'll have to excuse me if I don't dance with joy as most of the tech press and many users are about this news. Maybe I'm wrong and this really will be the best thing that ever happened to Chromebooks, but I'm honestly not seeing that as the case. It seems that Google is just wandering ever farther from their once innovative and brilliant vision for the web platform.