Sep

7

Android Device Fragmentation – Is it a Storm in a Teacup?

Mark Stephens

There is a growing storm amongst developers about device fragmentation with the Android handset, so we threw a monkey’s tea party here at Monkeybin and posed the question - is it really just a storm in a teacup?

There has been a lot of heated talk in developer circles in the past 12 months or so about coders having to support "thousands of different android phone hardware and screen sizes"; it is often compared to working with the iOS platform, which is generally seen as child’s play in terms of coding compatibility.

And the noise seems to be getting louder. This graphic shows that 86 % of 250 working developers surveyed by geek.com and published in April this year, view Android fragmentation as a “problem” for them and over half consider it a serious problem.

It is not particularly surprising that the issue has come about.

The Open Handset Alliance, which controls the Android operating system, is a consortium of 80 hardware, software and telecommunication companies – there is no single Android “voice.”

Write once, run everywhere

Basically, developers like the “write once and run everywhere” concept because it means less work writing different versions for different devices. Device fragmentation creates more work, there’s no doubt about it, but isn’t it part of a developer’s job to combat this?

Perhaps partial fragmentation is the price developers have to pay for the “open license” Linux-based approach that has helped to drive the rapid growth of Android and to create new devices and embrace so many software customizations. The problem also exists with Linux-based desktop applications but it is exaggerated with mobile devices.

We feel that it is part of our job as programmers to pay this price; we should set the parameters correctly when we set out to develop an app for the Android platform. We need to decide on 3 basic areas:

  • Minimum screen resolution
  • Minimum Android version
  • Hardware capabilities

If we look at the Google Android stats, we see that very few of the 100 million plus people using Androids are using the older versions.

That really only leaves two major problems for coders to concentrate on then – screen resolution and hardware capabilities, such as the processor and graphics powers of different versions.

Stories on fragmentation are dramatic and they drive traffic to pundits’ blogs, but they have little to do with reality. Fragmentation is a bogeyman, a red herring, a story you tell to frighten junior developers.

Google aims for basic compliance

When it comes to the hardware Google aims for basic compliance and compatibility by forcing vendors to sell units that stay within certain pre-defined boundaries and not deviate from the default code base to any great extent. So almost all mainstream Android devices are fairly standard and offer the same user experience, with actual application compatibility not usually much of a problem.

Enhancing compatibility and minimising so-called “fragmentation” further could be done at a cost of slowing down the development of the Android platform. Do any of us really want that outcome?
This would present fewer opportunities for developers, which would be a new concern for us, and it would be detrimental to the competitiveness of the Android brand overall. Taming the beast may also bring the beast down!

Perhaps our conclusion that the whole Android fragmentation debate is an overblown "storm in a teacup” won’t go down well with some other developers but our advice would be to stop the moaning and get on with the programming, because it’s partly the nature of the beast we are working with! The advantages of working on the Android platform still outweigh the disadvantages.

We’ll leave the final word to Google’s Android compatibility program manager, who said last year:

Stories on fragmentation are dramatic and they drive traffic to pundits’ blogs, but they have little to do with reality. Fragmentation is a bogeyman, a red herring, a story you tell to frighten junior developers.