Difference between "Build Target SDK" in Eclipse and android:targetSdkVersion in AndroidManifest.xml?

Question

As I'm importing an existing Android project into Eclipse, I am asked to select an SDK build target as part of the process.

Why do I need to enter this information? How is this different from the android:targetSdkVersion/android:minSdkVersion values specified in AndroidManifest.xml?

For example, in the Google IO sample app, its AndroidManifest says android:targetSdkVersion=11, but the README says the Eclipse project needs to target API level 13 or higher, or compile errors will occur.

Answer 1

android:minSdkVersion in manifest file means that market will filter devices with lower sdk.

target=android-x in project properties file means that Eclipse will not allow use methods or classes from sdk higher than x. It will show compiler errors.

You can use it like this: provide min version in manifest - depending on your app critical features. Set the same value to project properties. Then, if you want use somewhere APIs from higher SDKs - raise up value in project properties, and wrap code with check if device API can do this code:

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.ECLAIR_MR1)
{
    // here you can use APIs, that appears in Android 2.1
}

Answer 2

Here is a description of each attribute, exactly what it controls, and how you should use it.

In AndroidManifest.xml:

• midSdkVersion: Used by the Google Play Market. The lowest API on which you will allow your app to run. Devices running a version of Android older than this will not be allowed to install your app. Set this to the lowest version of android that your code can support (i.e. it doesn't use any API calls newer than this without paying special attention to backward compatibility). Of course, you should test on a device or emulator running this version.

  Google provides a dashboard giving you a breakdown of the number of people using each version, which can be useful when deciding whether it's OK to stop supporting one.

  Note: If you are using any of the android-support libraries, you should not use an older version than indicated in the name of the support library. For example, android-support-v4.jar will not run on versions of Android older than 4.

• targetSdkVersion: Used by devices at run time. Devices use this to decide whether to run your app in a backward compatibility mode. For example, if you set this to 10 (Gingerbread) devices that run 16 (Jelly Bean) will still use the visual styling of Gingerbread for your app; e.g. it will have a title bar instead of an action bar. Set this to the newest version of Android that you want your app to look like (which you can only determine by testing it on newer versions to see if it looks good and behaves well).

In project.properties, or set via Eclipse's Project Build Target setting:

• target: Used by your computer at compile time. The version of Android that your app is compiled against. Trying to use API features newer than this will cause an error. You should set this to the same as minSdkVersion unless you do special things for backward compatibility (see below), so that the compiler will prevent you from accidentally using features that don't exist on your users' older devices (causing it to crash).

  Note: It is possible for library projects you include to require a minimum for this value. For example, android-support-v7-appcompat includes .xml resource files in res/layout-v14 that require you to compile against API 14 or newer.

A note on backward compatibility:

There is a case when project.properties should be higher than minSdkVersion: when you want to use newer API features, but you include special code for backward compatibility to allow it to run on older devices. In this case you will have to bump project.properties up to the match the oldest API that contains all the features you use.

When possible, use the Android Support Libraries to accomplish backward compatibility, because it is conventional, well tested, easy, and allows you to leave project.properties alone. However, sometimes the support libraries do not meet your needs, in which case you will have to use techniques such as this or these

Answer 3

The heart of your question is: what is the relationship between the targetSdkVersion value declared in a project's manifest, and the Project Build Target selected in the Project / Properties / Android dialog for the project in Eclipse, which selects the SDK level against which your app is compiled?

The minSdkVersion value is a distraction from your question; this must be less than or equal to targetSdkVersion, but it is not directly related to the Project Build Target. The relationship is between targetSdkVersion and Project Build Target.

After careful consideration (you must judge for yourself whether I have this right), I have concluded that the targetSdkVersion and the Project Build Target should always be set to the same API level. My reasoning is in two parts.

** First, I'll argue that Project Build Target should never be lower than targetSdkVersion:

When you set targetSdkVersion to a certain API level, this is generally done in order to use certain API features that first became available at that level. You may decide to support versions back to an earlier minSdkVersion, and to detect the lack of availability of your targetSdkVersion features that were not available in those earlier versions, and write alternate code which supports those earlier versions, but your reason for setting targetSdkVersion would be to obtain access to features that are only available as of that API level.

Since you clearly want to access some features that were first introduced at the targetSdkVersion API level, it makes sense that you would set your Project Build Target to equal the same API level as specified in your targetSdkVersion. Otherwise, the API against which you are compiling will not include the API features which were the reason for your setting targetSdkVersion to the level that you selected.

So, clearly, you would not want to set your Project Build Target lower than your targetSdkVersion. But would you ever want to set it higher? This brings us to part two of the argument:

** Second, I will argue that the Project Build Target should never be higher than targetSdkVersion:

You would not want to select a Project Build Target that is higher than your targetSdkVersion, because that would mean that you might inadvertently use some features supplied by the SDK of your Build Target that are not available at the level of your declared targetSdkVersion, and if you did use such features, then they would not be available if your app were run in earlier (than the build target) Android versions, and your app might crash as a result.

Now, if your app were committed to detect such missing features itself and handle their absence, then this would justify setting the targetSdkLevel to the level of the Project Build Target, since that is exactly the meaning of the targetSdkLevel (that you are committing to detecting and dealing with any API features present at your targetSdkLevel but not present at your minSdkLevel), so if you are doing that, then there's no reason not to set your targetSdkLevel to the highest level that you are supporting in your code in that manner (i.e., to the level of the Project Build Target).

[OK, I just found a "reason" to set the Project Build Level higher than the targetSdkLevel. The default soft keyboard for API level 16 and higher is buggy (its backspace key does not work correctly) and so I moved my targetSdkLevel down to 15 to make that keyboard go away. I could have changed my Project Build Target to 15 as well, but I haven't done that, because I want the latest code, on the theory that more recent is generally "improved" and therefore "better." That is perhaps superstitious. Despite this exception, the arguments above are generally valid.]

In this regard, I would note that the official docs state that: "When you are developing your application, you will need to choose the platform version against which you will compile the application. In general, you should compile your application against the lowest possible version of the platform that your application can support."

http://developer.android.com/guide/topics/manifest/uses-sdk-element.html

This seems to suggest that you should compile vs. a Project Build Target that equals the minSdkVersion rather than the targetSdkVersion, contrary to what I have argued above. I've listed my reasons for favoring targetSdkVersion instead of this. Specifically, if you are trying to use features present in targetSdkVersion but not in minSdkVersion, how will you ever be able to do that if you're compiling vs. minSdkVersion? Sure, your app will work at minSdkVersion, because you'll be testing for the availability of those features (e.g., through reflection), but you won't have those nice new API elements ever, even if your app is running on the latest version of Android, if you compile vs. a minSdkVersion level of the SDK.

So, the Project Build Target should always be the same as the targetSdkVersion; that is my argument. I couldn't find any material that laid out this relationship with any clarity, so the above is inferred by me, and is not backed by any authoritative source, and in fact the above quote from an official source seems to contradict my position; comments are therefore encouraged and desired.

Answer 4

AFAIK, the android:minSdkVersion and the one that the Eclipse asks you to select while setting up a project are one and the same. However, the android:targetSdkVersion is where you'd want your app to target a specific sdk version of Android available in the market.

For example, you might have your android:minSdkVersion="8" (the one that Eclipse asks you during setting up of your project) because you'd want your app to run on devices that have Froyo also (along with higher versions of Android). But you might want your app to truly target GingerBread users or HoneyComb users or ICS users.

EDIT : Please do keep in mind that your targetSdkVersion has to be equal to or more than that of the minSdkVersion. Otherwise, it doesn't really make much sense.

Answer 5

I'm not saying Eclipse's build target should be set to something less than minSdkVersion. I'm asking why Eclipse doesn't automatically use either minSdkVersion or targetSdkVersion as its build target SDK instead. Why would you ever want to set it to something different?

call it a feature. eclipse is not made exclusively for android. if nobody thought of adding a automatism to use the sdk version given in the manifest, then eclipse simplely wont do it. i dont think there's much magic behind this. i think it has just not been added yet to eclipse / android plugin for eclipse features.

also, since you allways may change the sdk version stated in the manifest, it makes perfectly sense to also be flexible in eclipse (you always can change the eclipse sdk target via the properties of your project). like others posted there are times when the manifest sdk may differ from the eclipse sdk. (multi sdk-version support). using a lower then the min-sdk in manifest makes no sense of course but here gain: if nobody wrote yet a checker for the eclipse plugin that checks if what you're doing makes sense, then it simply will be possible.