I recently read an article where a technical reporter was speculating that Google’s next big move would be for ChromeOS to make inroads into the Smartphone market, essentially replacing Android for higher end devices. The argument was based upon these points:

  • ChromeOS is gaining in popularity, so manufacturers will find it compelling to use
  • The new system-on-a-chip (SoC) devices used to power our mobile devices are ever increasing in computing power
  • Google’s recent Android 4.4 (KitKat) release actually reduced the hardware requirements for new platforms, making it prime for low end devices (i.e. feature phones)

Just look at the latest offerings from Qualcomm, Intel, Nvidia and TI and you can see why the reporter might think this. Each of these vendors is rolling out chipsets with multiple processing cores plus hardware acceleration for graphics, encryption and multimedia.  As of Nov. 2013, smartphones accounted for just under 64% of all mobile subscribers in the U.S. Worldwide, the numbers drop by about 1/3, putting the total smartphone market size around 22%. Using the previous data source, we can see that tablet numbers are much lower, at only about 6% of market penetration; but, the tablet market has made it to the 6% mark faster than the smartphone did. The tablet market is exploding, which explains why it seems there is a new tablet every other week on the market.

Both the smartphone and tablet markets are ripe with opportunity. Chips are getting faster, tablets are taking off and people expect more out of their connected devices. Couple this with Android 4.4 dropping the minimum memory requirement to 512MB and it certainly makes you think. While this sounds interesting on the surface, the real likelihood of this happening is not very high. To explain why, you have to look closely at each OS, the markets they serve and the backing technology.  First, for those not familiar with what ChromeOS or Android are, let’s take a step back and look at both at a high level.



ChromeOS was first announced back in July of 2009. It is based on a Linux kernel and the UI originally planned to be powered by the popular Chrome web browser.  Google’s goal was to create lightweight, easy to use netbook devices to replace the traditional laptop for most users. This always connected device would have no real local storage, everything lives in the cloud. The premise is that most users are using their devices these days to browse the web, send and receive emails, or play online games. All of these things can be done via today’s web browsers, so for many users there is no need for a heavier, power hungry device which must support legacy software. This also bridges the gap for those not interested in a purely touch screen interface which you find on tablets. Vendors can still write software for ChromeOS using the Package App Platform, writing the app in HTML5, JavaScript and CSS. These devices started to enter the market in June of 2011 with offerings from Samsung and Acer, and are gaining in popularity.  The design has shifted slightly from the original, with ChromeOS now including a file browser and a window manager.  But, the main app “environment” is still the Chrome browser.



Android is a mobile OS originally targeted at Smartphones and has expanded into the tablet market. It is geared toward small, lightweight mobile devices which are always connected. Android is also based on a Linux kernel, but uses a custom framework and operating environment with apps running in a software virtual machine (VM). Android devices are intended to have touch screens and have started to adopt accessory keyboard support for tablets. Storage can be both in the cloud, and on local or external storage (i.e. SD card.)  The framework and operating environment are well suited for this small, mobile device market and provide a rich framework for app creation, multimedia support, advanced graphics, and networking.  Development is generally done in Java, albeit not “standard” Java.  However, developers may also use native (C/C++), HTML/JavaScript/CSS or other specialized languages and development tools.


What’s the Difference?

From my high level description, these sound very similar. Embedded/mobile operating systems for lightweight, low power devices which are (almost) always connected to the Internet. Both powered by a Linux kernel. But, this is really where the similarities end.

Android apps run within a VM environment with apps assigned unique user IDs, and sandboxed by process and filesystem area. Apps are separated by process and communicate using an extension to the kernel called the binder and run within a VM instance. A huge codebase and framework have been built over the 5 years as Android has grown.

ChromeOS, on the other hand, uses the Linux kernel to power itself but apps generally are run inside of a Chrome browser instance.  The main intent is for the user to use cloud based services and websites for their applications.  However, developers can create ChromeOS apps using a development kit.  These are basically device hosted, modified web apps. ChromeOS provides its own app framework, also very large, and unrelated to Android’s existing framework.

These two operating environments are very different. In order for ChromeOS to take over the higher end smartphone/tablet market, it would need to support existing Android apps out of the box. Why? Simple: there are over 1 billion (yes, billion) Android devices activated worldwide and over 1 million apps in the current Google Play store. The last thing a user would want is to go to their local Verizon, AT&T, Virgin Wireless, China Mobile, etc. and spend $500 on a shiny new mobile phone and discover their favorite apps aren’t available. By not supporting Android apps out of the box, app vendors would have to rewrite their apps for ChromeOS. Different development languages, different operating environment, and different OS. I can tell you this is not an easy task and software vendors are not going to invest the time/money to write the app unless there is a market to sell it and make money.


CPU Power and Manpower

Having stated all of that, is it still possible that reporter is correct and this could be the direction Google is heading? It is anyone’s guess, really. Is it technically possible? Absolutely. Google employs some of the most talented engineers, scientists and thinkers on the planet. It would be possible for ChromeOS to recognize Android APKs, create an instance of a Dalvik for that app and keep it all within a Chrome instance “wrapper” with a shim layer to talk to other ChromeOS or Android apps. Another approach may be to have ChromeOS essentially hosted inside of Android.  Sound complicated?  You better believe it. Google has the talent to make this happen, there is no doubt. In either case, the increased processing power available from new SoCs could make this possible. But, having helped architect and implement multiple Android devices for OEMs I can tell you that Google takes pride in making the underlying OS and framework efficient. There is not a mentality of “the CPUs have more horsepower, it’s ok if the software is bloated, the user won’t notice.”  So I’m very skeptical that either of these two approaches would be pursued.

Sergey Brin, one of Google’s founders and technology visionaries, predicted years ago that eventually Android and ChromeOS would likely converge over time. I’m not saying it won’t happen; but, I do not think that we are there yet. What do you think? Are ChromeOS and Android coming to a crossroads? What would be the advantage of ChromeOS taking over the high end mobile market?



Almost as if someone was reading my mind, this announcement was made shortly after I posted this blog entry.  Now, this is geared more towards Chrome apps in general (i.e. regular desktop Chrome), but ChromeOS is built upon this, so my second option above was not too far off.  Regardless, I still contend the reporter was incorrect: ChromeOS is not going to take the mobile market from Android.  It would seem far more likely the shoe would be on the other foot, with Android being used on netbooks in the future.