Open Signal’s recent post about Android fragmentation led to quite a bit of discussion on Hacker News. As interesting as questions of whether fragmentation is good or bad may be, however, most developers and entrepreneurs just want to know how to deal with it.
When we started the development of Instabridge we had read a lot online about the difficulty of building an app that works on all the different handsets out there. According to the OpenSignal report, a developer needs to deal with 10,000+ different Android devices. Strictly speaking, this is true, but as we’ll see below it’s irrelevant in practice. The same goes for many other aspects of the so-called Android fragmentation problem.
Our app is consistently rated 4 or 5 stars in Google Play and has virtually zero device related crashes, despite a development process with very reasonable time and budget constraints. In this article I describe what it takes to get there.
First of all, how fragmented is Android in reality? In theory there are 18 different Android versions and sub-versions for developers to deal with. In reality six different versions cover 98% of the Android user base. Those are:
(I use the numbering scheme since the numbers are more precise than the associated names. “Jelly Bean,” for example, refers to both
4.0, 4.1, 4.2 and 4.3).
If you’re wondering why 3.0 is missing, 3.0 was a tablet branch that never got any traction. The 3.0 designation was unfortunate, and merging the changes directly into 2.3 would probably have been a wiser choice. The 3.0 branch is now merged into 4.0, which all new tablets are running. So unless your app needs to be specifically adapted to the Motorola Xoom you can safely ignore it.
Versions before 2.2 are ancient by smartphone standards and can therefore also be ignored, just like most developers ignore iOS 3.0 and earlier. For almost all libraries exclusive to later versions of Android there are open source libraries that allows developers to use the same functionality on earlier devices.
But what about device fragmentation? Although there are over 10,000 Android devices on the market, there are really only three different screen sizes for smartphones. Those are:
- 4.7-5.3 inches (premium smartphones like the Samsung Galaxy S4 or HTC One X or phablets like the Samsung Galaxy Note II)
- 4.0-4-7 inches (entry level smartphones like Sony Xperia P)
- < 4.0 inches (tiny devices like the ZTE Blade or the Samsung Galaxy Ace that can almost be considered feature phones).
The latter category of tiny devices is the most challenging, often requiring a complete rethink of the layout if you intend to support them. Because of the limitations of these devices, however, their users don’t download apps nearly as often. This is one demographics that we have intentionally ignored (i.e. the app still works but we haven’t specifically adapted the UI), and have not yet had a single complaint as a result.
We use ten different devices from a few different vendors (Sony, HTC, ZTE and Samsung). We bought most of them on eBay and spent about €1000 in total. The good thing about this setup is that we also end up testing different processor speeds and memory sizes as well, since CPU speed and memory size correlate fairly well with screen size.
Whenever we have a new release we spend about four hours testing the new build on all the devices. In total we estimate the extra effort of fixing device or vendor specific crashes to add 10% to our development time.
Android fragmentation - worse than ever?
As we add more features and increase the user base we will probably need to test with more devices, but so far we’ve been pleasantly surprised over how smooth the process has been.
While Android fragmentation is increasing, the development time for developers is not.
Update #1: Link to the actual app for those of you who want to test it
Update #2: Discuss the article on Hacker News
Update #3: 4.0 is named ICS not Jelly Bean. #fail