Much is said about the Android platform’s fragmentation problem. However, the fact that there are a lot of politics and conflicts of interest at play creates an echo chamber that is difficult to wade through – especially if you reach articles by websites with an obvious bias.

The reality is that fragmentation is a serious problem but not in the way most people think. Having devices with different features – such as different screen sizes, or additional hardware – is something that can easily be dealt with by using conditionals and proper, flexible UI solutions; it is something that requires more testing time, but also nothing Flash developers hadn’t had to deal with in the past, for example. This is obviously exacerbated by the amount of different devices already available on the Android ecosystem, but developers for other platforms, such as Windows 8 and iOS, will have to deal with the same problems as soon as the number of device models supporting it reach a certain number and start spanning different sets of features (e.g. games on iOS having to deal with different resolutions based on the new iPhone screen densities, or whether they can use a gyroscope or not).

Rather than a problem with hardware differences in different devices, the real problem with Android is the OS version fragmentation problem due to the considerably slow adoption of OS updates. For developers, it means that if they want to reach the majority of the users out there, they need to develop for (at least) Android version 2.3.3, a version that was released in February 2011. And that only gives them roughly 60% of the market out there; if they want to increase their reach to about 90%, they need to use version 2.2, which was released in May 2010.

This creates a problem because the Android system has changed considerably in the last few iterations – it’s now on version 4.0.3. Many of the best packages – like Fragments, Renderscript – were made available after version 2, as have many additional features, such as hardware accelerated 2d elements, multicore support, and UI and speed enhancements. When you’re stuck with an older version of the system, it means you’ll have more trouble doing something (commonly having to recreate a feature that’s already available on a newer version of the system) and end up with a result that’s less than optimal, just because the system is not as optimized as it could have been.

It’s no surprise that Google Chrome for the Android was released for the latest version of the system – a version that only runs on 1% of the devices out there: it was probably a lot easier than creating something for older versions, and performance should be better. But even though this update should start being released soon to many existing devices, it should be at least one year until it reaches any viable penetration to warrant Android 4 exclusive releases.

As a developer, it’s especially sad reading the reference site and finding a feature you want, but realizing you cannot use it because it’s only available on a version of the system that’s newer than the one you’re targeting. Even doing simple stuff like setting the alpha of a UI element requires version 3.0 of the system. There are workarounds, but they’re more painful than they should be.

Luckily, one (almost unspoken about) solution to this problem of lack of updated libraries is the compatibility package. Google realized the OS version penetration problem and, as such, packaged ported versions of some libraries (that would normally only be available on later version of the system) into a library that can even be used by version 1.6 of the system (which means “API Level” 4). One especially useful class is the ViewPager, a class that I wish I had discovered sooner. This solves many of the problems a developer has to deal with, but the lack of certain features – like easy hardware acceleration for UI elements – are still saddening.

The Android system is ever evolving. The software itself is getting better by the day; however, if you’re stuck with an old version, it can be a pretty painful experience. Using the compatibility package is the least a developer in that position can do to keep his or her sanity while developing a new application, but I can only hope that device sellers and phone providers will get their act together and speed up deployment of new Android versions. I’m not very optimistic; even with the Nexus line of phones – which would normally mean clean, Google-controlled Android versions – updates can be painfully slow and, many times, not even available. The fragmentation problem, manifested in the form of version lag, is very real, and it’s not going away.

Update (29-February-2012): here is a great post analyzing the version fragmentation that the Android ecosystem suffers from.