本文主要是介绍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系统，定义了它对我们是个悲剧
这篇关于Android 版本platform 与api的对应关系的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
