Android Wobbly Shaky Ground MobilestanceWhat’s Behind What Some View as Android’s Growing List of Self-Inflected Problems. Conspiracy? Complacency? Or Raw Genius At Work?

At first glance, it might appear that things are going pretty well for Android.  The free-to-license mobile OS has quickly become popular among many cash strapped mobile OEMs (original equipment manufacturers). Heavyweights such as Samsung, Sony Ericsson, LG and Motorola, along with handset newcomers Garmin and even Dell (hold for laughter) have all announced plans to develop handsets for the Google-run platform.

Supposedly, T-Mobile even managed to sell roughly one million Android-powered HTC G1’s last quarter… a respectable, yet not exactly iPhone-worthy performance (but to be fair, Apple and AT&T set an impossibly high standard with iPhone 3G, accomplishing in three days what Android did in three months – who knew AT&T would deliver on their promise of “Raising the Bar” so literally!).

Yet a quick peek below the surface reveals a conflicting scenario emerging for everyone’s favorite “Little (open-source) engine that could.”  Depending on your point of view, the OS is either plagued with systemic flaws, or designed with a profound sense of Machiavellian perfection. The exceedingly real threat of viruses, worms and other forms of malware, combined with a system seemingly “design to fragment” (read: seriously frustrate application developers) leaves one wondering if (as the conventional wisdom would have you believe) that Android’s model scales so well, and its backers so powerful and smart, that it can’t fail to become a serious contender over the long term…  or what we’re really looking at is nothing more than “Yet Another (seriously flawed) Google Beta Product.”

The issue of Android’s well-publicized “open door” security policy reared its pathogenic head again last week in the form of an all-out malware scare, and although the jury’s still out on whether or not the now infamous “MemoryUp” application did (as was accused) take over a user’s mobile, spam out its contacts and wipe its memory, or is just (as was suspected by cooler heads), merely a poorly designed, near universally-panned app… the frightening fact remains that the only thing standing between us and just such a dark reality is the relatively low profile group known as the Android Security Team.

Unfortunately for Android users, this team (of which whose public presence appears to consist entirely of one message board post dated August 18, 2008) seems to operate in a decidedly passive capacity: rather than vigilantly seeking and tracking down security flaws wherever they might appear in the system, the model works more like a ticket-based complaint counter, addressing user-submitted security threats when (and only when) the Goog Squad is alerted to their presence by the public.  It would be as if the local police force was replaced by an automated 911 system (and we all know how efficient that system can be). While it wouldn’t be 100% accurate to say that “no one’s minding the Android App store” (er, market) – there’s far more truth in that statement than many are willing to admit.

Moving on, the other significant issue facing the Android system – that of the looming threat of OS fragmentation – has (unsurprisingly) garnered scant attention in the trade press.  I say “unsurprisingly” as so far the threat of OS fragmentation is fairly complex and has yet to be an issue as, with only one Android handset on the marketplace (so far) – the HTC G1 – there just isn’t that much of a marketplace to fragment.  That said, this issue seems to have some real legs, not to mention real intrigue, and is, in our opinion, very likely to seriously impede Android application development over the long term.

Before we get into all the wide-eyed intrigue and half-baked conspiracy theories, a little background information on the subject of OS fragmentation is in order.  At its core, the issue revolves around the fact that Android, as an open source software platform, freely publishes its source code to the world under the general assumption that under “the eyes of the world’s” constant viewing, tinkering, and deploying – the software will ultimately become more robust, stable and efficient than any system created and maintained by a finite number of (paid) employees.  As is the case with a great many subjects, the devil is in the details.  It seems that when Google formally launched the Android project back in late 2007, it chose the to advocate a licensing model (Apache) whereby third parties could maintain private ownership over any modifications made to Android’s publicly-available source code, and would not be compelled (as in other open source licensing models) to turn over said software modifications or enhancements back “to the public domain” – so that (among other reasons) these modifications could (potentially) be incorporated into future versions of the software… thereby making the whole system more unified, and less “fragmented.”

So here’s where things can really get messy.  As said, mobile handset manufactures designing smartphones are turning to Android in large numbers, driven mainly by its price point (free), as well as its many innovative design features.  That said, not all of these “Android” devices will be running the same version of Android, as handset manufactures will be under extreme pressure to modify Android in order to maximize the performance of the particular hardware components making up each of their individual handset models.  This means that Android developers will soon have to create multiple versions of each Android application they develop in order to insure that their apps will run correctly on each “version” of Android in the marketplace (i.e. all the different handsets running “Android”).  This time-consuming and labor-intensive process, known to overworked software developers the world over as “porting,” significantly drives up the cost of software development.  Ultimately, Android developers will need to limit the number of Android handsets they can support as simply a matter of cost/benefit.  This well-known problem has been identified as one of the primary barriers that has held up mobile software development to date, as the current crop of Java, Symbian and BREW feature phones are simply fragmented beyond belief.

We’ve already seen the beginnings of fragmentation in the Android system, as differences in handset specifications play out over the various geographic regions – and with the sheer number of players about to enter the space in the coming year this issue is bound to accelerate dramatically.  That said, it is inevitable that that this scenario will negatively impact the development of innovative, new applications for Android over the short term.  The only real question is to what extent will Android innovation be stymied?

What makes this issue to interesting to many is that, due to advocating the Apache licensing model for Android, Google seems to be actively encouraging Android fragmentation.  Ironically, this apparent paradox was first identified by Sanjay Jha, Chief Operating Officer of Qualcomm’s chipset division (ironic in that Qualcomm is one of the founding members of the Open Handset Alliance and the Android initiative!)  who, in a  Register story that emerged out of last Spring’s CTIA conference, was quoted as saying that “Google wants fragmentation in the [mobile] industry.”

