Addressing Android Fragmentation

A link from the folks who make the OpenSignalMaps app for Android has been making the rounds in the last couple of days. In the article, they reveal that they have been analyzing the Android devices that have been using their app and have counted 3,997 different Android variants of model, brand, Android version, and screen size. You can imagine the headache that causes for application testers and for mobile Web developers.

Android Fragmentation Infographic

I see a number of reasons for this plethora of Android variants:

  • It takes longer for old versions of Android OS to fall into disuse; it takes in the order of a year for a new version from Google to be adopted, updated, and tested by the device manufacturers and tested by the carriers.
  • Companies like Samsung and HTC take a spaghetti against the wall approach, creating large numbers of different devices in the attempt to cater to different customer interests. For example, I counted 34 current models advertised by HTC, with 23 of them running Android, and 5 Android tablet models. Samsung shows 144 models (!), with 54 running Android, and 17 Android tablet models.
  • Not reflected in the report, but smart-phone manufacturers using Android need to differentiate themselves from the other manufacturers also using Android. To help with this, these companies extend the base Android install with their own user interface customization layers. HTC adds Sense UI, Samsung adds TouchWiz, and other makers such as LG, Motorola, and Sony Ericsson have their own equivalents. This of course introduces additional functional differences between handsets from different vendors, not to mention bugs and performance issues.

As a consumer, I’ve looked through lists of Android devices trying to pick one that is suitable, and it’s actually quite intimidating. Compare that with Apple where your choice is between the legacy iPhone 4 or the current iPhone 4s. As a developer working increasingly with mobile, it’s intimidating from a testing standpoint. While proponents cite the level of choice that exists, that choice comes with a big cost.

From a developer’s point of view, there are a few things that would be a big help:

  • Google should update their emulator so that it simulates individual models. Right now, that’s pretty much impossible. In contrast, Research in Motion includes virtual machines for pretty much every iteration of every single Blackberry that they sell, including the variants from every carrier.
  • Google should update the Web browser in their emulators so that they also do a better job of simulating real devices. The one they have now is piss-poor, the only thing it’s good for is showing that yes, there is a web page showing. In contrast, mobile Safari in Apple’s emulators makes a very accurate representation of the real thing and can be used for testing and debugging purposes.
  • Not that this will happen anytime soon, but it sure would be helpful if handset vendors stopped taking the spaghetti against the wall approach and focused their offerings with fewer models.

Having emulators is no replacement for the real device, but who’s going to have a testbed of 4,000 devices? I would be very happy to see these things happen, but I’m not holding my breath. Still, I can dream.