Google's Andy Rubin, VP of Engineering, just stepped up to challenge media reports the Google was defending Android against fragmentation. Rubin says "no." And perhaps that's actually the secret to Android's success.
In a post titled "I Think I'm Having a Gene Amdahl Moment" on the Android Developers Blog, Rubin writes in a "spirit of transparency and in an attempt to set the record straight" about the "misinformation in the press about Android and Google's role in supporting the ecosystem." Directly refuting many suggestions that Google was getting protective about sharing Android in order to prevent worse fragmentation--and possibly even writing strict hardware specs centering on ARM chips for Android 3.0 Honeycomb--Rubin says none of that is happening. There's no "'one size fits all' solution" and there are no "efforts to standardize the platform on any single chipset architecture."
Rubin stresses Android manufacturers are "free to modify Android to customize any range of features" which lets them "support the unique and differentiating functionality of their products" across a diverse range of use cases that even Google thinks deems miraculous. There are basic compatibility requirements, and the anti-fragmentation program has "been in place since Android 1.0 and remains a priority" so that Google can "provide a great user experience."
He also mentions, however, "it would not be realistic to expect Google applications--or any applications for that matter--to operate flawlessly across incompatible devices." He made this point to highlight that Android hardware sellers must comply with those basic compatibility requirements, but inadvertently highlighted that if you're an Android device owner there are always going to be some situations where you can't run an app designed for a different flavor of Android or a different device.
So what can we conclude from this? Google isn't extra-specially defending Android 3.0 Honeycomb from fragmentation on different tablet devices. It's not withholding 3.0 from OEMs to specialize the OS toward a tightly-controlled ARM architecture. And all its existing plans to prevent fragmentation are just fine.
This last point, some would argue, is in direct conflict with experience of both Android users and developers around the world. A recent survey even suggested 86% of Android developers--people Google really needs on board if it's to expand its platform to challenge the iTunes App Store dominance--are unhappy with the way fragmentation messes with their code and their user-client's satisfaction.
So what we're actually left with is a bit of a mystery--centered on why Google really does seem to be hanging on to 3.0 and not sharing it with other tablet makers. Is it really all about a big tweak to the OS to make it much more tablet-friendly, and a "damage control" maneuver to prevent too many consumers becoming disgruntled at a poor user experience? Does Google really not care about fragmentation at all?
That actually may be the answer to all of this. Several recent surveys--including a brand new one from Gartner--see Android moving to seize the greater part of the mobile OS market inside just a handful of years. The platform has already seen incredible growth, leading some to inaccurately predict the demise of the iPhone, and that's even despite the fragmentation that gets so many people angry (and which Rubin is half-denying, or half-excusing). Precisely because it's free and companies can customize it the way they want, Android is appearing on more and more devices in more and more markets--from PMPs to in-car systems. That's all good for Google, which gets exposure and rich user data for advertising purposes from all of this activity.
Maybe we can see another hint in new data about Google's plans to bring ChromeOS to tablets. Perhaps Google thinks it can let Android run free on smartphones and some tablets, because actually Chrome may eventually become a more powerful UI for the tablet class of mobile device.
Image with apologies to the fab Chopshop T-shirt.
To read more about Google, click here.