当你设置targetSdkVersion="xx"时，你是在证明你的应用程序在API级别xx上正常工作(例如，已经彻底和成功地测试了)。

运行在API级别高于xx的Android版本将自动应用兼容性代码来支持任何你可能依赖的功能，这些功能在API级别xx或之前可用，但现在在该Android版本的更高级别已经过时。

Conversely, if you are using any features that became obsolete at or prior to level xx, compatibility code will not be automatically applied by OS versions at higher API levels (that no longer include those features) to support those uses. 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 features that are available at the running OS's API level.

如果它没有做到这一点，那么一些通常会在代码中触发事件的接口特性可能就不会出现，并且您可能会缺少用户触发这些事件并访问其功能所需的关键接口特性(如下面的示例所示)。

正如在其他回答中所述，如果您想使用一些最初定义在比您的minSdkVersion更高API级别上的API特性，并且已经采取步骤确保您的代码可以检测和处理在比targetSdkVersion更低级别上缺乏这些特性，则可以将targetSdkVersion设置为高于minSdkVersion。

为了警告开发人员专门测试使用特性所需的最低API级别，如果代码包含对任何在比minSdkVersion更晚的API级别上定义的方法的调用，编译器将发出一个错误(不仅仅是警告)，即使targetSdkVersion大于或等于该方法首次可用的API级别。若要删除此错误，请使用编译器指令

@TargetApi(nn)

告诉编译器，该指令范围内的代码(在方法或类之前)已经被编写为在调用任何依赖于至少具有该API级别的方法之前测试至少nn的API级别。例如，下面的代码定义了一个方法，可以从minSdkVersion小于11且targetSdkVersion大于或等于11的应用程序的代码中调用:

@TargetApi(11)
    public void refreshActionBarIfApi11OrHigher() {
      //If the API is 11 or higher, set up the actionBar and display it
      if(Build.VERSION.SDK_INT >= 11) {
        //ActionBar only exists at API level 11 or higher
        ActionBar actionBar = getActionBar();

        //This should cause onPrepareOptionsMenu() to be called.
        // In versions of the API prior to 11, this only occurred when the user pressed 
        // the dedicated menu button, but at level 11 and above, the action bar is 
        // typically displayed continuously and so you will need to call this
        // each time the options on your menu change.
        invalidateOptionsMenu();

        //Show the bar
        actionBar.show();
    }
}

如果您已经在更高的级别上进行了测试并且一切正常，那么您可能还想声明更高的targetSdkVersion，即使您没有使用任何来自高于minSdkVersion的API级别的特性。这只是为了避免访问旨在从目标级别调整到最小级别的兼容性代码的开销，因为您已经确认(通过测试)不需要这样的调整。

An example of a UI feature that depends upon the declared targetSdkVersion would be the three-vertical-dot menu button that appears on the status bar of apps having a targetSdkVersion less than 11, when those apps are running under API 11 and higher. If your app has a targetSdkVersion of 10 or below, it is assumed that your app's interface depends upon the existence of a dedicated menu button, and so the three-dot button appears to take the place of the earlier dedicated hardware and/or onscreen versions of that button (e.g., as seen in Gingerbread) when the OS has a higher API level for which a dedicated menu button on the device is no longer assumed. However, if you set your app's targetSdkVersion to 11 or higher, it is assumed that you have taken advantage of features introduced at that level that replace the dedicated menu button (e.g., the Action Bar), or that you have otherwise circumvented the need to have a system menu button; consequently, the three-vertical-dot menu "compatibility button" disappears. In that case, if the user can't find a menu button, she can't press it, and that, in turn, means that your activity's onCreateOptionsMenu(menu) override might never get invoked, which, again in turn, means that a significant part of your app's functionality could be deprived of its user interface. Unless, of course, you have implemented the Action Bar or some other alternative means for the user to access these features.

相比之下，minSdkVersion声明要求设备的操作系统版本至少具有该API级别才能运行应用程序。这影响哪些设备能够在谷歌Play应用程序商店(也可能是其他应用程序商店)上看到和下载应用程序。这是一种说法，说明你的应用程序依赖于OS (API或其他)的功能，建立在该级别，并没有一个可接受的方式来处理这些功能的缺失。

An example of using minSdkVersion to ensure the presence of a feature that is not API-related would be to set minSdkVersion to 8 in order to ensure that your app will run only on a JIT-enabled version of the Dalvik interpreter (since JIT was introduced to the Android interpreter at API level 8). Since performance for a JIT-enabled interpreter can be as much as five times that of one lacking that feature, if your app makes heavy use of the processor then you might want to require API level 8 or above in order to ensure adequate performance.

如果你得到一些编译错误，例如:

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

.

private void methodThatRequiresAPI11() {
        BitmapFactory.Options options = new BitmapFactory.Options();
                options.inPreferredConfig = Config.ARGB_8888;  // API Level 1          
                options.inSampleSize = 8;    // API Level 1
                options.inBitmap = bitmap;   // **API Level 11**
        //...
    }

你会得到编译错误:

字段要求API级别11(当前最小值为10): # inBitmap android.graphics.BitmapFactory美元选项

自从第17版的Android开发工具(ADT)，有一个新的和非常有用的注释@TargetApi，可以很容易地修复这个问题。将它添加到包含有问题声明的方法之前:

