Android's bane: fragmentation blues

Android's rapid evolution and growing popularity may bode well for its future, but this evolution is also contributing to a major problem: developers writing for Android must cater for several different versions of the operating system, each with its own features and idiosyncrasies.

Currently, Google is offering SDK downloads for seven different versions of Android: 1.5 (Cupcake), 1.6 (Donut), 2.1 (Eclair), 2.2 (Froyo), 2.3 (Gingerbread), a bugfix 2.3.3, and 3.0 (Honeycomb). By the time the mooted 'Ice Cream Sandwich' bows later this year, developers will face the prospect of writing apps to accommodate eight different versions of Android.

Throw in a broad range of device designs and resolutions, and the situation is complicated. "For developers, the biggest issue with Android is fragmentation between OS generations," says IDC’s Mark Novosel. "It's an issue; some apps may not show all the elements on a low-resolution device, and others may just not work altogether."

To complicate the situation further, Google has chosen a different path to Apple – which has a relatively high base of users on current versions because it controls the upgrade through its syncing process – by giving telcos far more control over the Android upgrade process. This has left many Android users waiting far longer for new versions than they – and developers – might like: Google may have published the Froyo SDK in May 2010, but it took Telstra 11 months before it made Froyo available to users of its HTC Wildfire smartphone. By contrast, Telstra users of the HTC Desire smartphone were given access to Froyo in October 2010.

Other carriers have been equally sporadic in their support for new versions of Android, which has led to a less-than-optimal situation where a significant portion of the market remains well behind the feature curve. Worse still, many users are caught in dead-end arrangements as telcos simply never get around to providing them with an upgrade.


Rooting the phone and running the upgrade themselves is of course an option, but this is a technical solution requiring users have a degree of knowledge on which developers simply cannot rely.

This has very real implications for users: for example, it's well and good for Google to have just released Android 3.0, then point out that a vulnerability recently exploited by 58 malware-carrying Android apps has been fixed and only affects operating system versions 2.2.1 and below – but when 97.3 % of your users are running a version of Android that falls into that category, you've got a problem.

This has very real implications for developers, who need to shape their apps based on the capabilities of the devices they're likely to encounter in the field – and not just rush to take advantage of the latest features as Google adds them. Even though the Gingerbread SDK was released in December 2010, for example, at current adoption rates it could still be months before developers see enough of a market to actually implement its new features – including support for SIP VoIP telephony, WebM/VP8 video playback, new audio effects, better garbage collection, a download manager, ext4 file system, and more – in their apps.

In the meantime, the easiest solution is to do version checking and work around specific features – but this can be a real consideration for people trying to build their apps to work a specific way. "When we develop a proposal for a company we have to say that we're going to support particular devices," says Daniel Bradby, director of Android and iPhone development house jTribe.

"That information coming from Google is invaluable. But it's very rare that we have code that says: 'If it's version 1.5 do this, and if it's 1.6 do this'- we have to adjust our development style by using layouts that can stretch and shrink, and allow for different screen sizes. It's all about development style."