Distilling market noise into market sense
The VisionMobile blog is a space where VisionMobile analysts and industry insiders exchange views on the fast-changing mobile market and the trends that define the future direction of telecoms.
The many faces of Android fragmentation
[Android fragmentation is only getting started. Research Director Andreas Constantinou breaks down the 3 dimensions of Android fragmentation and argues how Android will become a victim of its own success]
The article is also available in Chinese.
There’s been plenty of talk of Android fragmentation, but little analysis of its meaning and impacts.
As far as definitions go, the best way to look at fragmentation is not from an API viewpoint, but from an application viewpoint; if you take the top-10,000 (free and paid) apps on Android, how many of these run on all the Android-powered phones?
For Google’s Android team, fragmentation is what keeps them up at night. Fragmentation reduces the addressable market of applications, increases the cost of development and could ultimately break the developer story around Android as we ‘ll see.
Google’s CTS (compatibility test spec) is predicated on ensuring that Market apps run on every Android phone. Android handsets have to pass CTS in order to get access to private codelines, the Market or the Android trademark as we covered in our earlier analysis of Google’s 8 control points – and yes, Google controls what partners do with Android, contrary to the Engadget story.
The 3 dimensions of Android fragmentation
Many observers would point to fragmentation arising as a result of the open source (APL2) license attached to the Android public source code. Reality however is much more complex. There are 3 dimensions of Android fragmentation:
1. Codebase fragmentation. Very few companies have taken the approach of forking the public Android codebase, as permitted under the APL2 license; Google innovates so fast (5 major versions in 12 months) that once you fork, the costs of keeping up-to-date with Google’s tip-of-tree are increasing prohibitively over time (Nokia found out the hard way by forking WebKit and then regretting it).
The main fork of the Android codebase is by China Mobile (the world’s biggest operator with over 500M subscribers) who has outsourced Android development to software company Borqs. China Mobile cares less about keeping up-to-date with the latest Android features as the China market operates as an island where cheap, fake (Shanzai) handsets are predominant. Mediatek, a leading vendor of chipsets shipping in 200-300 million handsets per year plans to make Android available, which could mean another major fork. Cyanogen and GeeksPhone also fork the Android public codeline, but they are designed for a niche of tech-savvy Android fans.
2. Release fragmentation. Google has released 5 major updates to Android in 12 months (1.5, 1.6, 2.0, 2.1 and recently 2.2), all of which introduce major features and often API breaks. You may notice how accessing the Android Market from a 1.6 versus a 2.1 handset gives you a different set of apps. So much for forward compatibility. AndroidFragmentation.com (a community project) has documented several cases of release fragmentation arising from releases which break APIs (e.g. 2.0 SDK breaks older contact apps) or from inconsistent OEM implementations (e.g. receiving multicast messages over WiFi is disabled for most HTC devices).
Release fragmentation is the victim of Google’s own speed of innovation – and Andy Rubin has hinted there’s more major releases coming out in the next 6 months. It’s clearly a sign of how young, agile Internet companies know how to develop software much better that companies with a mobile legacy; major Symbian versions take 12-18 months to release.
Release fragmentation is particularly acute due to the lack limited availability of an automatic update mechanism much like that found on the iPhone. We call the phenomenon ‘runtime aging’ and it is directly responsible for increasing the cost of developing applications. Tier-1 network operators see handsets in their installed base with browsers which are 1-6 years old – that’s how hairy it can get for mobile content (and software) development companies. [update: we understand that certain Android handsets come with a firmware update (FOTA) solution available from Google and other FOTA vendors, but it is installed reactively (i.e. to avoid handset recalls) rather than proactively (i.e. to update all handsets to the latest OS flavour)].
Google itself reports that the Android installed base is split between devices running 1.5, 1.6 and 2.1 versions (or at least for those devices accessing the Android Market). The detailed breakdown as of mid May 2010 is as follows:
Release fragmentation is also arises out of Google’s elitist treatment of its OEM partners. Google will pick and choose which private codeline is available to which OEM based on commercial criteria (contrary to Michael Gartenberg’s story). Take for example how Sony Ericsson’s X10 (running on Android 1.6) came to market after the Nexus One (running on Android 2.1). Ironically, both handsets were made by HTC. [correction: the X10 was developed by Sony Ericsson Japan]
3. Profile fragmentation. Android was designed for volume smartphones. But it arrived at an opportune time – just after the iPhone launch and just as consumer electronics manufacturers were looking at how to develop connected devices. This resulted in two effects that Google hadn’t planned for:
- Android was taken up by all tier-1 (and many tier-2) operators/carriers hoping to develop iPhone-like devices at cheaper prices (i.e. lower subsidies) and greater differentiation. That meant that while operators funded Android’s adolescent years (2008-2010), they niched Android handsets to high-end features and smartphone price points.
- Android is now being taken up by 10s of consumer electronics manufacturers, from car displays and set-top boxes to tablets, DECT phones and picture frames. The Archos internet tablet was just the beginning. Each of these devices has very different requirements and therefore results in different platform profiles.
The timing of Android’s entry into the market has therefore resulted in two implications related to fragmentation.
Firstly, Android’s official codebase isn’t suited for mass-market handsets (think ARM9 or ARM11, 200-500MHz). To get to really large volumes (100M+ annually), Google will need to sanction a second Android profile for mass-market devices. This is a Catch-22, as a second profile is needed to hit large volumes, but it would also break the Android developer story.
Secondly, every new platform profile designed for different form factors (in-car, set-top box, tablet, etc) will create API variations that will be hard to manage. That’s one of the key reasons behind the Google TV initiative and the Open Embedded Software Foundation. However even Google can’t move fast enough to coordinate (manage?) the 10s of use cases and form factors emerging for Android.
All in all, Android fragmentation is going to get far worse, as Android becomes a victim of its own success.But hey, would you expect to have a single app (and a single codebase) that runs on your TV, phone and car?
And there the opportunity lies for tools vendors to provide app porting tools, compatibility test tools and SDKs to help bridge the gap across the eventual jungle of Android fragmentation. And for those looking to better understand the Android commercials we offer a half-day training course on the commercial dynamics behind Android.
What do readers think? Do you have any fragmentation stories to share?
you should follow me on twitter: @andreascon