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.

  • 10
    Apr
    2009

    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]

    visionmobile_android

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



    Andreas Constantinou

    Andreas Constantinou

    As Managing Director, Andreas oversees the growth and strategy of VisionMobile. He has twelve years experience in mobile, having worked with the top brand names in the mobile industry including Telefonica, AT&T, Telenor, Vodafone, Deutsche Telekom, MTS, Nokia, Sony, RIM, HTC, Qualcomm, Ericsson and Microsoft. Over the last five years, Andreas has grown VisionMobile into the leading, most respected research firm on telco economics and developer economics, with a client base and reputation that out rivals companies many times the size.

Ajit Jaokar

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.

yes?

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

 
10Apr
Hampus Jakobsson

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…

 
11Apr
C. Enrique Ortiz

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

ceo

 
12Apr
Allan MacKinnon

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.

-ASM

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

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

 
13Apr
Andreas Constantinou

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.

 
13Apr
Giff Gfroerer, i2SMS

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.

 
13Apr
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?

 
17Apr
Andreas Constantinou

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.

Charles,

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

Andreas

 
20Apr
Ihsan

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.

 
24Apr
Andreas Constantinou

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

 
24Apr
Erick Eidus

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.

-Erick

 
28Apr
Andreas Constantinou

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.

Andreas

 
29Apr

Vision Mobile Blog

Distilling market noise into market sense

A Game of Ecosystems: Measuring ecosystem performance VisionMobile - Game of Ecosystems

