Android 版本platform 与api的对应关系

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

 

Code name	Version	API level
Marshmallow	6.0	API level 23
Lollipop	5.1	API level 22
Lollipop	5.0	API level 21
KitKat	4.4 - 4.4.4	API level 19
Jelly Bean	4.3.x	API level 18
Jelly Bean	4.2.x	API level 17
Jelly Bean	4.1.x	API level 16
Ice Cream Sandwich	4.0.3 - 4.0.4	API level 15, NDK 8
Ice Cream Sandwich	4.0.1 - 4.0.2	API level 14, NDK 7
Honeycomb	3.2.x	API level 13
Honeycomb	3.1	API level 12, NDK 6
Honeycomb	3.0	API level 11
Gingerbread	2.3.3 - 2.3.7	API level 10
Gingerbread	2.3 - 2.3.2	API level 9, NDK 5
Froyo	2.2.x	API level 8, NDK 4
Eclair	2.1	API level 7, NDK 3
Eclair	2.0.1	API level 6
Eclair	2.0	API level 5
Donut	1.6	API level 4, NDK 2
Cupcake	1.5	API level 3, NDK 1
(no code name)	1.1	API level 2
(no code name)	1.0	API level 1

 

 

Android版本分布图- 2015-04

 

先说一下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系统，定义了它对我们是个悲剧