Android has recently become the majority operating system on mobile smartphones today, and for good reason: it’s an open, incredibly versatile mobile OS that can work on a vast majority of different types of phone hardware (or, in the event it doesn’t, be programmed to do so). This has enabled it to be the OS of choice for these vendors, and so far the market and the people have been extremely amenable to Google’s mixture of open-source, versatility, and user-friendliness.
With this open structure and versatility, however, comes a price: as more and more vendors push out their own versions of Android with their own bells and whistles (Motorola’s MOTOBLUR, HTC’s Sense UI, etc. and so forth), they are slower or unwilling to update the core version of the Android operating system. As a result, you have many phones running on older versions of Android, be it 1.6, 2.0, or 2.1. This can pose a significant problem for the average Android developer; the goal is to support as many Android phones as possible, but building to a lower Android version can strip a developer of features present in newer Android OS versions, like Internet calling or support for extra large screens.
What’s a developer to do?
The best thing to do is decide what features you need in your app, and see the lowest version that contains all of these features. For example, let’s say you need to create a sync adapter to interface with an external data source; that functionality comes with Android 2.0, and so you’d need to develop to the Android 2.0 SDK in order to use that data sync adapter. Older versions of the SDK wouldn’t have the data sync adapter feature; if you tried to build your app using the 1.6 SDK, for example, you wouldn’t be able to include that functionality even if the app was run on a phone running a version of Android that included the data sync adapter ability.
The differences between Android SDKs are numerous, though not always gargantuan; some of the version changes are minor and others major. The framework and features changes are beyond the scope of this document to list here, but thankfully Google keeps a very comprehensive set of documentation regarding the Android version SDKs, including new features and changes to the API and framework calls. This documentation is available here:
It contains API difference reports so you can see at a glance the change log between the SDKs, including detailed breakdowns of what calls and functions have changed between versions.
That’s not to say, however, that you should simply develop to the lowest standard denominator; for example, if the 1.6 SDK meets your requirements that doesn’t necessarily mean you should develop to it. Though phone makers are rolling out updates slowly, they are rolling out updates: fewer people, and so it might be counterproductive to develop to such an antiquated standard only to reach a small handful of users. The best objective here would be to develop to the lowest possible Android standard that both supports the features you need and is the newest version that reaches the most users possible.
How to figure that one out?
Well, thankfully Google keeps meticulous statistics on the OS versions of the phones that access the Android Market. It can be reached at http://developer.android.com/resources/dashboard/platform-versions.html, and it includes a percentage breakdown of the versions of Android OS that are accessing the Android Market within the last 14 days.
If we take a look at the most current statistics (As of August 1st, 2011) we can see that the vast majority of users aren’t running on Android 2.1 anymore. In fact, a full 81% of people are using Android 2.2 or higher, and if you include the Android 2.1 statistics that number jumps to 96%. That means that only 4% of users aren’t being hit when you develop to the 2.1 SDK, which is a very small number of users indeed.
The choice as a developer, then, becomes clear: you can still use the 2.1 SDK and all the features it entails without sacrificing a severe number of users in the process. If anything, the distribution shows that the Android fragmentation problem isn’t as bad as many claim it to be; over half of Android users are using the same platform, and 81% of them are only a version number apart. For developers looking to get exposure to a majority of users, getting the Android version right isn’t as hard as some may lead you believe.
The big question here is, of course, the hardest to answer: what’s the best SDK version to build to overall? What’s the best SDK base for a budding developer looking to get their app out the door and into the wild?
The answer is, of course, that it depends on your situation: if you’re a developer looking for the most exposure, build to Android 2.1. If you are comfortable having more features at the expense of losing about 15% of the Android userbase, then build to Android 2.2; you’re still getting most of the features that are newer, and you’re still able to reach 81% of the Android majority. the 2.3 SDK still hasn’t hit the majority of users in the wild, and so building to it will give you the most features but cut you off from the majority of the Android users.
For most Android developers, however, the best SDK to use in general would most likely be 2.1. It offers the most access to a users base – 96% – while still giving most of the features cooked into the 2.0 SDK. For most applications, features don’t matter quite as much as compatibility: Most apps, especially simpler ones designed for a wider audience, don’t need quite that much functionality.
And so ends our foray into the Android SDKs and their versions; the choice of the SDK is an important one, and shouldn’t be entered into with a clear conception of what you need both in features and in accessibility. For most, however, the 2.1 SDK is the way to go; it offers the best mix between functionality and accessibility, and will prove to be the best way to avoid fragmentation headaches going forward with your app!
Help us spread the word!
If you liked this article, consider enrolling in one of these related courses:
|Jun 03-05||Java for Android|
|Jun 10-13||Android Bootcamp|
|Jun 10-11||Android Application Development|
|- Classroom - Online|