Difference between “Build Target SDK” in Eclipse a

2020-01-30 06:58发布

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.

标签: android
7条回答
▲ chillily
2楼-- · 2020-01-30 07:44

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.

查看更多
登录 后发表回答