@TargetApi
private void methodThatRequiresAPI11() {            
  BitmapFactory.Options options = new BitmapFactory.Options();
      options.inPreferredConfig = Config.ARGB_8888;  // API Level 1          
      options.inSampleSize = 8;    // API Level 1

      // This will avoid exception NoSuchFieldError (or NoSuchMethodError) at runtime. 
      if (Integer.valueOf(android.os.Build.VERSION.SDK) >= android.os.Build.VERSION_CODES.HONEYCOMB) {
        options.inBitmap = bitmap;   // **API Level 11**
            //...
      }
    }

现在没有编译错误，它将运行!

EDIT:这将导致API级别低于11的运行时错误。在11或更高版本上，它运行起来没有问题。因此，必须确保在版本检查保护的执行路径上调用此方法。TargetApi只允许你编译它，但是你要自担风险。

Target sdk是你想要的目标版本，而min sdk是最小的一个。

android:minSdkVersion和android:targetSdkVersion都是Integer值，我们需要在android manifest文件中声明，但两者都有不同的属性。

android:minSdkVersion:这是运行android应用程序所需的最低API级别。如果我们将在较低的API版本上安装相同的应用程序，解析器将出现错误，应用程序不支持的问题将出现。

android:targetSdkVersion: Target sdk version用于设置应用程序的Target API级别。如果manifest中没有声明这个属性，minSdk version将是你的TargetSdk version。这总是正确的，“应用程序支持安装在所有更高版本的API，我们声明为TargetSdk版本”。要使应用程序有限的目标，我们需要声明maxSdkVersion在我们的manifest文件…

android: minSdkVersion

一个整数，指定应用程序运行所需的最小API级别。如果系统的API级别低于此属性中指定的值，Android系统将阻止用户安装应用程序。您应该始终声明此属性。

android: targetSdkVersion

一个整数，指定应用程序的目标API级别。

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.

更多信息请参考这个URL:

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

一个概念总是可以用例子更好地表达。我很难理解这些概念，直到我深入研究Android框架源代码，并做了一些实验，甚至在阅读了Android开发人员网站和相关stackoverflow线程中的所有文档之后。我将分享两个例子，它们帮助我充分理解这些概念。

一个DatePickerDialog将根据你放在AndroidManifest.xml文件的targetSDKversion(<use -sdk android: targetSDKversion ="INTEGER_VALUE"/>)中的级别看起来不同。如果您将值设置为10或更低，您的DatePickerDialog将看起来像左边。另一方面，如果您将值设置为11或更高，则DatePickerDialog将看起来是正确的，具有完全相同的代码。

我用来创建这个示例的代码非常简单。java看起来:

public class MainActivity extends Activity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
    }

    public void onClickButton(View v) {
        DatePickerDialog d = new DatePickerDialog(this, null, 2014, 5, 4);
        d.show();       
    }
}

而activity_main.xml看起来是:

<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent" >
<Button
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:onClick="onClickButton"
    android:text="Button" />
</RelativeLayout>

就是这样。这是我需要测试的所有代码。

当你看到Android框架源代码时，这种外观上的变化是非常明显的。是这样的:

public DatePickerDialog(Context context,
    OnDateSetListener callBack,
    int year,
    int monthOfYear,
    int dayOfMonth,
    boolean yearOptional) {
        this(context, context.getApplicationInfo().targetSdkVersion >= Build.VERSION_CODES.HONEYCOMB
                ? com.android.internal.R.style.Theme_Holo_Light_Dialog_Alert
                : com.android.internal.R.style.Theme_Dialog_Alert,
        callBack, year, monthOfYear, dayOfMonth, yearOptional);
}

如您所见，框架获取当前的targetSDKversion并设置不同的主题。这种代码片段(getApplicationInfo())。targetSdkVersion >= SOME_VERSION)可以在Android框架中随处找到。

另一个例子是关于WebView类的。Webview类的公共方法应该在主线程上调用，如果没有调用，当你设置targetSDKversion 18或更高版本时，运行时系统抛出RuntimeException。该行为可以通过源代码清楚地交付。它就是这样写的。

sEnforceThreadChecking = context.getApplicationInfo().targetSdkVersion >=
            Build.VERSION_CODES.JELLY_BEAN_MR2;

if (sEnforceThreadChecking) {
    throw new RuntimeException(throwable);
}

Android文档称:“随着Android的每一个新版本的发展，一些行为甚至外观可能会发生变化。”我们已经研究了行为和外表的变化，以及这些变化是如何实现的。

In summary, the Android doc says "This attribute(targetSdkVersion) 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.". This is really clear with WebView case. It was OK until JELLY_BEAN_MR2 released to call WebView class's public method on not-main thread. It is nonsense if Android framework throws a RuntimeException on JELLY_BEAN_MR2 devices. It just should not enable newly introduced behaviors for its interest, which cause fatal result. So, what we have to do is to check whether everything is OK on certain targetSDKversions. We get benefit like appearance enhancement with setting higher targetSDKversion, but it comes with responsibility.

编辑: 免责声明。DatePickerDialog构造函数根据当前targetSDKversion(上面所示)设置不同的主题，实际上在稍后的提交中已经更改。尽管如此，我还是使用了那个例子，因为逻辑没有改变，而且那些代码片段清楚地显示了targetSDKversion概念。