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.

Beware of Android bearing gifts

[Is Google the great benefactor, or is there a bag of tricks hiding behind Android? Research Director Andreas Constantinou explains how Google may be using commercials to deploy services on Android phones, why Android is not that well designed for the mobile industry and how Google can overcome its challenges]


Android was launched in November 2007, breaking new ground with open source in the mobile industry. Single-handedly Android triggered the Nokia S60/Symbian merger and open source roadmap, and pre-empted the openness of the LiMo foundation (Linux-based) initiative.

[updated: this post has been featured on the Carnival of the Mobilists! Thanks Tam.]

The hype tsunami that has followed Android is well documented in the blogosphere. So are the mis-steps that Google made away from its openness pledge, including working behind closed doors with selected developers and restricting applications from its Android Market.

What seems to be still a puzzle is how Google is using Android to further its primary goals; making more money from ad inventory sales. And whether Android is the panacea it’s promised to be;  HTC is only producing devices so far, Arora devices have been delayed indefinitely and many OEMs are promising but not showing any handsets.

Google’s bag of tricks
If the entire Android software stack is open source and freely available to download, modify and reuse, how does Google deploy its services and ads? Surely, Google is not just a benefactor to the mobile industry, there must be something that it gets back in return to the 300+ man years it has put into the effort already, especially as Google is a publicly traded company.

There’s two tricks up Google’s sleeve that we ‘ve been able to deduce based on public info:
– Android Market (or any part of the marketplace) is closed source and Google-proprietary. And it’s not just the on-device storefront that Google holds the key to (which is easily replicable), but the whole marketplace, distribution and – more importantly – the developer ecosystem behind it.
– The Android source code is not productised. You need (in our estimates) 1+ year of productisation efforts and Google’s help to develop an Android phone. By the way, this is true for any phone; even if Symbian’s source code was open source from inception, it would still take OEMs 3+ years to reach a level where they can produce differentiated phones fast enough. In short, Google’s professional services are much needed by an OEM producing Android phones.

In exchange for Android Market and professional services, I would assume that Google can demand a tall order in return;
– bundling of Google apps (and thereby exposure to Google’s services)
– access to usage analytics for Google phones – and thereby helping Google target ads more finely and increase CPCs and CPMs.. surely a highly controversial topic for which Google ought to be keeping the details close to chest..

Designed for 3rd parties, but not 2nd parties and handset OEMs.
Google has released a ton of source code under the APL2 open source license; just have a look for yourself at source.android.com.

Android has been designed exceptionally well for 3rd party application developers; the programming paradigm of Intents and Java-SE environment make programming apps a breeze.

We tested Android against S60 for developing a PhotoEditor and a Mapping application (with two developers per OS) and the results were crystal-clear: development time and emulator debug time was less than half in the case of Android, compared to S60.

However, when designing Android, the Google team had the PC paradigm in mind. And in the mobile industry, it’s not 3rd party developers who create phones. It’s OEMs and their partners (so-called 2nd party developers). And the needs & wants of 2nd party developers are very different to those of 3rd parties.

OEMs care not just about speed of app development, but the speed of variant management; i.e. how quickly can you take one Android phone and create a second one that looks very different in a fraction of the time. Android is poorly designed in going from n to n+1 variant. You need to be re-customising the Java code for each app separately, playing with XML templates and inheritance operators alone will not help. In general, variant management is a major thorn for handset manufacturers and no-one has solved this issue completely (mostly because OEMs are extremely risk averse these days).

Moreover, the APL2 licensed source code at source.android.com is missing several key components for productising mobile phones:
language packs: Google promised 7 languages for 1Q09, but that’s already passed. You need support for 50+ languages in order to launch a phone globally and Google certainly has a lot of catching up to do in comparison to S40 and S60.
bluetooth drivers: most phones need them
DRM support for content: often required by operators and content providers in Europe.
operator compliance software and certification: one of the main omissions in Android that stalls product delivery into European operators. This is not something that was intentionaly left out, but assumedly comes from the PC-centric mentality at Google HQ.
– theming support

Google has decided to control the roadmap and the code checkins (even cupcake is a development branch not the productised code); and so each OEM who has to develop operator packs, language packs, etc doesn’t have a straightforward way (or any obligation!) to share the developments with the Android community. In plain English, this calls for reinventing the wheel for each OEM that builds an Android phone. This is a very hard problem to solve and not one that either LiMo or Symbian Foundation have got a solution to yet.

Android is a victim of its success
To the surprise of most industry observers, the industry (including operators and handset OEMs) have shifted from criticising Android in late 2007 to adopting Android in late 2008.

So what does this mean for Google?

It means that up to 2008, Google was working with one OEM (HTC) and one operator (T-Mobile). And since 2009 it has to work with nearly 10 OEMs (Motorola, Huawei, Sony Ericsson, Samsung, HTC, Acer, Lenovo, Archos, Garmin, Toshiba) and several operators (O2, Vodafone, T-Mobile China Mobile, ..).

