BuildingDroidsLast week, Google unveiled a bit more on the ChromeOS initiativie, including source code. Some people already have it running on netbooks, even though commercial devices running ChromeOS are not due out until 2010.

As usual, there was a round of questions as to where Android ends and where ChromeOS begins. No other than Sergey Brin suggested that the two operating systems might combine forces sometime in the future.

In the interim, let’s ponder a totally crazy notion: having ChromeOS devices be able to run Android apps.

On the surface, this is indeed totally crazy. After all, ChromeOS’s UI is Chrome, and that has been plain from the outset. The expectation, therefore, is that ChromeOS apps are Web apps, taking advantage of HTML5 features for local data caching and whatnot.

However, Chrome can have extensions. It would appear that ChromeOS, at least as shipped on devices, will have an extension for Adobe Flash. This begs a question: if Chrome extensions and ChromeOS can handle Flash applications, why not implement an Android APK extension for Chrome in much the same fashion?

An Android application is a set of Java classes encoded in Dalvik bytecode. Those classes assume a Dalvik VM and a Java class library containing all the classes that make Android applications work (e.g., android.* packages). That Java class library, in turn, delegates some stuff to a native code layer through JNI. That native code layer presumes that it is running on the Android edition of the Linux kernel, has OpenCORE for multimedia, has WebKit for the WebView component, etc.

But, this is just code. It doesn’t necessarily have to work that way. So long as there is native code implementing the methods that the Java class library expects, and so long as that native code behaves properly, the APK runtime environment could, in principle, execute outside of Android proper…such as on Chrome, via a Chrome extension.


Just as the Flash extension gets a chunk of screen space and can draw in it whatever is needed, so would the Android extension. Just as the Flash extension has hooks back into Chrome to do things like open new browser windows, so would the Android extension (i.e., starting the Browser activity to view a URL would open a new Chrome tab). Just as the Flash extension has access to multimedia hardware, so would the Android extension. And so on.

Now, there are likely going to be things that will not work well this way, and the work to implement the rest would be truly herculean. The extension may not be small, either. On the other hand, such an extension would mean that many Android APKs would work on ChromeOS…and other platforms where Chrome is deployed…and conceivably other browsers if the extension were ported to, say, Firefox.

I am not a firmware guy, so I suspect there are any number of flaws with this concept. However, it serves as an illustration to remind everyone that getting Android applications to run on such-and-so hardware does not necessarily mean that the solution is to get Android as a whole to run on that hardware.

Note: Select outbound links may include affiliate tracking codes and AndroidGuys may receive compensation for purchases. Read our policy. As an Amazon Associate we earn from qualifying purchases.


  1. I'm not sure if it makes more sense to have Dalvik on top of ChromeOS, or the Chrome Browser on top of Android. Each probably has its advantages. But, I am hoping to eventually see a nice mix of the two platforms that gives us the best of both (netbook feature support built-in to Android, desktop quality browser on Android, fast-boot/splashtop type support in Android, touch screen and screen rotation features in Chrome OS (for use on tablets and convertible tablet netbooks), Dalvik apps in Chrome OS, variant Chrome OS distributions (like what Cyanogen does for Android)). If something like that really is the future for Android and Chrome OS, then the future looks promising to me.

    Especially if I can get that on a 10" tablet with a 1280×720-1280×800 hybrid e-paper/LCD multi-touch display, KVM ports (mini-DVI-I and 2+ USB host/otg ports), 5-way dpad (maybe with built-in optical mouse), 3d accelerometers for device input and screen rotation, 3.5mm headset jack, SDHC card slot, 1GB+ RAM, 4GB-32GB built in storage options, Wifi, GPS/AGPS/compass, optional internal 3G support, charge/sync via mini-USB client, and TONS of battery life. And, if the fast-boot/splashtop features let you hand-off to Ubuntu (or any OS of the user's choice) when you need a more intensive OS, then that'd be perfect. E-reader, media-player, commute computer, meeting computer, couch computer, vacation computer … yup, that'd be my ideal mid-range computer.

Comments are closed.