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 darker side of Android

[Can an open Android result in a closed phone? Research Director Andreas Constantinou explains why this will not be the exception, but the rule]

Stop signThe G1, the first phone to carry the Android OS has been discussed extensively across the blogosphere. Those expecting an iPhone killer have certainly been disappointed. So have those who expected Google’s first phone to be “truly open” as Google pledged for the Android OS.

The HTC smartphone is locked to the T-Mobile network binding eager fans with a two year contract. T-Mobile won’t allow VoIP applications running on the handset either. Plus you need an GMail account to use the G1, prompting concerns about whether Google is tracking phone usage (neither confirmed nor denied at present). The phone is also pre-packaged with Google services: search, YouTube, GMail, Calendar, Maps and Streetview, as well as access to Google’s Market and Amazon’s mp3 download service.

The source code for Android will be out in Q4 under an Apache 2 license, hopefully shortly after the October 22 launch of the G1. Yet an open source operating system doesn’t mean an open phone.

The darker side of Android
Google’s Android has plenty of unique features to rave about, as we ‘ve covered earlier. But Android also has a ‘dark side’ – aspects which Google doesn’t want to talk about too much. Here’s a short list:

Not a market-ready operating system. While Google provides the source code for the entire application environment to OEMs, it leaves the hardest part of cellular stack integration to the OEM and the hardware platform providers. Stabilisation of 3G stacks is notoriously difficult and involves testing 1000s of corner cases of telephony stack integration (something which is believed to have caused significant delays for Motorola’s L-J platform).

Fragmentation by design. Android uses an Apache 2 license which allows handset OEMs to modify and ship the code without any obligation to share their modifications. At last week’s mobile open source conference in Berlin, Mike Jennings said that the Dalvik virtual machine source code would also be released under APL2. If the virtual machine is open to optimisation changes, this is sure to result in fragmentation by design and interoperability breaks. At the same time it should be noted that software licensed under non-copyleft licenses (e.g. WebKit) is known to resist forking as contributors are incentivised close to the branch where the gravity of contributions are made (Apple’s branch in the case of WebKit). Google offers an API test tool, but clearly what we need is not testing for compliance, but enforcing compliance.

Liability concerns will result in locked handsets. Android source code is promised to ship under APL2. We assume that this is the license under which the Android OS ships to OEMs. Interestingly, APL2 license explicitly disclaims any and all warranties and liabilities. In the world of mobile software, warranties and liabilities are common practice, offering OEMs to ability to pass on liabilities which result from defective software. In plain English, if an OEM needs to recall a few thousand handsets due to a software fault, they need someone to blame. With APL2, Google steers clear of the liability game and passes the burden onto the OEM to self-indemnify or seek third party insurance with expensive premiums. Moreover, OEMs who ship Android phones will not leave any liability holes open; if a third party application interferes with the handset operation, the OEM will be unwilling to pick up the tab. Which means that Android handsets will move access to several APIs off limits to developers. When I asked Mike Jennings about this at last week’s conference he declined to comment, saying he had not been briefed on this issue.

During several months of testing of Android development on the m5 (pre-beta) release, we had uncovered several additional omissions; the emulator left a lot to be wanted (incl. phone call, battery, Bluetooth and other hardware emulation) while the tools for creating UIs were rudimentary.

A key message here is that an open source operating system does not result in open phones. Google’s ‘built it and they will come’ approach does not readily apply to mobile devices for the reasons described earlier.

Clearly, Google has set the expectations too high.

– Andreas

