[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.)
[slideshare id=1071449&doc=mobilemegatrends2009visionmobilenew-090226011714-phpapp01]