You would think that Google’s mighty 20,000+ workforce can easily cope. But the 100-strong Android team that Google acquired isn’t showing signs of scaling to match the demand; at least the roadmap seems to lack the pace of development, let alone innovation that is expected from Google.

Overall, Google should seriously struggle to meet demand from OEMs in 2009. I wouldn’t be surprised if we see half a dozen phones launch in 2009.

What Android needs most
What Android needs most is for the key productisers within the industry to step up and take a leading role in offering an out-of-the-box Android-based stack. Here I ‘m referring to chipset vendors (e.g. Qualcomm, ST-Ericsson) and system integrators (e.g. WindRiver, Teleca) to provide complete stacks including a UI personality framework, operator-compliant packs and test suites, language packs, app store (doesn’t have to be Android Market) and post-sales software management tools. The role of system integrators can also act as a gap-filler for OEMs looking for expertise in Android phone development.

I would say Android has a window of opportunity that lasts until end-2009 to win the OEM’s support. In 2010, S60/Symbian is going fully open source under the EPL license, and OEMs (in theory) will be taking more package owner (i.e. product influencer) seats away from Nokia. So unless Android can cater to the needs of the mobile industry (and not just 3rd party developers), OEMs might have a change of heart in 2010, back to S60 as the strategic platform of choice for smartphones, which can’t be so bad after all with 200+ million phones in the market. I hope that Motorola, having banked its future on Android really knows what it’s doing.

Comments welcome as always.

– Andreas
twitter: @andreascon

