Difference between minsdkversion and targetsdkversion

android:minSdkVersion

 
An integer designating the minimum API Level required for the application to run. 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. You should always declare this attribute.android:minSdkVersion helps Google Play filter apps for the user based on their device. For instance, with minSdkVersion=”7″, someone browsing with a device that only supports 6 won’t see your app on Google Play, and thus won’t download it, find it doesn’t work, and leave a bad review :)

android:targetSdkVersion

 
An integer designating the API Level that the application is targetting.

With this attribute set, the application says that it is 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.

android:targetSdkVersion is a signal to the device about which version of the API your app was tested against. New behaviors are often available by default with new versions of the platform, for applications that target at least that version of the platform. For instance, by setting your targetSdkVersion to 11 or higher, you get an overflow menu in the ActionBar (for Honeycomb and up devices) instead of the “legacy menu button of shame”.

project.properties target is a signal to your local build system regarding which version of the platform you should be compiling your code against. Generally it’s best to just set this to whatever you have set for the targetSdkVersion.

android:maxSdkVersion

 
An integer designating the maximum API Level on which the application is designed to run.

In Android 1.5, 1.6, 2.0, and 2.0.1, the system checks the value of this attribute when installing an application and when re-validating the application after a system update. In either case, if the application’s maxSdkVersionattribute is lower than the API Level used by the system itself, then the system will not allow the application to be installed. In the case of re-validation after system update, this effectively removes your application from the device.

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 maxSdkVersionand 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.

You have to maintain backward compactiblity through your code:

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.)

To give another example, you could use this if you wanted to use a feature from Gingerbread or Honeycomb. Some people will get the updates soon, but many others, particularly with older hardware, might stay stuck with Eclair until they buy a new device. This would let you use some of the cool new features, but without excluding part of your possible market