Here’s where the conspiracy theories start kicking into overdrive.  Keeping all of this in mind, some have speculated that – in a thinly veiled strategy against its old desktop rivals (Microsoft), Google would potentially benefit from Android fragmentation in that it would be prohibitively expensive for any one developer to dominate any fragmented system with a mainstay-like platform such as Microsoft Outlook or Office, both “heavy clients” that rely on sophisticated software applications running on the device’s (local) hardware (e.g. the desktop PC, or the mobile handset).   A fragmented system would ultimately favor companies like Google that favor thin client / “cloud computing” models (e.g. Gmail and Google Docs), where all the application’s heavy lifting is done on the server side (via the network), rather than on the client side (i.e. the mobile handset) – in this case the actual applications on the client/handset side usually reside in nothing more than a decent web browser.  All of this poses a very intriguing question: Could Google be subtly sabotaging device-side Android application development in favor of its browser-based / thin-client model?

Bringing this post full-circle, it is possible that both these two issues (fragmentation and security) may cancel each other out, sort of… again, ultimately resolving in Google’s favor.   The theory goes a little like this:  The folks that write software viruses, worms and other such programs do so primarily for the notoriety that comes with affecting many systems/users all at once – either with benign or malicious intent.  Platforms that don’t scale simply are unappealing to most virus writers.  Similar to the natural virus protection afforded by using a niche desktop system such as a Macintosh (sorry guys, I love ya but you’re still using what I would consider a niche product), few developers will waste their time writing a virus that only affects a (relatively) small number of people, when they can get better “bang for the buck” elsewhere.  The same forces that make it prohibitively expensive for (most) application developers to support a wide range of devices in a fragmented system will also similarly affect virus writers.  In affect, by encouraging fragmentation, Google could be enhancing Android security while simultaneously crippling many of its former rivals in the desktop space (or is this giving Google just a little too much credit?).

Thoughts?  If you have an opinion, share it… as there’s nothing like a good conspiracy to spice up the industry some!

j


10 Responses to “What’s this… Android on Shaky Ground?”

  1. #1 Android: does it scale? | The Mobile Web Tablet says:

    […] Stance has a longer post on the subject, even suggesting that Google would benefit from fragmenting the OS as it would move […]

  2. #2 Andrew Ebling says:

    That’s certainly an interesting line of thought and there is certainly a chance things may pan out as you have predicted. However I don’t believe it was Google’s intent from the start, for the following reasons:

    – The Android Developer Challenge shows at least some level of commitment to stimulating native application development on the platform.

    – If Apple eventually broke down and opened the iPhone/iPod Touch up for native application (having pretended initially that web/thin client was the only development environment needed), why would Google deliberately plan to do something which would drive their own platform back in this direction?

    – Google’s own support of the iPhone through native application development shows that they still think there is (currently) a need which is fulfilled by native applications over web or thin client applications.

    Personally, I think if Android becomes successful enough to survive long-term, we’ll see Google introduce JSR-style standards to try and address fragmentation problems.

    I think the success of the platform hangs on whether Google can prevent fragmentation from affecting the overall user-experience, rather than whether they can solve the problem for developers. Given how high the iPhone has raised the bar in terms of user-experience, this will be the biggest challenge Google face going forward.

  3. #3 Tane Piper says:

    I think there may be some truth to this, although I don’t think it will be in the web browser. Google have recently published their findings and a new API based on OAuth – allowing web and “desktop” applications to access your contact data, amongst other things. Over time I expect them to add more and more services to this, so that google becomes our main data provider. Appengine too I think is part of this plan, allowing developers to create data on google services and tie it into your google account.

  4. #4 SOSiPhone.com (Le Blog) » Archive du blog » Android, plate-forme qui va fragmenter le marchè ? says:

    […] d’incompatibilité au niveau des applications présentes sur l’Android Market. Le billet qui m’inspire celui-ci appel ça “la fragmentation” est pour lui c’est inévitable. Malheureusement en […]

  5. #5 C. Enrique Ortiz says:

    True that Android adds to the fragmentation game/issue. And that device manuf will do their own things. But there is where the OHA comes in — OHA defines the “official” Android. In addition, Android is not fully open yet so Google still has a good grab on what Android is/means.

  6. #6 Google Losing Focus on Android SDK In Favor of Mobile Web Apps’ Offline Functionality? (Part II) | mobilestance.com says:

    […] What’s this… Android on Shaky Ground? […]

  7. #7 Ajay says:

    You’re giving them too much credit, there’s no way that they want to hobble the desktop through fragmentation. Besides, it’s not like mobile devices can handle that much computation anyway so the more you offload to the server through thin clients, the better. Fragmentation is a given in all technology, you’d like to avoid needless fragmentation but innovation only comes in through people trying new things and “fragmenting” a platform. The alternative is Windows, where only Microsoft can decide what innovation is worthwhile, and the resulting stagnation. I think it’s to Google’s credit that they chose such a liberal license like Eclipse and they will reap the rewards for doing so. As for security, they’ve clearly not been as proactive as one’d hope but with an open source OS, they can now have many security firms looking for such flaws. If they put up some kind of bug reward program, I’m sure they can get plenty of people looking for these holes for them.

  8. #8 Alexander4 says:

    Need cheap generic ABANA?…

  9. #9 Frederick says:

    .

    thanks for information!!…

  10. #10 max says:

    .

    thanks for information….

Leave a Reply

For spam filtering purposes, please copy the number 5462 to the field below: