AndroidManifest.xml中的minSdkVersion、targetSdkVersion、maxSdkVersion和project.properties中target API leve

minSdkVersion、targetSdkVersion、targetApiLevel的区别

2011-10-10 17:19:51

在AndroidMenifest.xml中，常常会有下面的语句：

<uses-sdk android:minSdkVersion="4"

android:targetSdkVersion="10"

android:maxSdkVersion="10" />

在default.properties中，会看到下面的语句：

target=android-10

如果是使用Eclipse的话，还可能会看到这样的警告：

Attribute minSdkVersion (4) is lower than the project target API level (10)

那么，这里面的minSdkVersion、targetSdkVersion、maxSdkVersion、target API level四个数值到底有什么区别？

minSdkVersion与maxSdkVersion比较容易理解，就是在安装程序的时候，如果目标设备的API版本小于minSdkVersion，或者大于maxSdkVersion，程序将无法安装。一般来说没有必要设置maxSdkVersion。

targetSdkVersion相对复杂一些，如果设置了此属性，那么在程序执行时，如果目标设备的API版本正好等于此数值，他会告诉Android平台：此程序在此版本已经经过充分测，没有问题。不必为此程序开启兼容性检查判断的工作了。也就是说，如果targetSdkVersion与目标设备的API版本相同时，运行效率可能会高一些。

但是，这个设置仅仅是一个声明、一个通知，不会有太实质的作用，比如说，使用了targetSdkVersion这个SDK版本中的一个特性，但是这个特性在低版本中是不支持的，那么在低版本的API设备上运行程序时，可能会报错：java.lang.VerifyError。也就是说，此属性不会帮你解决兼容性的测试问题。你至少需要在minSdkVersion这个版本上将程序完整的跑一遍来确定兼容性是没有问题的。(这个问题确实让人头疼)

在default.properties中的target是指在编译的时候使用哪个版本的API进行编译。

综上，上面的四个值其实是作用于不同的时期：

target API level是在编译的时候起作用，用于指定使用哪个API版本(SDK版本)进行编译。

minSdkVersion和maxSdkVersion是在程序安装的时候起作用，用于指定哪些版本的设备可以安装此应用。

targetSdkVersion是在程序运行的时候起作用，用于提高指定版本的设备上程序运行体验。
因此，target API level就是你编译app代码要调用的sdk库的版本，比如你app代码里用了android material design的新库，那要编译通过target API level一定要为20。这样编译出来的app，因为运行sdk向后兼容原则，以后android 6.0,7.0设备上跑这个app一定都毫无压力，但是最低能到多少版本去跑呢？这一方面可以自己兼容性测试，看到底哪个最低版本能跑，另一方面可以看api文档，因为你app里调的某个函数是在material
design独有的，那在android2.3机子上当然不支持，就算不crash，可能也会不正常或难看，这个时候minSDK就要写高点，直接不让用户在太低版本机器上安装就行了。解决办法可以是，用build,SDK_INT来判断机器是哪个sdk版本，如果是5.0就调用material design的显示框架，如果是2.3就用传统api

这四个数值在程序编译时也没有严格的检查，比如说，你可以将minSdkVersion设置的比maxSdkVersion还大，他会自动忽略掉错误的maxSdkVersion。

参考：

http://developer.android.com/guide/appendix/api-levels.html

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

————————————————————————————————————————————————

AndroidManifest.xml中的minSdkVersion、targetSdkVersion、maxSdkVersion和project.properties中target API level 四个数值区别

新建工程的时候minSdk和target API level 是一致的

（1）minSdkVersion与maxSdkVersion ：在安装程序的时候，如果目标设备的API版本小于minSdkVersion，

或者大于maxSdkVersion，程序将无法安装。一般来说没有必要设置maxSdkVersion。

（2） targetSdkVersion ：如果设置了此属性，那么在程序执行时，如果目标设备的API版本正好等于此数值，他会告诉Android平台：此程序在此版本已经经过充分测试，没有问题。不必为此程序开启兼容性检查判断的工作了。也就是说，如果targetSdkVersion与目标设备的API版本相同时，运行效率可能会高一些。

（3）在project.properties中的target是指在编译的时候使用哪个版本的API进行编译。开发时工程SDK版本和target的值是保持一致的，无论修改哪一个另外一个值相应改变。

这四个数值在程序编译时也没有严格的检查，比如说，你可以将minSdkVersion设置的比maxSdkVersion还大，他会自动忽略掉错误的maxSdkVersion。

————————————————————————————————————————————————————————————

在 新建一个 android project 时，要求输入 minSdkVersion 这一项，一般我们是指定和我们使用的 SDK 版本相一致的 API Level. 然后，在androidManifest.xml 文件中会有一个对应的属性：android:minSdkVersion .那这个属性是否可以修改呢？我觉得是可以的，但不能随便修改。

