At the time of this writing, there are six different versions of the Android SDK in users' hands: Android 1.1, Android 1.5, Android 1.6, Android 2.0, Android 2.0.1, and Android 2.1. The upcoming releases (codenamed Froyo and Gingerbread) will add to this list. From time to time, Google publishes a breakdown of the usage of various Android versions on handsets:
This data was collected and provided online by the Android developer website during the two weeks prior to April 4, 2010. You can check for updated statistics at the following Android developer website: http://developer.android.com/resources/ dashboard/platform-versions.html. One particularly interesting factor is that some versions of the SDK are effectively skipped by most devices, such as 2.0, because they are quickly replaced, and updates (like 2.0.1 and 2.1) are pushed out to users. This data can be invaluable for reducing testing load to just platforms where it matters.
It may not be feasible for certain phones, especially older models, to receive the latest firmware updates. As you can see, if you want to hit the broadest range of users, you may need to develop for several different versions of the SDK. This data can be invaluable for reducing the testing load to only those platforms where it matters.
Looking for new data, watching the market news, and surveying your target users will all ultimately help you determine which devices to target.
Choosing an Application's Target Platform
To appeal to the most users, you need to give some thought to your target platform before you develop any Android application. Will your application support some of the older, more established handsets or just the newest ones? Do some market research and determine what versions of the SDK your target users are using in the field.
Specifying a Project's Target SDK
You can specify an application's SDK support by compiling against the appropriate SDK version, which is set in the project settings, as well as the Android manifest file. You can also specify certain application resources to work with certain SDK versions, by using the appropriate resource directory qualifiers listed in Table 20.1.
To target the largest number of handsets, you need to target multiple versions of the SDK. However, setting required SDK versions in the Android manifest file limits the versions of the SDK on which your application can be installed.
There is a workaround here, though. Because Java uses reflection, you can query classes and methods without including them in the import statements. You could therefore set the minimum SDK version to the lowest possible version that your application can reasonably use. Then application logic can be used—by determining what's actually available at runtime—to enhance any functionality or features that are available. This method can also be used on devices that include specialized features or functions not found on other devices but that your application may want to leverage when they are available.
Backward compatibility in the Android platform is not guaranteed. Developers have experienced some rough patches when classes in the latest SDK are changed or deprecated. For example, some applications written for Android SDK 1.5 were broken by the Android 1.6 release, and then they worked again in Android 2.0. This can be very frustrating to developers and users.
Did you Know?
You can programmatically determine the version of Android by using the Build class (android.os.Build). Specifically, you can check the Build.VERSION class's SDK_INT value, as defined in android.os.Build.VERSION_CODES.
Much as developers can provide resources for specific language, region, and handset configuration options in applications, they can also provide resources for specific versions of the Android SDK. Recall from Table 20.1 that resource paths can also specify a particular Android API level number.
Was this article helpful?