Feeds

Google Android future haunted by fragmentation past

Is there mobile harmony in open source?

Providing a secure and efficient Helpdesk

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

Internet Security Threat Report 2014

More from The Register

next story
UNIX greybeards threaten Debian fork over systemd plan
'Veteran Unix Admins' fear desktop emphasis is betraying open source
Netscape Navigator - the browser that started it all - turns 20
It was 20 years ago today, Marc Andreeesen taught the band to play
Redmond top man Satya Nadella: 'Microsoft LOVES Linux'
Open-source 'love' fairly runneth over at cloud event
Google+ goes TITSUP. But WHO knew? How long? Anyone ... Hello ...
Wobbly Gmail, Contacts, Calendar on the other hand ...
Chrome 38's new HTML tag support makes fatties FIT and SKINNIER
First browser to protect networks' bandwith using official spec
Admins! Never mind POODLE, there're NEW OpenSSL bugs to splat
Four new patches for open-source crypto libraries
prev story

Whitepapers

Forging a new future with identity relationship management
Learn about ForgeRock's next generation IRM platform and how it is designed to empower CEOS's and enterprises to engage with consumers.
Why and how to choose the right cloud vendor
The benefits of cloud-based storage in your processes. Eliminate onsite, disk-based backup and archiving in favor of cloud-based data protection.
Three 1TB solid state scorchers up for grabs
Big SSDs can be expensive but think big and think free because you could be the lucky winner of one of three 1TB Samsung SSD 840 EVO drives that we’re giving away worth over £300 apiece.
Reg Reader Research: SaaS based Email and Office Productivity Tools
Read this Reg reader report which provides advice and guidance for SMBs towards the use of SaaS based email and Office productivity tools.
Security for virtualized datacentres
Legacy security solutions are inefficient due to the architectural differences between physical and virtual environments.