Google Android future haunted by fragmentation past

With four billion connected mobile phones on the planet - compared to one billion PCs - handhelds offer developers the mother of all opportunities: ubiquity and mass market.

But the reward comes at a great price: market fragmentation, thanks to so many different devices using so many different hardware configurations.

To bridge them, we've had Java 2 Micro Edition, CLDC, MIDP and the OSDL's Mobile Linux Initiative that promised to abstract away the differences in hardware design or provide a common set of APIs that worked on a large number of platforms. Offered as the next "big answer," they've invariably compounded the problem by adding to the infinite soup of API configurations.

Google's Android has the potential to solve this, with an open-source code base that theoretically keeps people honest through shared development and a sense of mutual self interest. And yet Android looks as if it's already starting to succumb to the age-old prospect of fragmentation.

Motorola is this week expected to follow HTC, Samsung, LG, and Huwai in delivering an Android device. The touch-screen Morrison is due to be announced at Mobilize 09 in San Francisco, California, and The Reg will be there. HTC, meanwhile, plans to update its Gphone line with the cheaper HTC Tattoo.

Handset makers like Motorola and HTC and carriers such as AT&T and Verizon have historically implemented different APIs in the underlying software on a phone, like J2ME, deliberately to enable different customer-facing features - no matter that it killed application portability. Indeed, this has been seen as a positive plus in the world of telecoms because it prevented developers and customers switching and provided lock-in.

Further complicating the matter is the sheer diversity in hardware architectures - size, chipsets, screen, location-based features, camera phone - that demand different APIs.

It's early days for Android, but already there are issues as the preliminary handset makers diverge from each other and with Google's own publicly available open-source Android code base.

Like HTC, unlike Samsung, Motorola is believed to be implementing its own interface. It's called Blur. Such is the difference between Blur and the default Android interface it's understood Google is not helping Motorola on the customization work. If Motorola had used the regular Android interface, Google would have let its engineers work with Motorola.

Motorola did not respond to our questions at the time of going to press.

The question of Android's fragmentation surfaced recently, at the O'Reilly Open-Source Conference (OSCON). Google's open source programs manager Chris DiBona was asked what - if anything - could be done about the difference in code that goes into the open-source Android project and companies' own implementations.

DiBona acknowledged the problem comes when companies want to introduce a cool, new feature but don't want to telegraph it before launch. How do you not put a feature in the code that has implications further down the stack without stopping the project, which is supposed to be an original representation of what the phone is? DiBona reflected.

"It is going to get better," DiBona promised. "Application developers and people who are writing native libraries. I think they are in good shape with just the SDK.

"My goal, and the goal of my team and the Android team is to make those deltas get smaller and smaller and smaller to the point where people who are playing off the Android open source stuff are really happy. They can build images very easily. They can build custom images very easily. They can port to platforms very easily. And that's going to take time.

"We think it's really important that we spend a lot of our time trying to reduce fragmentation from an the application stand point - so when you code the G1 it'll also run on later platforms from Sony Ericsson and Motorola and all the rest - and that's a huge challenge," he said.

Based on past experience, it might be realistic to find a workable compromise to suit as many of Android's users as possible instead of cooking up a definitive answer.

Either that or it'll be fragmentation as usual for Android regardless of how open the code base is. That is, after all, what the telco industry does best. ®