top of page
Writer's pictureSlashData Team

The Naked Android

It had become painfully clear to Android’s executives: they had officially lost control. Something had to be done. There was only one option: to strip Android naked. Senior Analyst Stijn Schuermans explains how Google made it tough for ambitious rascals to fork Android and dump Google.

VMNakedAndroid

It had become painfully clear to Android’s executives: they had officially lost control. The operating system had been forked by Amazon and too many Asian handset makers. Worse, it had become too easy to replace Google Play with a proprietary app store yet leverage existing Android apps; too easy to replace Google’s services (Maps) with 3rd party alternatives (Nokia’s HERE). Even the Android brand wasn’t the king of the hill anymore, being eclipsed by Samsung’s Galaxy.

Something had to be done. There was only one option: to strip Android naked.

And so that’s what Google did. It let go of control over Android-the-OS. Instead it consolidated control on the APIs needed to make apps, consolidating them within the Google Play Services app. If any rascals want to fork the Android operating system, let them: they can no longer take the entire app ecosystem with them.

Google’s control of Android is eroding

Several years ago we wrote a post criticising Google’s openness statements around Android. Our 2011 study on the Open Governance Index found that [tweetable]Android is the most closed of all mobile open source projects[/tweetable]. We were also the first to document the Android control points in 2010, three years before the EU finalised its antitrust investigation. [tweetable]Android has been open to developers, but not to handset makers[/tweetable] who have had to comply with Google’s draconian certification and bundling of their apps and data mining software.

Despite the open source and zero-priced nature of the Android OS license, Google could not easily be bypassed. OEMs needed Google for the trademark, Google’s killer apps that leverage its online services and identity (GMail, Maps, and many others) and the Play Store, to get access to the hundreds of thousands of apps that end-users demanded. By cleverly closing down those parts of Android that matter, Google had gained a large amount of control over those who wanted to make an Android handset. A reaction was inevitable.

[tweetable]Over time, Google’s control points were systematically attacked and eroded[/tweetable]. Amazon and Yandex, to name just a few, successfully replaced the Google Play store with their own app and content stores. The One Platform Foundation (led by Yandex and Opera) attempted to liberate in-app payments and the app store packaging format from Google’s control, so that you can publish an app on multiple stores with a single click. Nokia HERE (formerly known as Navteq) provided a decent licensable alternative to Google Maps. Samsung spent a lot of effort in recreating all of Google’s services. Samsung also spared no expense in creating its own Galaxy brand, which is becoming as well-known as Android.

Samsung app replacement

With Google partially losing control over Android’s app ecosystem, the advertising giant had to do something. It decided to strip Android naked (a term coined by Nicolas Sauvage). It did so by shifting the control points one level up.

Closing down the APIs

Instead of gaining control through operating system certification, Google moved more and more critical APIs out of the open source operating system and into its proprietary Google Play Services software.

Update: We just learned Google will ship Android 4.4 without the Chrome browser.

ClosingAPIs.PNG

This had an immediate advantage: it reduced the fragmentation problem that had been plaguing Android for years.

Google Play Services is a piece of software that Google can update silently (without the user’s action or even knowledge) and over the air. Google no longer depends on handset makers and operators to update the software that app developers depend upon. Many users might (and do) have old Android versions on their devices: 26% of devices still use v2.3 Gingerbread, released almost three years ago, while only 2,3% uses v4.3 Jelly Bean, released in July 2013 (source: Google, Nov 1, 2013). Over 99% of devices, however, can run the latest version of Google Play Services. It is this which matters most to app developers.

FragmentationRelief.PNG

But this was just the start.

Controlling app development

Many developers will now be using a mix of OS and Google Play Services APIs; the former being available on any Android fork, the latter not. Before, the API gap between Google’s version of Android and forks of the OS was mostly in-app billing (the problem that OnePF was trying to fix). Now this gap includes many important services that a lot of developers depend upon: authentication, location APIs, messaging, to name just a few. Developers will now be forced to rewrite parts of their app for each Android fork they want the app to be distributed on.

[tweetable]Google has lost some control on distribution & discovery, but is regaining it on development[/tweetable].

3ControlPoints.PNG

ARS Technica has done a good job of documenting the end-user implications of this move. Yes, you have your photo, email and other apps in Android public codebase (AOSP), but they are poor cousins of their Google-supported versions. Google seems to prioritize APIs that add innovation and end-user value to their services, so that AOSP apps look outdated. But beyond the effect on end users, the implications for device makers are far more widespread and lasting.

Google’s move puts up the pressure on Amazon and other Android spinoffs to provide alternatives APIs on top of Android to replace those incorporated in Google Play Services. Some are trying: Amazon for example recently added analytics and split testing capabilities to a list of APIs including login, backend services, billing, push messaging, ads and of course the Amazon Appstore for distribution. Amazon and other are taking great pains to making migration to new APIs as easy as possible, e.g. by showing how to match the Maps APIs with theirs.

Even so, companies who fork Android will have to convince developers – who have limited resources and attention spans – that their version offers a large enough user base to be worth supporting. Only a few, if any, will succeed.

The endgame for Google: flatten, expand, mine

The “Android ecosystem” has become a misnomer. It really should be called the “Google Play Services ecosystem”. (Sadly, it doesn’t’ have the same ring to it.) Google has re-established firm control over the apps that drive Android’s success as a platform.

Android as an operating system is still important to Google in the light of its defensive strategy to flatten everything standing between the user’s eyeballs and Google’s ad inventory. Android has succeeded, and will continue to succeed, in preventing any mobile platform from becoming a monopoly in the way that Microsoft Windows was on the PC.

The Google strategy pillars

But Google’s strategy has two more pillars: to expand its footprint across the user journey with more services, and to increase the value of its ads by data-mining the user’s behavior. Not Android, but Google Play Services is now driving Google’s expand and mine imperatives.

Google has certainly shown mastery in making open source work to its advantage. Of course, we can’t assume that this is the end of this story. If you were Amazon, Yandex or Samsung, how would you react?

– Stijn (@stijnschuermans)

bottom of page