"android:minSdkVersion" ，故名思义，就是最小的 SDK 版本，这个值是对应 Android 不同版本的 API Level , 如 Android 1.5 对应 3，Android 1.6 对应 4，Android 2.1 对应7，Android2.2对应8 ，Android 2.3.3 对应10，等等。。。当用户指定这个值后，Android 系统会用这个指定的值对应的 SDK 版本去编译你的应用程序。这是错误的，minSdkVersion在程序安装期间起作用，指定SDK版本去编译你的app的地方是project.properties.

eclipse用ant去编译



那么，我们在 androidManifest.xml 中指定的话，必须是比我们新建时的 API Level 小或相等的值，这样 Android 系统在编译的时候，才会用对应的版本的 SDK 进行编译。假如修改后的 android:minSdkVersion 比我们 project 里的 SDK 版本对应的 API level 大，那么Android 系统在编译的时候，就会报错。

举例说明：

1. 我们新建一个 Android Project (HelloAndroid), 指定为 Android 2.2 版本，对应的 minSdkVersion 填8，finish;

2. 此时我们运行 HelloAndroid ,会运行一个 2.2 版本的模拟器。

3. 假若我们现在去 AndroidManifest.xml 文件 中修改 android:minSdkVersion=7，再次运行，那么会在我们已经打开的 2.2 模拟器上运行。因为 Android API 都是向后兼容的，所以系统在编译时，这个 Project 是利用 2.1 版本来编译的，但也可以在 2.2 模拟器上运行；若我们先把 2.2 模拟器关闭，再运行 HelloAndroid 这个Project 的话，那么会新建一个 API Level=7 的 模拟器来运行这个程序（也就是 2.1模拟器）。

4. 假若我们修改 android:minSdkVersion=10， 那么无论你是否打开了 2.2 版本的模拟器，都会报错：
ERROR: Application requires API version 10.Device API version is 8 (Android 2.2)（要求API 10的APP在真实SDK为API 8的Android机器上跑，是不行的。所谓API向后兼容，是高版本的SDK
API能运行用低版本的SDK编译出来的应用程序，这个原则是完全考虑应用开发者的便利，因为2010年那会才出来Android 2.0，开发者用Android 2.0 SDK编译出APP，但APP代码里只是预留了调SDK API的函数，实际是去所安装机器上的SDK API的，那么2015年Android升级到5.0了，这个2010年写的用Android 2.0 SDK编译出来的APP依然能在Android 5.0 SDK的机器上跑，这就是“向后兼容”啊！）.

Launch canceled!
——————————————————————————————————————————————————————

平台版本

不同的设备可能运行不同的 Android 平台版本，比如 Android 4.0 或 Android 4.4。 较高的版本往往会在低版本系统中新增一些 API。 为了便于识别当前可用的 API 集，每个平台的版本都会被定义一个 API
级别。 例如，Android 1.0 是 API 级别1，Android 4.4 是 API 级别19。

通过 manifest 标签

< uses-sdk >

及其

minSdkVersion

属性，你可以用
API 级别来声明应用程序可兼容的最低系统版本。

例如， Calendar Provider API API 是从 Android
4.0（API 级别 14）开始引入的。 如果没有此类 API 应用程序就无法正常使用了，你就应该把最小支持版本声明为 API 级别14：

< manifest ... >
< uses-sdk android:minSdkVersion="14" android:targetSdkVersion="19" />
...
< /manifest >

minSdkVersion

属性声明了应用程序可兼容的最低系统版本，

targetSdkVersion

属性则声明了应用程序已优化过的最高系统版本。

高版本的 Android 系统可以兼容较低版本 API 编译出来的应用程序，因此只要使用了公开的 API，应用程序就应该可与未来的 Android 版本兼容。

注意：

targetSdkVersion

属性并不能阻止应用程序在更高版本的平台上安装，但是系统可以通过它得知应用程序是否会适用较高版本的特性变动，因此它非常重要。
如果你没有把

targetSdkVersion

修改为最新的版本，如果在最新版本的平台上运行时，系统会假定应用程序还是需要用到某些向后兼容的特性。 例如，在Android
4.4 的特性变化 中，使用

AlarmManager

API 创建的 Alarm 提醒时间缺省将不再精确，这样系统可以批量处理 Alarm 以节省电力。
但是如果应用程序的目标 API 级别小于 19，则系统仍然会沿用之前的 API 特性。

不过，假如应用程序用到了最新版本的 API，但是主体功能却不需要使用， 你就应该在运行时检查 API 级别，并在 API 版本过低时平稳地降低对系统特性的需求。 在这种情况下，请把

minSdkVersion

设置为程序主体功能需要的最低版本，并将当前系统的版本

SDK_INT

与程序所需
API 级别对应的代码常量相比较，这些常量在

Build.VERSION_CODES

中给出。 例如：

if (Build.VERSION.SDK_INT < Build.VERSION_CODES.HONEYCOMB) {
// Running on something older than API level 11, so disable
// the drag/drop features that use ClipboardManager APIs
disableDragAndDrop();
}