Fragmentation or Diversity? It’s a Matter of Perspective

Points of View

It’s hard being a developer that has to support thousands of different devices, with screen sizes ranging from tiny to enormous, running multiple OS versions on all sorts of hardware… said the web developer.

Even if you only have a passing interest in developing for mobile, you’re bound to have heard about Android Fragmentation. In short, fragmentation is the onus placed on Android developers to ensure their apps work on an ever expanding array of devices encompassing variables such as:

  • screen sizes
  • screen resolution
  • device hardware specifications (i.e. RAM, processor, disk space / SD card support)
  • device capabilities (e.g. not all devices have NFC, tablets don’t tend to have phone functionality)
  • different versions of the operating system

As a developer, these variables add overhead to the whole process. Last year, the BBC revealed that their Android development team was three times the size of their iOS team. Fragmentation has often been cited as “The Achilles Heel of Android”. I’ve heard developers say “We didn’t develop an Android version because… fragmentation”. A valid argument?

Taking off my developer hat, I look at this issue from a consumer perspective. The fact that Android caters for the list of variables above means that manufacturers (original equipment manufacturers, or OEMs for short) can produce a wide range of devices to suit a wide variety of customer tastes and budgets – do I really want a phone with 6 inch screen? Do I want to buy a high-res quad core monster, or a budget friendly device for casual use? New devices (and indeed new manufacturers) are appearing every day, with a lot of emphasis being placed on growth within emerging markets such as China, Brazil and India.

Hardware sales aside, a larger audience equals more people to sell apps and services to. Even Nokia are tackling the emerging markets with an Android phone, with the Nokia X reportedly selling out in four minutes at one Chinese retailer. Although an Android phone, the device taps into Microsoft services rather than the equivalents provided by Google, and it is customised with a Windows Phone style launcher.

But how do we keep everyone happy? I thought I’d write this post as I personally believe the issue of fragmentation is largely overblown. The Android SDK is inherently designed to cater for such variety from the design phase onward; it’s not a hacky, post-production fixing exercise. Hopefully I can clear this up.

Fragmentation – How does it happen?

You’ve probably seen horrific patchwork quilt graphs like this one:


But what does this mean?

To start with, we should consider the Android Open Source Project (or AOSP for short). If you didn’t know already, Google makes the source code for Android freely available, hence it’s rapid adoption by new and established OEMs. The manufacturing cost associated of using Android lies in whether the OEM wants to use Google services (such as the Play Store), which must be licensed. In the case of the Nokia X, no such license was required; similarly, Amazon tablets provide their own marketplace.

If an OEM wishes to run Android on their devices, they will download the source and compile it against each device specification they manufacture. In our graph:

  • Manufacturers are represented in different colours, with area reflecting market share (Samsung being the most dominant player here)
  • Manufacturers are further split into different device specification, with area representing device popularity

So many specifications, so many Android binaries, so many problems!

At least, that’s what you may be led to believe. Google sets compatibility standards for manufacturers to ensure a consistent SDK, so that developers don’t write custom code for every possible hardware configuration, making this graph largely irrelevant in my opinion.

But what about different versions of the OS itself?

Like any other OS, incremental improvements of Android are released over time, bringing features such as better memory management (the main focus behind KitKat), a more fluid UI (JellyBean) and other assorted goodies.

Correspondingly, the updated source is pushed to AOSP for OEMs to compile and make available for their devices. Unfortunately, unless you have a Nexus device, you can expect a delay between when the source is released to AOSP and when it becomes available for your device; it may not even become available at all. For me, this is the true measure of fragmentation, and is displayed in more objective (And less scary) graphs such as this one:


Delays are straightforward to explain. OEMs need to compile and thoroughly test the source on their device range and this takes time. Although Android is a third party product, it’s still the OEM brand image that will be hurt if the update isn’t seamless. There may be an incentive to be first to market with the latest and greatest, but a hasty release may not be worth it if a rival OEM releases a perfect update a little while later.

Why then would an OEM choose not to release an update at all? Again, relatively straightforward – doing so could take the shine off new hardware they plan to release. This is especially true for smartphones which are generally replaced every 2 years. The choice is simple for an OEM – spend time and money creating a free update for a 2 year old device, or make it exclusive to newer hardware, providing the consumer with the incentive to spend money. This is further complicated in the US, where telecoms carriers hold sway on what updates OEMs can release for their devices, again for the same reasoning – making money.

