Friday, July 20, 2012

What is the difference between minSdkVersion, maxSdkVersion and targetSdkVersion


  • android:minSdkVersion — Specifies the minimum API Level on which the application is able to run. The default value is "1".
  • android:targetSdkVersion — Specifies the API Level on which the application is designed to run. In some cases, this allows the application to use manifest elements or behaviors defined in the target API Level, rather than being restricted to using only those defined for the minimum API Level.
  • android:maxSdkVersion — Specifies the maximum API Level on which the application is able to run.Important: Please read the <uses-sdk> documentation before using this attribute.


<uses-sdk android:minSdkVersion="integer" 
          android:targetSdkVersion="integer"
          android:maxSdkVersion="integer" />


android:minSdkVersion

  1. An integer designating the minimum API Level required for the application to run.
  2. The Android system will prevent the user from installing the application if the system's API Level is lower than the value specified in this attribute. 
  3. You should always declare this attribute.
  4. If you do not declare this attribute, the system assumes a default value of "1", which indicates that your application is compatible with all versions of Android, till your target and/or max version.
  5.  If your application is notcompatible with all versions (for instance, it uses APIs introduced in API Level 3) and you have not declared the proper minSdkVersion, then when installed on a system with an API Level less than 3, the application will crash during runtime when attempting to access the unavailable APIs. For this reason, be certain to declare the appropriate API Level in the minSdkVersion attribute.

android:targetSdkVersion -

When you set targetSdkVersion="xx", you are certifying that your app works properly (e.g., has been thoroughly and successfully tested) at API level xx

Conversely, if you are using any APIs that became obsolete at or prior to level xx, compatibility code willnot be automatically applied by OS versions at higher API levels (that no longer include those features) to support those APIs. In that situation, your own code must have special case clauses that test the API level and, if the OS level detected is a higher one that no longer has the given API feature, your code must use alternate APIs that are available at the running OS's API level. If it fails to do this, then it will experience a run time anomaly when those obsolete APIs are accessed by your code. Or, perhaps some interface features will simply not appear that would normally trigger the obsolete APIs, and you will notget an error, but will instead be missing a critical interface feature (as in the example below).

  1. An integer designating the API Level that the application targets. If not set, the default value equals that given to minSdkVersion.
  2. This attribute informs the system that you have tested against the target version and the system should not enable any compatibility behaviors to maintain your app's forward-compatibility with the target version. 
  3. The application is still able to run on older versions (down to minSdkVersion),  but was explicitly tested to work with the version specified here. Specifying this target version allows the platform to disable compatibility settings that are not required for the target version (which may otherwise be turned on in order to maintain forward-compatibility) or enable newer features that are not available to older applications. This does not mean that you can program different features for different versions of the platform—it simply informs the platform that you have tested against the target version and the platform should not perform any extra work to maintain forward-compatibility with the target version.
  4. As Android evolves with each new version, some behaviors and even appearances might change. However, if the API level of the platform is higher than the version declared by your app'stargetSdkVersion, the system may enable compatibility behaviors to ensure that your app continues to work the way you expect. You can disable such compatibility behaviors by specifyingtargetSdkVersion to match the API level of the platform on which it's running. For example, setting this value to "11" or higher allows the system to apply a new default theme (Holo) to your app when running on Android 3.0 or higher and also disables screen compatibility mode when running on larger screens (because support for API level 11 implicitly supports larger screens).
  5. To maintain your application along with each Android release, you should increase the value of this attribute to match the latest API level, then thoroughly test your application on the corresponding platform version.
  6. Introduced in: API Level 4


android:maxSdkVersion


An integer designating the maximum API Level on which the application is designed to run.
To illustrate how this attribute can affect your application after system updates, consider the following example
An application declaring maxSdkVersion="5" in its manifest is published on Google Play. A user whose device is running Android 1.6 (API Level 4) downloads and installs the app. After a few weeks, the user receives an over-the-air system update to Android 2.0 (API Level 5). After the update is installed, the system checks the application's maxSdkVersion and successfully re-validates it. The application functions as normal. However, some time later, the device receives another system update, this time to Android 2.0.1 (API Level 6). After the update, the system can no longer re-validate the application because the system's own API Level (6) is now higher than the maximum supported by the application (5). The system prevents the application from being visible to the user, in effect removing it from the device.