[Update: this article was awarded ‘best post of the week‘ honours at the Carnival of the Mobilists, hosted by Xen Mendelsohn – thanks Xen!]

  • Pingback: Mippin Blog()

  • Pingback: Martin J Smith()

  • Another great article, Stephan! I'll admit that I (respectfully) disagree on one point: the fragmentation argument. If an OEM or carrier decides to sell an Android phone that breaks the App Store, that phone will not be popular will buyers and will be quickly discounted and forgotten. Android should be popular with early adopters, who are smart enough to research the differences between devices. Releasing an incompatible Android handset would get a lot of bad attention from the blogosphere, and I'd expect OEMs and carriers to realize this and not make that mistake.

  • wait, this article wasn't written by Stephan! : ) Imposter!

  • Pingback: geekinside's me2DAY()

  • Hi Matthew. Who Stephan ? 🙂

    Handset OEMs have never produced interoperable handsets simply due to concerns of blogosphere retaliation – the Java ME framentation is a good example. Lack of interoperability is created because OEMs want to differentiate with performance, additional capabilities or APIs. The one thing that might reduce fragmentation in Android is the 'gravity of contributions' effect that I described above, as per the WebKit model.


  • Hi Andreas,

    Do you really mean that comment – that lack of handset interoperability and fragmentation of JavaME is purely caused because bloggers would complain if there was no fragmentation? Maybe I misunderstand…

  • Hi Raddedas,

    No – I ment entirely the opposite, but my use of grammar didn't help convey the point. My point was that handset OEMs have never seen blogosphere retaliation as an incentive to create interoperable handsets – and they never will.


  • Ben Hookway

    Hi Andreas, Nice article. Do you have any insight into the hardware that is going to be needed to run a reasonable Android implementation? I hear the T-Mobile device is running a Qualcomm chip with a 526MHz processor – heavyweight stuff.

  • Hi Stefan & Andreas & Raddedas & Fred,

    I like the title of the article, although frankly, I think the dark side is much darker than that, like Google doing a lot of tracking & pulling data/stats and more — and helping world govts do the same (but don't all phone co's do that now anyway???).

    While early adopters/buyers will likely be stuck with a closed phone (to some extent) for awhile, the beauty of the 'net is that most phones get cracked wide open by the world community of disgruntled engineers (aka hackers), and bitTorrent is still around so people can share in the wealth.

    While Google is making an open source phone OS with a foolish attempt to keep the marketplace in it's control, I hope that the 'real free market' — hackers (ie freedom fighters), pirates (aka copiers), and bittorrent (aka 'freedom of speech' as software) — will eventually re-open things in time.

    Some of you may notice I re-interpreted all those names (hackers, pirates, etc). I think we must reclaim our language from the double-think of corp-biased media. The real pirates of 2008 are the corporate CEOs, the political spin artists, the media moguls cutting off freedom of the press, the freelance mercenaries working for the CIA, the drug cartels, the mafia, etc — and it seems like most of those are the SAME people!

    WAKEUP and smell the coffee (which is often produced with child labor and slave labor wages in poor countries).


    aka Ari

  • Surya

    Hi Andreas,

    Great article once again. Just had a question on the point about "fragmentation by design".

    When you say "by design", do you mean Google has intentionally set things up so that fragmentation happens? How would Google benefit from this?

    On the other hand, if Google is not hoping for fragmentation, why are they sticking with the Apache license? Why can't they modify the license such that Dalvik cannot be modified without feeding back into the main code stream?

    Please excuse me if my questions are ignorant..


  • Hi Andreas – Am I the only person whose PC browser (IE6 running on Win XP) resolutely fails to display more than the first 3 lines of each response to articles in this blog? // dw2-0

    PS Opera Mini on my Nokia E61i makes a *much* better job of displaying the comments!

  • Surya,

    Good questions.

    Fragmentation by design: I meant two things by this:

    a) My guess is that Google is counting on diversity (as in biodiversity) for the survival of the fittest stack.

    b) simply that Google knows that people can create binary incompatible Androids from the 'master' APL2 stack, therefore it's 'designed' for fragmentation.

    Dalvik: we won't know for sure whether Dalvik code will be covered under APL2 until the v1.0 is released in source code form. Mike Jennings did say that Dalvik would be also licensed under APL2, but I 'm not holding my breath. Dalvik holds the key to binary runtime compatibility.


    thanks for the tip on IE6. We 've had compatibility issues with IE6 before, and we 'll fix the comments snag asap.


  • For another article on a roughly similar theme, see "Google’s Android Market Guarantees Problems for Users" at http://www.roughlydrafted.com/2008/08/29/googles-

  • very interesting article Andreas! Been travelling so I missed it. Agree with all you say – and also that its been a bit disappointing so far with Android. We have been covering this topic in our respective blogs .. and we know ofcourse that 'an open source operating system doesn’t mean an open phone' is true. But the converse question is more interesting as well: What constitutes an Open phone? I had a long article I am working with(Openness in general and also relating to phone) – and have been thinking of this for a while. Seek your thoughts. If you take a purist stance, then openmoko is potentially a candidate(since it includes HW and SW combined). And leads to a even more broader question – would an open phone be commercially accepted/useful? The problem of fragmentation can be solved by uniting around a certain paradigm (and that need not be a phone). More interetingly – it appears to me that Google is going for a pricepoint of free(ie ad funded) apps


    Android – iPhone revenue models: Can 70 plus 30 equal free? – Is the future of mobile apps free or fee based?

    So, if you look at the whole pic, then the approach seems to be to provide a Good enough/free app – so no customer support hassles etc.

    In that context, it is disappointing since developers wont get anything if it is free .. but Google still gets ad revenue(and I refer to one of your excelent older posts – every element of the Android stack becomes a Web 2.0 element – or something like that ..) i..e we get targetted advertising like Gmail with metadata derieved from every element of the stack ..

    A long comment! and late in the night at Hong Kong and gotta go early morning to China .. but hope you find it useful inspite of ite rambling nature! kind rgds Ajit

  • Thanks Ajit – openness is indeed a very complex issue. Here's how I break it down:

    1. Openness for developers

    a. API-level openness for developing downloadable AND core applications

    b. tools openness: cost of tools, both in terms of one of cost, but also development costs, testing efffort needed

    c.route-to-market openness, i.e. access to a centrallised channel for certification, distribution, provisioning, and billing

    d. post-sales channel openness, i.e. having an open channel to the user using your app

    2. Openness for handset OEMs

    a. access to read AND modify source code (this has lots of parameters – see West and O'Mahony, 2008)

    b. access to hardware boards, for quickly bringing up new devices

    3. Openness for network operators

    a. ability to request customisation changes, without impacting time-to-market or cost (both are usually impacted, but because OEMs in purpose introduce lengthier TTMs as a negotiation strategy)

    Probably 1-2 more aspects which escaped the braindump.. I think this justifies a new post 🙂


  • thanks. I also did something similar a while ago. Agree complex topic. But what about the free bit? I think mobile apps are tending to free ..


    LBS for £1.79? Vicinity app on the iPhone. What does it say for the Context – location based services business/ revenue model?

    If things start to get free(even LBS type apps) – then it needs a fundamantal rethink .. and I dont have any answers – just the observation that the evidence on Android and iPhone both leans to free mobile apps ..

    Having said that, even if an app is £2 and there are 100,000 downloads, it is still a good model for the developer ** assuming ** they get to keep 70%. Thats the really worrying thing re Android – revenue share i.e. if we are talking of free then many of the consideratuons(like fragmentation, support etc) don matter that much! thoughts? kind rgds Ajit

  • Ajit – I hope to do a comparison on Download! vs Android Market vs AppStore vs BREW Shop in the near future. I 'll hold my judgement till then 🙂



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 ...