Android的minSdkVersion，targetSdkVersion，maxSdkVersion - edisonlg的专栏 - 博客频道 - CSDN.NET

http://blog.csdn.net/edisonlg/article/details/7855898

API Level 是一个整型值，表示Android发布的某个特定版本，新API Level相对于老API Level会增加以下内容：

* 新增类、或者已有类中新增、修改、甚至删除的API

* 新定义的xml tag

* 新定义Intent

* 新定义的Permission

* 其它…

API Level和版本有如下对应关系：

Platform Version API Level

Android 3.0 11

Android 2.3.3 10

Android 2.3 9

Android 2.2 8

Android 2.1 7

Android 2.0.1 6

Android 2.0 5

Android 1.6 4

Android 1.5 3

Android 1.1 2

Android 1.0 1

先说一下minSdkVersion的用处：

新版本中public了老版本没有的接口，如果我写的一个App中用到了只有新版本才有的接口，肯定不能让它跑在老版本SDK上，不然会报错。 Android是如何保证这一点的？靠定义minSdkVersion来实现。 比如，如果我定义了<uses-sdk android:minSdkVersion="8"  ... />, 编译生成的apk是无法安装到Android 2.1(API Level 7)系统上的，系统会提示： ERROR: Application requires API version 8. Device API version is 7。

AndroidManifest.xml中如果不写，缺省 minSdkVersion = 1， 表示程序至少能安装到，并且作者也希望它能跑到Android 1.0上。

接下来说一下targetSdkVersion的用处：

一般而言，新版本要兼容老版本，这就是为什么Android中很多接口即使过时了(deprecated)但还依然保留在新SDK中，所以绝大多数情况下，为老版本开发的应用可以运行在新版SDK上。但是也有一些例外，主要是以下三类问题：

1. 老接口被删除或修改了（这种case有，但很少），本文不关注

2. 同样的接口，但新老版本的实现有所不同。比如有一些API早期设计时考虑不周全，新版本做了改进。

3. 即使不涉及任何接口调用，但由于物理设备的扩展，同样的apk需要在新版本上需要适配更多的物理设备，从而具备了新的特性

对于第二类问题，指定targetSdkVersion为具体的某个API Level，则表示调用接口时只会调用该版本实现的API，而不是早期版本的API。

对于第三类问题，就是这封信碰到情况，Google从开发Android 1.6 （API Level 4）开始意识到，程序运行时需要考虑到手机屏幕大小、分辨率不同。因此从1.6开始引入了针对多屏幕的支持，定义了不同屏幕尺寸与分辨率、密度的一个对应关系。注意到此前google只意识到会在中密度屏幕（mdpi）下开发，所以1.5以及以前版本的图片图标等资源、布局都是按照中密度屏幕设计的。

从Android 1.6开始，Google提供了多套资源（ldpi, mdpi, hdpi) 支持，对内置应用以及Framework的资源（比如控件），系统可以在编译时刻决定只打包某个特定密度的资源(定义在PRODUCT_LOCALES中，对N1,应该是PRODUCT_LOCALES := hdpi ...）。

对基于SDK开发的应用，eclipse缺省会打包所有密度的资源，在Android 1.6之后的版本上跑，会在运行时刻根据物理设备实际密度来选择对应密度的资源。

如果某个App中定义的targetSdkVersion <= 3, , 表示该App无法用到Android 1.6才有的多屏幕支持能力， 所以即使应用本身包含了hdpi,mdpi,ldpi资源，但运行到hdpi的物理设备上时只会去加载mdpi的资源，当然显示就不正常了。

注意：如果App中也用到的系统级资源（比如控件），一般来说特定的物理设备只可能是hdpi,mdpi, ldpi (以后会有扩展，比如xdpi）中的一种，所以只会加载那唯一的一种dpi资源，因此显示系统控件本来不应该有任何问题。不过，如果Image没有优化，而是包含了所有资源，那么控件显示也会不正常 。

 

再回到正题上来，为什么eclipse下编译的程序运行起来和ubuntu下编译的显示效果不同？

在ubuntu下编译，系统认为你编译的是内置应用，内置应用在正常情况下不会被变态的人扒出来放到其他设备上去，所以不存在安装兼容性问题，minSdkVersion缺省就是当前物理设备的current sdk version。另外既然是内置应用，当然运行在当前物理设备上效果最好，所以targetSdkVersion缺省也是当前物理设备的current sdk version。这个在编译时刻打包apk时，build system首先检测这两个值有没有设置，没设置的话它会替你加上。 

在eclipse下编译，系统认为你编译的是第三方应用，忘了写就是你的错了，minSdkVersion和targetSdkVersion缺省都是1，所以会出现上面说到的悲剧。

结论：

1. 对内置应用，不要自己去设置minSdkVersion和targetSdkVersion；

2. 基于SDK开发的，根据自己的实际情况，一定要设置minSdkVersion和targetSdkVersion；

3. 刚刚没说maxSdkVersion，我们别定义它，以后可能会OTA升级整个Android系统，定义了它对我们是个悲剧