Warning: Declaring this attribute is not recommended. First, there is no need to set the attribute as means of blocking deployment of your application onto new versions of the Android platform as they are released. By design, new versions of the platform are fully backward-compatible. Your application should work properly on new versions, provided it uses only standard APIs and follows development best practices. Second, note that in some cases, declaring the attribute can result in your application being removed from users' devices after a system update to a higher API Level. Most devices on which your application is likely to be installed will receive periodic system updates over the air, so you should consider their effect on your application before setting this attribute.
Introduced in: API Level 4
Future versions of Android (beyond Android 2.0.1) will no longer check or enforce the maxSdkVersionattribute during installation or re-validation. Google Play will continue to use the attribute as a filter, however, when presenting users with applications available for download.


In short, here is the purpose to declaring a different targetSDK from the minSDK: It means you are using features from a higher level SDK than your minimum, but you have ensured backwards compatibility. In other words, imagine that you want to use a feature that was only recently introduced, but that isn't critical to your application. You would then set the targetSDK to the version where this new feature was introduced and the minimum to something lower so that everyone could still use your app.
To give an example, let's say you're writing an app that makes extensive use of gesture detection. However, every command that can be recognised by a gesture can also be done by a button or from the menu. In this case, gestures are a 'cool extra' but aren't required. Therefore you would set the target sdk to 7 ("Eclair" when the GestureDetection library was introduced), and the minimumSDK to level 3 ("Cupcake") so that even people with really old phones could use your app. All you'd have to do is make sure that your app checked the version of Android it was running on before trying to use the gesture library, to avoid trying to use it if it didn't exist. (Admittedly this is a dated example since hardly anyone still has a v1.5 phone, but there was a time when maintaining compatibility with v1.5 was really important.)

Each Android platform version stores its API Level identifier internally, in the Android system itself.
Applications can use a manifest element provided by the framework API — <uses-sdk> — to describe the minimum and maximum API Levels under which they are able to run, as well as the preferred API Level that they are designed to support. The element offers three key attributes:
  • android:minSdkVersion — Specifies the minimum API Level on which the application is able to run. The default value is "1".
  • android:targetSdkVersion — Specifies the API Level on which the application is designed to run. In some cases, this allows the application to use manifest elements or behaviors defined in the target API Level, rather than being restricted to using only those defined for the minimum API Level.
  • android:maxSdkVersion — Specifies the maximum API Level on which the application is able to run.Important: Please read the <uses-sdk> documentation before using this attribute.
For example, to specify the minimum system API Level that an application requires in order to run, the application would include in its manifest a <uses-sdk> element with a android:minSdkVersion attribute. The value of android:minSdkVersion would be the integer corresponding to the API Level of the earliest version of the Android platform under which the application can run.
When the user attempts to install an application, or when revalidating an appplication after a system update, the Android system first checks the <uses-sdk> attributes in the application's manifest and compares the values against its own internal API Level. The system allows the installation to begin only if these conditions are met:
  • If a android:minSdkVersion attribute is declared, its value must be less than or equal to the system's API Level integer. If not declared, the system assumes that the application requires API Level 1.
  • If a android:maxSdkVersion attribute is declared, its value must be equal to or greater than the system's API Level integer. If not declared, the system assumes that the application has no maximum API Level. Please read the <uses-sdk> documentation for more information about how the system handles this attribute.

or those who want a summary,
android:minSdkVersion
is minimum version of android that your app need, ie in terms of backward compatibility.
while,
android:targetSdkVersion
is maximum version from where you app has inherited features.
ie. My app will work on minimum 1.6 but I also have used features that are supported only in 2.2 which will be visible if it is installed on a 2.2 device.
android:maxSdkVersion
is maximum (apis) supported device


Conclusion -

minSdkVersion is required to set the minimum version of device apps supporting, targetSdkVersion is required to test your apps whether target APIs will supporting by apps or not, and if you know the maximum version of device/system apps will support use maxSdkVersion


Application forward compatibility

Android applications are generally forward-compatible with new versions of the Android platform.
Because almost all changes to the framework API are additive, an Android application developed using any given version of the API (as specified by its API Level) is forward-compatible with later versions of the Android platform and higher API levels. The application should be able to run on all later versions of the Android platform, except in isolated cases where the application uses a part of the API that is later removed for some reason.


Application backward compatibility

Android applications are not necessarily backward compatible with versions of the Android platform older than the version against which they were compiled.
Each new version of the Android platform can include new framework APIs, such as those that give applications access to new platform capabilities or replace existing API parts. The new APIs are accessible to applications when running on the new platform and, as mentioned above, also when running on later versions of the platform, as specified by API Level. Conversely, because earlier versions of the platform do not include the new APIs, applications that use the new APIs are unable to run on those platforms.