2

Can you explain to me how I should determine the correct value for targetSdkLevel?

Let's say I want to build an app that works on all the versions from android 2.3.7 to 4.0.3, how should I set minSdkLevel and targetSdkLevel?

The former should match the API level of android 2.3.7 and the latter should match the API level of 4.0.3?

Then, when I develop my app, should I use only Methods/classes available in the oldest supported sdk level?

When I compile the app does it compile for 2.3.7 or 4.0.3?

I can not understand the purpose of targetSdkLevel, since the apk can not be compiled for the newer version specified in this tag, otherwise it could not work on versions down to the one specified by minSdkLevel... Why should I not set targetSdkLevel to the latest available level?

I've read also the official info about uses-sdk Manifest tag, but I still do not understand.. Can you help me clarifying this topic?

EDIT: thanks to all of you and excuse me for the duplicate question. I've read this Blog post and it really helped me. Great answers from all of you.

Gianni Costanzi
  • 6,054
  • 11
  • 48
  • 74
  • 1
    duplicate http://stackoverflow.com/questions/4568267/android-min-sdk-version-vs-target-sdk-version – Dhruv Gairola Jun 01 '12 at 20:26
  • @DhruvGairola I'm sorry for the duplicate. Thank you for the very useful link, that let me find this wonderful blog post: http://android-developers.blogspot.it/2010/07/how-to-have-your-cupcake-and-eat-it-too.html – Gianni Costanzi Jun 02 '12 at 07:40

4 Answers4

4

It clearly is explained here: http://developer.android.com/guide/topics/manifest/uses-sdk-element.html

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.

And for targetSdkVersion

An integer designating the API Level that the application targets. If not set, the default value equals that given to minSdkVersion. 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. The application is still able to run on older versions (down to minSdkVersion).

What is that you don't understand here?

This is how you would set it: 

<uses-sdk android:minSdkVersion="10" 
          android:targetSdkVersion="15"/>

You can read about the changes here, for API Level 14: http://developer.android.com/sdk/api_diff/14/changes.html and here for API Level 4: http://developer.android.com/sdk/api_diff/4/changes.html

nullpotent
  • 9,162
  • 1
  • 31
  • 42
  • I've read exactly that page but I'm not able to answer my questions... If I set *targetSdkLevel* to 14 and *minSdkLevel* to 4, what code/methods/classes are used? The ones in API level 4? Then I have an apk compiled for release 4, so how can it be targeted and use new features up to level 14? I'm sorry but it makes me confusing a bit.. – Gianni Costanzi Jun 01 '12 at 20:29
  • I made a lot of mess here.. Reading this helped e clarifying some doubts: http://android-developers.blogspot.it/2010/07/how-to-have-your-cupcake-and-eat-it-too.html – Gianni Costanzi Jun 02 '12 at 07:54
4

You should only use methods/classes available in the SDK specified by minSdkLevel, or otherwise wrap them with a proper check for the runtime API version.

Your application will be compiled with the SDK specified in the project itself, not by the one specified by either minSdkLevel nor targetSdkLevel.

You should set targetSdkLevel to the highest level API that you have tested the application with. This is because compatilibity behavior will be enabled/disabled for your application based on this value.

K-ballo
  • 80,396
  • 20
  • 159
  • 169
  • If I'm using Eclipse to develop the app and *minSdkLevel* is 4 while *targetSdkLevel* is 14, does Eclipse set itself to work with level 4, i.e. providing only methods/auto completions for that level? So I should not worry about using things not supported in *minSdkLevel*, right? – Gianni Costanzi Jun 02 '12 at 07:18
  • I think that what I've written in the previous comment is wrong... I've understood that we can set the target level to a level in which has been introduced a feature we would like to use, for example, and then check at runtime if it is available or not, ensuring that our app works also on older hardware.. But is it possible that the produced apk, that works also at *minLevelSdk*, contains code that calls methods/uses classes that were not yet available in *minLevelSdk*? What do you mean by "the application will be compiled with the sdk specified by the project"? What if it is greater than min? – Gianni Costanzi Jun 02 '12 at 07:29
  • This link answers my last questions: http://android-developers.blogspot.it/2010/07/how-to-have-your-cupcake-and-eat-it-too.html – Gianni Costanzi Jun 02 '12 at 07:38
1

Build using the target, and then you can check and gracefully downgrade if the user is below the target. For example, if you are creating a location aware app, you might want to use PASSIVE_PROVIDER which is available starting with version 8. You could set the min version lower than 8 and check the android version. From there you could decide to use or not use PASSIVE_PROVIDER based on the version.

bezz
  • 1,438
  • 18
  • 28
  • How do you check the version at runtime? Is there a function call that provide this info? Otherwise I could easily add a string version-info with value *lower-than-10* in a strings.xml file within values folder and then add the same string with value *higher-or-equal-to-10* in a strings.xml file in values-v10 folder and then retrieve the string at runtime.. Is this too stupid or inherently wrong? – Gianni Costanzi Jun 01 '12 at 20:36
  • I've found the answer here: http://android-developers.blogspot.it/2010/07/how-to-have-your-cupcake-and-eat-it-too.html – Gianni Costanzi Jun 02 '12 at 07:46
1

google suggests that you always use the latest version of the targetSdk , and also gives the lint tool to check for you that your classes and methods aren't too new for the minSdkVersion . in case of a warning , you will need to think of how to handle it.

do note that as people has mentioned here , setting the targetSdk also means that it will change some aspects of the app .

one aspect is how the app treats the menu button : if you set the targetSdk to 11 or above , it means that you can't assume that there is a menu button , so you will have to deal with the action bar and put the options there in some way (or any other way, depending on your app design) .

if you set it to 10 or below , android will add this button (shown as 3 dots) on the screen for devices that don't have the menu button , like the htc one x or the galaxy nexus . do note that for some devices it looks ugly (takes a whole row for the htc one x , for example) .

so , in short , i would suggest setting the minSdk to the minimum that you can , in order to support as many people as possible , and the targetSdk to the maximum that you can , in order to enjoy all of the benefits that it can give you .

android developer
  • 114,585
  • 152
  • 739
  • 1,270