The myth of Android fragmentation

Every month or so, we hear someone bleat about how fragmented the Android market has become, how Google has ceded control of Android to the device manufacturers, and how writing and testing Android software is a nightmare. This is complete nonsense.

To see how this perception might have come about, look at the first pie chart on TweetDeck’s Android beta test blog posting. It lists hundreds of distinct kinds of devices, but note the vast majority of testers favored the top 15 phones.

Now look at the second pie chart: There are more than 100 distinct ROMs, but fully half of the testers used stock Android 2.2, and another 48 percent of the testers went with the four next most popular stock Android versions.

Now look at the conclusion above the first chart: “From our perspective it’s pretty cool to have our app work on such a wide variety of devices and Android OS variations.” This is despite “the massive variety of phones and Android OS versions everyone is running.”

Friends, Android market fragmentation is a nonproblem for software developers. From a programming viewpoint, if you are using the Android SDK, you basically stick to the Android and Google APIs for 99.7 percent of what you do, pick a minimum API level you want to target, and don’t worry at all about the UI skinning that HTC, Samsung, and Motorola add. The manufacturers are responsible for making sure their devices support the standard APIs, and in fact they do, as TweetDeck’s 36,427 active beta testers proved.

In a rare case, you might want to write an app that requires nonstandard hardware lacking an Android or Google API, such as using the dual flash LEDs on the HTC Incredible for a flashlight. Generally, the manufacturers eventually provide those apps for the largest use cases, if not on the day the phone ships. For the Incredible, HTC Flashlight came with the Android 2.2 update.

In terms of QA, you’ll want to test on every device that supports your minimum API specification, but you don’t need to have every candidate phone in-house. If you’re shipping using the Android Market, you can test on all the hardware that matters by releasing free beta versions, just as TweetDeck did. Believe me, users are not shy about reporting problems when an app doesn’t work perfectly on their phones, even when the app is free.

If you have a private application, you might want to let your users know what you’ve tested and currently support, but allow them to test for you on hardware and ROMs you don’t have. If they report all is OK (especially if they’ve gone through your own complete test sequence), then you can add the tested configurations to the list. Yet another, somewhat more expensive but better-controlled approach is to do paid crowdsourced QA — for example, with uTest.

It’s not that hard, folks. Start with the biggest target, currently Android 2.2, and write your application. Test internally on three phones running 2.2: one each from HTC, Samsung, and Motorola. Release for 2.2 only and see what your testers say. When Android pads begin to come out, start testing on those, and modify your application by adding alternate screen layouts if necessary.

Now go backward in Android versions, and add work-arounds to make the application function as well as possible on 2.1. There are some good techniques for this on the official Android blog. Again test on three phones, and release with a lowered minimum version level. Keep doing this until you reach the point of diminishing returns.

How is this fragmentation? It’s nothing more complicated than we’ve had to do for different OS versions, browser versions, and screen resolutions for 50-odd years. Well, maybe not browsers, but you get the picture.

Any questions?

This article, “The myth of Android fragmentation,” was originally published at InfoWorld.com. Get the first word on what the important tech news really means with the InfoWorld Tech Watch blog.