compileSdkVersion，targetSdkVersion和minSdkVersion三者的关系

**

compileSdkVersion，targetSdkVersion和minSdkVersion

**

*compileSdkVersion

*定义应用程序编译选择哪个Android SDK版本，通常compileSDKVersion属性值被设置为最新的API版本，例如：25，改变compileSDKVersion的属性值不会影响Android系统运行行为，比如说，将属性值设置为25，targetSdkVersion属性值为23，代码如下：

compileSdkVersion 25
buildToolsVersion "25.0.2"
defaultConfig {
    applicationId "cn.teachcourse.demos"
    minSdkVersion 11
    targetSdkVersion 23
    versionCode 1
    versionName "1.0"
    testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
}

开发的应用程序在Android 7.0系统运行，不会以Android 7.0新增的行为运行，决定Android系统行为的仍然是targetSDKVersion，那么compileSDKVersion有什么用呢？选择最新的API版本，在编译的时候检查代码的错误和警告，提示开发者修改和优化，因为通常在Android项目中会引入第三方的支持库，支持库使用了23.1.1版本，compileSdkVersion的属性值至少为23.0.0，新版本的支持库的发布紧跟着对应的Android系统平台，能够更好的兼容。

minSdkVersion

定义应用程序支持的最低API版本，最低版本设置为API 11，目标版本设置为API 24，那么应用程序调用使用API 14提供的方法时，Android Studio或Eclipse开发工具将提醒开发者引用一个未定义的方法，使用该方法需要将minSdkVersion设置为API 14以上，如下图：

继续在上述代码，造成的结果大于或等于Android 4.0的系统可以正常执行，小于Android 4.0的系统将在运行时尝试访问不可用的 API 时发生崩溃。

---

targetSdkVersion

即目标软件开发版本，在创建每一个Android项目的时候都需要选择targetSdkVersion和minSdkVersion，一个targetSdkVersion的属性值表示创建的Android项目使用哪个API版本，一个API版本使用一个整型数字表示，API的全称是Application Programming Interface，即应用程序编程接口，API 19对应的编程接口和API 23定义的编程接口存在差别，因为使用整型数字表示targetSdkVersion的属性值，容易记忆和便于比较它们之间的大小，高版本API编程接口可以兼容低版本API编程接口，反之则不行。

需要区别Android 7.0和API 24之间的关系，Android 7.0定义的手机系统的版本，该系统的版本对外开放的应用程序接口被定义为API 24，如果开发者想要在开发的APP中使用Android 7.0系统提供的功能，这些功能包括：多窗口支持、通知显示变更、JIT/AOT编译、快速的应用安装路径等等，那么新手在创建的Android项目的时候就需要选择API 24的应用程序接口。

这样一来我们就可以知道，版本号的大小关系就是：compileSdkVersion>targetSdkVersion>minSdkVersion

compileSdkVersion代表着编译的时候，会采用该api的规范进行代码检查和警告，但是并不会编译进apk中。
targetSdkVersion代表着目标版本，在编译的时候会将该版本的api编译进apk中。
minSdkVersion 代表着最低版本，在编译的时候兼容到该参数指定最低版本api。

安卓中的兼容其实是，各个api接口中通过判断系统的版本来兼容的，比如最常见的view的创建过程，就是在创建之前判断当前运行的安卓系统版本是多少，然后调用对应的api接口进行创建。targetSdkVersion，minSdkVersion的版本问题就迎刃而解了，说明打包的时候将最高版本的api接口到最低版本之间的api打包进apk，如果安装到范围之外的安卓系统中，那么运行程序肯定就是找不到方法的错误出现。而如果targetSdkVersion版本低于23，但是装在了6.0以上的系统中的话，那么动态权限申请的api没有打包进apk，所以自然还是走低版本的权限流程，不需要动态申请就可以获得权限了。安卓系统至于为什么会兼容低于自己系统的targetSdkVersion版本，也是因为源码里面对api接口调用做了版本判断，用于向下兼容。

targetSDKVersion
简单来说就代表着你的App能够适配的系统版本，意味着你的App在这个版本的手机上做了充分的 前向 兼容性处理和实际测试。其实我们写代码时都是经常干这么一件事，就是 if(Build.VERSION.SDK_INT >= 23) { … } ，这就是兼容性处理最典型的一个例子。如果你的target设置得越高，其实调用系统提供的API时，所得到的处理也是不一样的，甚至有些新的API是只有新的系统才有的

Android6.0普通权限normal permission 和 危险权限dangerous permission
Normal Permission：写在xml文件里，那么App安装时就会默认获得这些权限，即使是在Android6.0系统的手机上，用户也无法在安装后动态取消这些normal权限，这和以前的权限系统是一样的，不变。

Dangerous Permission：还是得写在xml文件里，但是App安装时具体如果执行授权分以下几种情况：

1、targetSDKVersion < 23 & API(手机系统) < 6.0 ：安装时默认获得权限，且用户无法在安装App之后取消权限。
3、targetSDKVersion < 23 & API(手机系统) >= 6.0 ：安装时默认获得权限，但是用户可以在安装App完成后动态取消授权（ 取消时手机会弹出提醒，告诉用户这个是为旧版手机打造的应用，让用户谨慎操作 ）。

2、targetSDKVersion >= 23 & API(手机系统) < 6.0 ：安装时默认获得权限，且用户无法在安装App之后取消权限。

4、targetSDKVersion >= 23 & API(手机系统) >= 6.0 ：安装时不会获得权限，可以在运行时向用户申请权限。用户授权以后仍然可以在设置界面中取消授权，用户主动在设置界面取消后，在app运行过程中可能会出现crash。

再举一个一例子来说明这三者的关系，现在有一个类Icon，这个类是在api版本23加入到android frame源码中的，如果compileSdkVersion=28，targetSdkVersion=23 ，minSdkVersion=16的话，编译是不会有任何问题的，因为我的targetSdkVersion版本就包含了Icon这个类，如果我将其设置为22就会报错，说找不到这个类，因为android.jar架包内不存在这个类，如果我将targetSdkVersion设置为23，并且打包出来的apk安装到5.0的手机上的时候，会发现程序闪退，之所这样是因为，android.jar只参与编译（frame层代码是手机自带的，不会从外部打包进apk的），并不会打包进apk，这样apk在调用Icon类的时候，使用的是安卓手机自带的frame层代码，Icon在api23引入，5.0的手机自然就没有，程序自然就会crash掉。