首页 > 代码库 > Android的minSdkVersion,targetSdkVersion,maxSdkVersion

Android的minSdkVersion,targetSdkVersion,maxSdkVersion

 

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系统,定义了它对我们是个悲剧

Android的minSdkVersion,targetSdkVersion,maxSdkVersion