Android fragmentation is a feature, not the big problem everyone says it is

When I think "fragmentation", device sizes and configurations are the least of my worries, although the tooling around this area is very poor and needs improvement. The real fragmentation issues are things involving bugs which are hard to work around, like

* Froyo having a number of NIO bugs (ByteBuffer.AllocateDirect & selectors) (which were fixed later on) * Samsung GPS driver not filling in Location.getTime() * HTC Desire and others having broken Bluetooth stacks

Or advice from Google like:

"Apache HTTP client has fewer bugs on Eclair and Froyo. It is the best choice for these releases. For Gingerbread and better, HttpURLConnection is the best choice."

I have always found Android and its tools to be extremely buggy. Then take into account you are going to have to maneuver around all of these bugs not for one version of the OS, but essentially every version put out for the past 2 years. Many bugs are from Apache Harmony, a huge pile of turd, which is defunct.

Also, fragmentation comes in other forms entirely, like the Kindle Fire, which does not pass CTS and does not have all of the android APIs (I see the possibility of Google subsidizing a low cost ASUS tablet as a move against this existential threat).

Additionally, the newly published design guidelines are for ICS and above, but most developers will target Froyo-ICS. Its quite a challenge making an app which follows these guidelines if you are also targeting pre-ICS devices. So even the guidelines are "fragmented".

I'm really looking closely at how Windows Phone does. Its becoming more difficult to write non-trivial apps for Android unless you can afford a bunch of phones to test on, or use one of the testing services like Perfecto.

But there is potentially a startup opportunity here. Perhaps someone could create a database that lets you drill down, by API, to see which phones have issues. It would be great if lint hooked into this database and gave me a list of phones to exclude in the market, if I didn't feel like working around them.

> Froyo feature set is a really good base line for most of the applications. I challenge

> you to find a new feature in higher versions that you really need to have in a general purpose app.

So, for "general purpose apps", whatever that is, Android 2.2 (which was launched 2 years ago) is great. 2 years is ages in computer land and this is a huge issue, even though the author likes to downplay this because the 2 year old software works "just fine". Android is very fragmented and if you have to develop for 2 year old software still today, that's a big proof.

> Developer tools

This whole section can be skipped when developing for iOS. Big deal, there are tools to help you develop for the chaos that is the Android flora. Just because the tools exist doesn't mean it's easy to support all these different devices.

> Developers can provide different graphics for different screen sizes

I don't have the exact number on the range of Android screen sizes, but there's much more work to this than the author implies. Just because you can doesn't mean it's easy.

> There is an emulator and UI builder that can emulate any Android version, screen resolution

> and pixel density combo

The ARM emulator is really really slow. Maybe it's picked up speed with Android x86 but when I was developing for Android the emulator was almost unusable and basically everybody's advice was to go out and buy an Android device. This will get pretty expensive pretty fast if you need to emulate the range of Android devices.

> It doesn’t matter if you prefer a large vs a small screen, a hardware keyboard vs software

> input, a 1Ghz+ quadcore vs a 600Mhz single core, a device from an A brand vs a Chinese

> copy or maybe you just want the best available phone for you specific budget.

> There will be a device available for your needs. This is only possible due to the so called

> “fragmentation”.

IMHO, sure, some people prefer larger screen or a hardware keyboard. But the rest of this paragraph doesn't make sense. Who'd want a single core rather than quadcore? Who'd want a chinese knock off instead of a brand? This is both just a question of budget. So in reality, again IMHO, I think the "featureful" difference between Android devices is much less then is purported in this post.

Just one more thing, I'm not knocking on Android as such - variety is good and Android has some features over iOS and iOS has features over Android. But having developed a little bit for both platforms, Android is definitely very fragmented and harder to develop for.

When a customer buys an Android device, rightly or wrongly they more or less expect it to behave in the same way as their friend's. Even if their friend has a SG SII and they've just bought a ZTE or Huawei. After all, that's how things (more or less) work for iOS.

What a lot of operators have found is that when they flood their network with cheap, low end Android devices (which are not adequately explained as such), that many get returned. Many of these returns are 'No Fault Found' - meaning that there was no technical fault with the device at all, but it didn't meet the customers expectations.

The argument that it was a feature would work if there were tighter minimum hardware specs for running Android, but too often fragmentation means the Android platform being misused by being loaded onto poorly equipped devices.

It might not be a fatal problem, but it does raise the barrier to entry, and it does reduce profitability for apps that are more marginal.

But this screen size and hardware is different between devices is fragmentation and is bad is a bit bullshit. If that was so bad where are all the articles says OSX is fragmented and hard to develop for, it support a large range of screen sizes (11 -> 27 inch) and both semislow and super fast cpus (and now we are not even talking windows...).

"Fragmentation" is an engineering problem that we can iron out. Bad market performance is much more complex and something that's in large part out of our control.