(while on the topic of market insights, make sure to check out our hugely successful Mobile Megatrends 2009 series below.)

  • Pingback: Open Gardens()

  • Pingback: Tracking the Inevitable Technocracy()

  • A great post as usual my friend ..

    so the key conclusion is:


    What Android needs most is for the key productisers within the industry to step up and take a leading role in offering an out-of-the-box Android-based stack. Here I ‘m referring to chipset vendors (e.g. Qualcomm, ST-Ericsson) and system integrators (e.g. WindRiver, Teleca) to provide complete stacks including a UI personality framework, operator-compliant packs and test suites, language packs, app store (doesn’t have to be Android Market) and post-sales software management tools. The role of system integrators can also act as a gap-filler for OEMs looking for expertise in Android phone development.


    If so, I agree … Not sure about the deadline re symbian but the principle is correct

    Qs is:

    iPhone will also have the same problem – no?

    when the iphone was launched, I said that the launch itself is an anomaly(one device and one opertaor). Android has also taken the same route. Thats not the way devices have been launched prior to the iPjone i.e. you have same device(mostly) launched across many operators

    so we are seeing something new .. both in the case of the iphone and the android.


    and thats the key question i.e. will now see Palm PRE adopt the same model(start with one – or limited operators)

    If I were to be more radical – can I even say that Noikia should also exlore this?

    The model itself is not so radical.

    We are seeing a major shift now ..

    No longer is the OS etc etc a key differentiatior and with incresingly larger number of devices – maybe be device manufactures will want to take this path of choosing operators?

    End of the day – customers will drive the change ..

    finally .. from memory – windriver already had something similar. will check.

    anyway good post as usual kind rgds Ajit

  • Good post!

    It is interesting to see that in a world where features explode and more and more consumers (and companies in the telecom value chain) need more and more of a vertical end to end solution to make thing useful (like the iPhone and maybe the Palm Pre), more companies go the platform way…

  • Good writeup. I wouldn't say necessarily that Android was designed w/ PC developers in mind. Android went with standard Java. Much better than coding in C++. Yes it was designed for 3rd party developers, as Google recognizes them are the ones who will create the applications — i.e. Google understands the key ecosystem.

    I've always said the problem w/ adopting Android is the lack of differentiation for OEMs; this is so true.

    Android is sufficiently abstracted; the high-level Java classes should map well to the native implementation upper interfaces; then, it is the native (driver) implementation the hard part, as it is for any OS. By concentrating on specific reference implementations, that should help mitigate porting effort; porting Android should be less expensive than other, specially over time.

    Google will fight fragmentation, thus, it will keep ownership of the roadmap and key decisions.

    Even if Symbian OS finally goes fully open, coding on Symbian native is so much more complicated for 3rd parties – I'm not sure yet if it will attract as many developers as a Java-based development environment. But I guess developers will go where the money is regardless of complexity — the proof = iPhone (Objective C is ugly yet there are tons of apps).


  • Nice analysis.

    I'm waiting to see how the Android developer community will react when the first few post-G1 devices are released. If there are any significant incompatibilities between devices it's going to discourage the developers that thought development was going to be entirely write-once. Hopefully this won't be the case.


    [ re: ceo — Objective-C was never ugly! 🙂 ]

  • Mem

    From the standpoint of view of the consumer the UE on the android is years behind the iphone or the upcoming palm pre.

    We tend to forget that at the end there is a consumer at the end of the food chain that need to buy that device and now he is having a choice.

  • Thanks everyone for the comments – will try to address beifly as I 'm on holiday with limited email access.

    Ajit – I think Apple was the only OEM who could afford to be selective with its opertor partners, because it had a handset no one could resist. And so its strategy was to create demand through scarcity. However, I don't think many OEMs can afford that – operator promiscuity is necessary for most OEMs, if they want to maximise their addressable market and hence sales.

    Hampus – good observation. My guess is we won't see any more platform efforts. The centers of gravity – Qualcomm, Intel, Nokia, Microsoft, Google, etc all have an OS at hand as a key building block of their vertical ecosystem. I dont expect any suprises here unless there is a heavyweight newcomer in the mobile business who shakes things up through M&A.

    Enrique – I think we are on the same page. By PC developers I didn't imply C++ or Java, just developers who are building on top of commoditised hardware and software platforms – and with very different problem sets than OEMs. The best way to express this is Android was designed for 3rd party developers, whereas it should have been designed ALSO for 2nd party developers, ie OEM commercialisation partners and of course OEMs themselves.

    Allan – spot on. The G2 and the next few Android devices will be the real test. Does API compatibility ensure application portability?. Sun's Java showed this is not the case, so doubt Google will be able to do any different.

    Mem – indeed, the Google UI has lots of room for improvement. But I hear OEMs are aware of this and have already employed specialist UI technology firms for the forthcoming Android devices. Let's wait and see.

  • What the android platform offers, though, is an easy road map to downloadable applications and web browsing. Just like the iPhone, G1 users are browsing the web at 50+ times the rate of other TMobile phones in the U.S. That type of statistic can not be overlooked. This is what will drive the ARPU up for the carriers as new comers pick up these types of phones.

    We don't know why other phones aren't seeing these kinds of figures, but they are not. Hence more android phones will come to try to replicate these successes. Here's hoping the G2 exceeds expectations.

  • Charles Merriam

    Excellent work.

    The competitive landscape continues the shake-up from several years ago. The key question asked to a consumer, is "What's your cell phone company?"

    IPhone users say Apple, identifying with the equipment manufacturer and app store owner.

    Android users say Google, identifying with the software stack and app store owner.

    Most others say 'AT&T' or the name of the cellular service provider, and app store owner.

    Did you notice how the phrase begged the question?

  • Giff,

    I would put the high browser usage of the G1 and iPhone down to three main factors; a) large screen with good-enough rendition of the full web b) flat data rates that encourage browsing behaviour c) the very demographic that buys iPhone and G1 devices who are already high spenders and quite likely connected individuals.


    Thanks, and great question to ask. Indeed, customer brand affinity is moving away from the handset brand to the service provider brand – in the US it's already that way and in the rest of the world it's becoming the way due to a) Apple and Google and b) handset brands becoming service provider brands also..


  • Thanks for this blog. I am imppressed with your work. Do you not think that by providing some kind of UI technology for Java development environment will help in improving the development process. This will also help in creating differentiation on different handsets instead of changing the code of Android alltogether.

  • Thanks Ihsan,

    Android is indeed missing a drag&drop UI development tool.

    This would indeed make UI development easier, but still at an application level, and still addressed towards 3rd party developers.

    What Android also needs to better address second parties (and variant management) is a tool for rapid core app development, like the ones licensed by TAT (Cascades) and Digital Airways (Kaleido). These tools/runtimes treat the entire UI (dialler, PIM, etc) not as a set of applications, but as a huge state machine, making designing the UI a task of designing screens and screen transitions, rather than individual app UIs.


  • Andreas,

    You are thinking too much like a mobile industry guy. 🙂

    Here are Google's motivations, IMHO, for Android:

    1. Incorporate end user mobile behavior into AdSense.

    2. Push the bar for a good mobile browser so Google's vision for Gears can be realized on mobiles. (This is why they built Chrome.)

    3. Some day, evolve the click-through business model to click-to-call. You have to own the OS to pull this off.

    They are bringing a huge pot of advertising money to the mobile industry and when they start distributing it, they will redirect the mobile industry to support their vision for computing. In the process, they are going to suck the money out of the value chain for location services & mobile OS licensing.


  • Hi Erick,

    >You are thinking too much like a mobile industry guy.

    That's what I do best 🙂

    Re: your three motivations for Google:

    1. pull user analytics into AdSense and 3. implement click-to-call: both of these require Google to embed several key binary building blocks within the phone. As with Google YouTube, Gmail, etc apps, these are not in the source.android.com distro. The OEM has no incentive to include them as-is, other than through a commercial agreement (e.g. trade for Android Market, professional services support, ad rev share, etc) as per my earlier arguments

    3. Both the Android and Chrome are based on WebKit, with the difference being in the JavaScript engine. So I don't see why Chrome specifically and not another mobile-optimised WebKit variant. One reason of course is the consistency in rendering web apps, but I don't know how well Chrome can be ported to mobile.

    I also totally agree re: Google having commoditised location services and OS per-unit royalties.

    Interesting times.



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