[How do ecosystem economics shape the mobile competitive landscape? What are the key performance indicators and how should app ecosystem…

Continue Reading
The Mediatek Phenomenon: the new smartphone disruption The Mediatek Phenomenon

[The next disruption in smartphones comes not from the power struggle between Apple, Google and Amazon, but from silicon. Guest…

Continue Reading
[Infographic] Developer Economics 2013: Dev tools are the foundation of the app economy DE13_preview

We’d like to present our latest infographic, based on the latest Developer Economics report – themed around dev tools. This…

Continue Reading

Vision Mobile Research

Analytical reports on emerging solution markets

Developer Economics 2012 Developer Economics 2012 - VisionMobile

Welcome to Developer Economics 2012, the third in the report series that set the standard for developer research. This report focuses…

The 100 Million Club Preview100Million

The 100 Million Club is a watchlist tracking the shipments of the largest handset manufacturers and mobile platforms. The current…

Developer Economics Visualisations Visualisation_sample

The Developer Economics Visualisations are interactive graphs, based on unpublished data from our Developer Economics 2012 research. We have created…

Vision Mobile Strategy

Market Sonar MarketSonar_ill

Market Sonar is a customisable reporting service, based on Big Data from all major app stores. We deliver monthly, quarterly…

Report: Telco Innovation Toolbox Telco_web

Telco Innovation Toolbox showcases 10 economic models on how Telcos can manage disruption and reinvent themselves. This report, produced in…

Telco Innovation Toolbox VM029 - SEBroc_V0.5_HR-1 copy

“Telco Innovation Toolbox” is a strategy workshop introducing the new economic thinking necessary for successful innovation by telcos. Aimed at…

Privacy Policy

1. Introduction

VisionMobile Limited (referred to as “VisionMobile”, “we, or “our”) is committed to protecting the privacy of visitors to the VisionMobile web site(s) together with all related surveys, discussion forums, directories and databases. This privacy policy explains how we collect and use the information we collect about you.
By accessing and using this web site, you agree to the terms of this privacy policy.
As used in this Privacy Policy, the term “Personal Data” means data such as: your name, mailing address, e-mail address or other personal information that may be supplied by you or collected about you. We hope that this Privacy Policy helps you understand what kind of Personal Data, if any, we collect at this site and how we handle and use any such personal data after collection. Please note that we may provide aggregate statistics about our surveys, sales, traffic patterns, and related site information to reputable third parties, but these statistics will not include personally identifiable information (such as name and email address). VisionMobile is committed to protecting your privacy and does not engage in the practice of selling or trading Personal Data to other companies for promotional purposes.

2. Personal Data Provided by You

To respond to your questions, fulfill your requests or manage our online Surveys, it may be necessary to ask for or obtain Personal Data. If you provide us with any Personal Data, we may use it to respond to your requests or manage our surveys. By providing information to VisionMobile through this Site, you acknowledge and consent to the collection, use and disclosure of personally identifying information of the type and for the limited purposes described in this Privacy Policy.
If you place an order for a product, request a service or submit content to this site, we may need to contact you for additional information required to process or fulfill your order and/or request. Unless compelled by applicable law or administrative or judicial order, we will not provide this information to a third party without your permission, except as necessary to process your order, fulfill your requests, manage interactive customer programs or, if you are a corporate user, enable administration of access and usage of this Site by authorized personnel in your organization.

3. What type of information is collected?

To provide you with our Services and/or Products and to collect your views via our online surveys, we collect certain personal information about you. The information we collect may include, but is not limited to, your name, address, email address and work details.
We do not store credit card or debit card details. If you have given us your credit card or debit card details, we will only use this information to process your order and we will delete this information once your order has been completed.
We do not collect any sensitive personal information such as information on your racial or ethnic origins, political opinions, religious beliefs, trade union affiliations, sexual life, health or criminal history.

4. How is information collected?

We may collect personal information about you from the following sources:
4.1 Personal details registered by yourself in relation to VisionMobile online surveys.
4.2 Personal details registered by yourself in other ways e.g. via our website feedback forum or our Blog
4.3 Information about your visits to our web site(s);

5. How long is the information retained by us?

We only collect information which is necessary for the operation of our web site(s) and for the provision of our Services. We will not keep your personal information for longer than necessary to provide the Services or as required by law.

6. External Web Sites

This privacy policy only applies to our web site(s). Our web site(s) may contain links to external web sites. Please note that we are not responsible for the privacy practices of other web sites. We recommend that you check the privacy policy of any other web sites you may visit through the web sites.

7. Changes to Privacy Policy

We may amend this privacy policy from time to time. If we make any changes we will post them on the web site, so that you will always be aware of the way we use your personal information.
terms of use.
The contents of the VisionMobile Forum are licensed under a Creative Commons Attribution 2.5 License. The contents of the downloadable papers published through this website are licensed under the terms specified within each paper. The remaining contents of this website are licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 License.

8. Cookie Policy

Cookie Name Info URL Info
_vm1 VisionMobile The purpose of this cookie is ensure that a user is authorized to download the report . Vision Mobile does use the data stored in this cookie in any other way.
_prli_click_? Pretty Permaling The purpose of this cookie is to log information from the Pretty Links Lite Plugin in order for the plugin to know that the user has clicked in the pretty link of the (id=?) to go to the VisionMobile website.
mp_2dccbf28670dda1c8b77def198be2f89_mixpanel MixPanel The purpose of this cookie to use mixpanel to identify the mixpanel user to track the flow of the visitors from page to page. No personal or any other private information is captured.
(a)_utma
(b)_utmz
(c)_utmb
(d)_utmc
Google Analytics (a)This cookie tracks the number of times a visitor has come to www.visionmobile.com including their first and last visits.
(b)This cookie tells VisionMobile from where you, the visitor, were referred to www.visionmobile.com
(c)This cookie is used to determine the length and time of your visit to www.visionmobile.com
(d)This cookie works with _utmb to determine the length of your visiting session to www.visionmobile.com and when that session has ended.
VisionMobile does not use the data stored in these cookies in any other way.
(a)__qca
(b)mc
Quantserve (a)The _qca cookie may use your computer’s IP address, pixel code, referring HTTP location, current HTTP location, search string, time of the access, browser’s time, any searches made on the applicable website, and other statistics” in order to “analyze Log Data from different websites and combine it with other non Personally Identifiable Information to produce the Reports that are made available on the Quantcast.com Site, to enable web publishers and advertisers to deliver audience segments that are appropriate for their products or services.
(b)The mc cookie set by Quantserve is related to advertising, and may track your behaviour on the VisionMobile website.
PREF Google cookie This cookie remembers users basic search preferences. The Google “PREF cookie” is used to remember our users’ basic preferences, such as the fact that a user wants search results in English, no more than 10 results on a given page etc. Expiry is set to 2038 in order to preserve user preference information. See here for more information.
Please enter your email to receive weekly updates from the VisionMobile blog
I also want to subscribe to the monthly newsletter, with updates on VisionMobile news and research (you will receive a separate email for this list, please subscribe to both to receive the newsletter and blog updates)