How does Google address version fragmentation?

Google have taken a number of steps to address this issue:

  • Most new APIs are not version specific
  • The Support Library
  • All new devices that wish to use Google services must run KitKat

The first point is really rather clever. Think about the release of any new operating system. The parent company release promotional material of the new features. Again, it’s an incentive to upgrade, and so we associate new features with new versions of an OS.

In Android’s case, this model is flawed – for reasons given above, a large chunk of consumers do not have the latest version of the OS, and some run so called “legacy versions” of the OS (i.e. Android 2.3; Gingerbread). Developers would have little or no incentive to work with new features if they aren’t widely available.

Consequently, Google release most new APIs as part of the Google Services package; a service that runs on all Android devices and is updated automatically. Developers who wish to integrate features such as Google Drive, Cast, Cloud Messaging, Game services… etc. can do so knowing that all devices can handle the new APIs, regardless of OS version.


The second point mostly caters for devices running anything less than Honeycomb (Android 3.0). Honeycomb was designed for Android tablets only, and had a very different look and feel to the Android that ran on phones at the time (mostly Gingerbread 2.3 and Froyo 2.2). It introduced ActionBars, Fragments and swipeable views among other things.

The main focus of Android 4.0 (Ice Cream Sandwich) was to create a unified experience across tablets and phones, and thus a lot of the design introduced concepts in Honeycomb became the new standard for phones as well. These design libraries are not APIs, so do not ship with the Google Services package; they are tied to the OS version.

However, developers can simply import the Android Support Library jar into their projects and start using the new designs for older versions of the OS. Code written using the support library is not specific to older versions of the OS either – that is, your Gingerbread compatible app with fragments looks and behaves exactly the same on an Android 4.0+ device. Thus the need for version specific code is largely avoided.

Of course, Google do provide monthly statistics on the adoption rates of each OS version (as shown above), and it’s the developers choice to ignore older OS versions if they wish. If a user wishes to download an app that is not supported on their device, they will have to know the URL of the app as it will not appear in any search results. Furthermore, they will be prohibited from installing the app as the Play Store will display a “Not compatible for your device” message instead of an Install button. Even side loading the package won’t work.

The last point is based on “a leaked internal memo“, although it has been reported in a few places. Apparently Google is insisting that all devices released from February 2014 onwards must run KitKat. The main focus of KitKat was to radically improve memory management, allowing low-cost, low-spec devices with as little as 512Mb of RAM to run the latest version of the OS (so called “project svelte“). I’m interested to see how this one pans out.

How do developers cater for different screen sizes and resolutions?

This has been a feature of the SDK for a long time. It’s really nothing new.

Here’s a quick primer on how screen layouts work in Android – basically, each screen will have an XML file that defines the position and styling of screen components (such as buttons, labels, images…etc), much in the same way as HTML is used. Let’s say we have a screen that uses the layout “activity_main.xml”. The directory structure looks like this:


If I wanted to alter the layout for a large screen somehow (change the styling / margins, show more controls), I create a new folder “layout-large”, and add a new layout with the same name as before to it. So my directory structure looks like this:


At runtime, Android will load in the correct layout depending on device screen size.

Images work in a similar way. Let’s say I have the image “ic_launcher.png” – the directory structure looks like this:


If I wanted to use a high resolution version of the icon on higher resolution screens, I create a folder “drawable-hdpi” and store my higher res graphic there:


At runtime, Android will load in the highest resolution images that the device screen can support.

These folder suffixes are known as “qualifiers”, and the documentation on them can be found here.

Further Restrictions

If you want to take a very narrow view of supporting only specific devices, Google allows you to do this as well – you may specify which devices may download your app when uploading it to the Play Store thus:


I know that the SkyGo app is restricted in this fashion, causing some consternation among customers who don’t own one of their allowed devices (for a time the Nexus 5 was not compatible, even though the Nexus 4 was). This may be that they only release their app for devices they have tested it on, but the cynical side of me thinks they are being lazy here.

A Rich, Ever-Expanding Ecosystem

Here’s a list of Android devices I own:

And some I’d like to get my hands on:

A wide range of devices and form factors, all running Android, all ready to consume services. Fragmented? Maybe. Diverse? Definitely.



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s