Distilling market noise into market sense

VisionMobile is the leading research company in the app economy. Our Developer Economics research program tracks developer experiences across platforms, revenues, apps, tools, APIs, segments and regions, via the largest, most global developer surveys.

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?

– Andreas
you should follow me on twitter: @andreascon

  • Jo Ritter

    Andreas, thanks for this great post. I just had a talk about Android Fragmentation on the German droidcon conference (the barcamp, in fact), you might find some of the research interesting <a href="http://(http://www.slideshare.net/j.ritter/androidfragmentationcom-an-open-community-project)” target=”_blank”>(http://www.slideshare.net/j.ritter/androidfragmentationcom-an-open-community-project).

    We have launched an open community project called AndroidFragmentation.com that aims at helping developers to deal with the problem. Open for anyone to contribute.

    – Jo

  • Hi Andreas.

    just a couple of things:

    – not sure that X10 is made by HTC. Are you sure?


    – "would you expect to have a single app (and a single codebase) that runs on your TV, phone and car?"

    Yes, that would be the perfect runtime! 🙂



  • Yann

    Excellent article!

    Hopefully it can't get much worse than J2ME fragmentation… can it??

  • oliverw

    I think one of the biggest issues is the fragmentation of user experience. There are more Android user experiences than OS versions, e.g HTC Sense UI. Customers have very different Android experiences and levels of service integration

  • To echo Simone, are you sure X10 was made by HTC not SE? Btw, do you know who makes Android UI for both HTC and SE? Looks like the same company…

    As for the fragmentation, I think Google is not worried so much about it as they see Android as a short-term fix to run their services on mobile phones. When the web runtime environment comes true on mobiles, it will make Android and other platforms irrelevant and their role will diminish to underneath heavvy lifting. The question is how soon it is going to happen?

  • Aissen

    Interesting article, at leats I'm not the only one thinking Michael Gartenberg's was incomplete.

    I'd consider HTC's Sense as a fork of the Android code base as well. Maybe not as deep as China Mobile's but already very deep.

    On a sidenote, I find it amusing that you offer commercial training on Android but didn't know all about the top-tier market (high end phones), and who made the X10.

  • Jo,

    AndroidFragmentation.com is an excellent (and much needed) initiative. I updated the post to add a reference to the PPT and some examples of fragmentation.


    You 're right, the X10 wasn't made by HTC, but by SEMC Japan – it's an error on our part as we should have double-checked the source. I 've updated the post.


    Google is much more heavy-handed in the Android governance model, whereas Sun took more of a laissez-faire approach (as long as Java licensees are paying their license and TCK fees!). As a result, I expect Android fragmentation to be more 'contained' than Java ME fragmentation – if Android ever reaches the ubiquity of Java ME.


    I would agree on UI fragmentation in terms of UI behavioural differences as perceived by developers (AndroidFragmentation.com highlights some examples of UI fragmentation). However, do customers really care if HTC's SenseUI is different to the Samsung Android UI? For example, Android has a weaker brand than HTC, and one might argue that it's more important for HTC devices to be UI-consistent.


    See my response to Simone – I 've corrected the reference to the X10 and HTC. Your other comment on Android being a vehicle to proliferate Google services is spot on. But I don't see HTML4/5 being deployed ubiquitously and consistently across mobile phones (in the foreseeable future!); Android is the best chance Google has today, but Chrome or other web runtimes might be what Google may latch on in the future to promulgate its services.


  • UB

    I appreciate the blog and also good comments contributed…thanks. One more point though, the comparison of mobile to PC is a bit romantic, but I think is very different in many ways. For ex, the demographics it serves are entirely different, more stark in emerging markets while it is slightly blurred in developed countries – this calls for a consistent software and user experience strategy. The irony is that PC software strategies were less fragmented than the current mobile market today. You may be right on supply-value-chain perspective, but the value proposition is different in mobile.

    I wish Google takes-up some substantial software strategy, rather than knee-jerk, greed-blinded, short-term, incompetent ones as per its usual habit. We need some really open, but disciplined software environment for mobile market for the good of consumers.

  • Marc

    You wrote, "It’s clearly a sign of how young, agile Internet companies know how to develop software much better than companies with a mobile legacy".

    I have highest respect for the clever marketing that makes Google even wealthier, but I'd rather formulate that its clearly a sign of how young, agile Internet companies with a strong brand manage to use the momentum of their market power to deliver strategically and architecturally half-baked software that everyone is made to believe represents the future. Reminds me of the emperor's new clothes – except for the lack of children.

  • Hi Marc,

    Google's Android has had it's patchy spots in the past, and the open source licensed branch is stratefically incomplete. I also agree that Google's brand and clever marketing can coerse some developers into thinking that open source is manna from heaven.

    However, why do you say that Android is half-baked? Do you mean purposefully incomplete, immature or of mediocre quality?


  • Biji

    Reading your post i still dont understand what you addressed, the codebase or apps running on it?

    For me fragmentation is freedom

  • Hi Biji,

    Fragmentation is one side of the coin. The other side is Diversity. Depends which side you 're looking at.

    The article addressed platform fragmentation that creates incompatibility issues for apps running on top.


  • Mike Grant

    Good post Andreas.


    for the companies righting the core device software Android is freedom, but for content developers writing apps that use those APIs, fragmentation = increased cost.

    As a J2ME and BREW games developer, I spent 50% of my money on porting. That was money that should have been going into the games experience itself. As a result of fragmentation in the J2ME and (to a lessor degree) the BREW world, users got half the games experience they could have got for their £2.99. Sales of that poorer experience were limited, and developers end up going out of business – or, as in our case, get bought out. Just this week Glu – the US #3 player and one of the consolidators, raised $13m from investors to keep itself afloat.

    Unless an OEM puts their hands around Android and creates their own software platform structured and controlled the way Apple controls iOS, the Android world will look exactly like the J2ME world in two years time. An apps ghetoo that has eaten up a lot of shareholder money and delivered very little to consumers.

  • tz

    With the newer phones they could develop in Adobe Flash.

    as far as iOS, you have the same problem or even worse – selling today is the iPod Touch 3g 8m is actually 2g so has a slower processor and the earlier hardware, the iPad can do many things the others can't, and the iPod4 has the gyro, and three different native screen resolutions so far. Tell me that isn't a problem.


Distilling market noise into market sense

What gets desktop developers out of bed in the morning?

desktop developer segmentation

Despite all the hype around the death of the PC and the enormous amount of media attention focused on mobile,…

Continue reading ...

A proven model for targeting IoT developers


  What if you could identify a handful of developer personas, or segments, each with a very distinct set of…

Continue reading ...

1000 skills: Amazon Alexa as a metaphor for the IoT developer community


Alexa is a centerpiece of Amazon’s Smart Home push, and quickly growing to become one of the most promising attempts…

Continue reading ...


Research on the app economy and developer ecosystems

Developer Segmentation 2014


The Developer Segmentation Q3 2014 report is the most sophisticated study of developer segments to date. The report delivers a…

Continue reading ...

App Profits and Costs


This research report examines the critical success factors for a profitable app, and how business and technology choices, such as…

Continue reading ...

Developer Segmentation 2013

Developer Segmentation 2013

The Developer Segmentation 2013 report delivers a needs-based segmentation model that actually works, with extensive profiling of the eight principle…

Continue reading ...