compileSdkVersion，targetSdkVersion和minSdkVers。。。
**
compileSdkVersion，targetSdkVersion和minSdkVersion
**
*compileSdkVersion
城市生活垃圾处理*定义应⽤程序编译选择哪个Android SDK版本，通常compileSDKVersion属性值被设置为最新的API版本，例如：25，改变compileSDKVersion的属性值不会影响Android系统运⾏⾏为，⽐如说，将属性值设置为25，targetSdkVersion属性值为23，代码如下：
compileSdkVersion 25
buildToolsVersion "25.0.2"
defaultConfig {
applicationId "cn.teachcour.demos"
minSdkVersion 11
targetSdkVersion 23
怎样玩魔方versionCode 1
versionName "1.0"
testInstrumentationRunner "st.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或Eclip开发⼯具将提醒开发者引⽤⼀个未定义的⽅法，使⽤该⽅法需要将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掉。
