先抛出一个问题：
我们的应用开发的时候android最新版本是6.0，当一年过去之后，7.0发布了，那么我们的应用在7.0手机上是否还能运行？会奔溃吗？
根据我们的实际经验，觉得应该不会奔溃，可能有些功能会有问题，但是具体是那一块呢？又说不太好，这就涉及到了Android的向前兼容的问题了。
我们在创建App的时候经常会设置这几个参数
android {
compileSdkVersion 23
buildToolsVersion “23.0.1”
defaultConfig {
applicationId “com.example.checkyourtargetsdk"
minSdkVersion 16
targetSdkVersion 23
versionCode 1
versionName “1.0”
}
}
其中著名的就是compileSdkVersion，minSdkVersion，targetSdkVersion。平时这些参数都是自动设置的，我们只需设置minSdkVersion，最低SDK版本，然后compileSdkVersion和targetSdkVersion可能是一致的。这就是我们平时使用AS的时候不注意的问题，平时操作习惯了，但是真的不知道这几个参数是什么意思。
minSdkVersion
最好理解的就是minSdkVersion了，就是我们的app能够运行的最小版本，如果选择16，那么就是Android 4.1 以及以上的设备才能运行我们app，如果小于这个版本，那么抱歉运行不了，我们不支持。这是应用程序支持api的下限。这也是应用商店判断这个应用是否能运行在设备上的一个依据之一。
在开发中也会根据这个下限去判断，是否可以用某个api方法，如果是下限之下的那么就会有警告，避免调用一些在新的版本已经改变或者过时的方法。
当我们引用了第三方的库，如果某几个库的minSdkVersion分别是API5，API10，API16的方法，那么我们的minSdkVersion最少就是16。
对于minSdkVersion的选择，我们应该看各个api的占比，不过因为基数太大了（十几亿）所以就算是0.7%也是个天文数字，所以我们需要根据自己应用的受众，以及是否需要适配低版本的需要，一般说来我们适配4.1以上，即minSdkVersion=16，不过还要根据自己的实际情况，去选择相应的版本号。
compileSdkVersion
compileSdkVersion是我们告诉Gradle，我们是用哪一版本的Android Sdk去编译程序的，可以使用这个版本的API，比如我们使用的是7.0的版本，compileSdkVersion=24，那么我们对于拍照裁剪图片等功能的操作，就可以使用FileProvider了。
我们需要注意的是：我们改变compileSdkVersion的版本号，本质上改变不了我们程序的运行，虽然可能会报错误❌或者警告⚠️，但compileSdkVersion 只会在编译期间起作用，因为环境是compileSdkVersion这个版本的SDK，所以你可以用一些这个版本的API，但是只是IDE给你的便利性帮助而已，帮助你检测代码，避免使用一些弃用的API。就算你用个低版本的compileSdkVersion，你依然可以那么写，但是可能会报错，报警告，但是你强制打包，其实也是没有问题的。IDE只是个工具，他的环境也只是工具的环境，不代表你应用运行时的表现。
所以希望大家用最新的sdk版本作为开发环境，compileSdkVersion设置成最新的，这样我们可以使用到最新SDK的API方法和机制。
如果我们使用了比如V4，V7包，有没有发现必须和compileSdkVersion的版本相匹配，比如我们compileSdkVersion = 26，那么V4，v7的版本也要相应的是26.xx.xx，首位的26必须一致，后两位没有要求，就是说明编译所依赖的SDK和依赖包必须是统一版本，不然两个不兼容，编译会通不过。同时也是为了使用该版本的新特性。
targetSdkVersion
targetSdkVersion是这哥三里面最难以理解的一个了，不过也是最有趣的一个。
targetSdkVersion的含义对于我们来说就有点陌生而熟悉了。
- 什么是目标设备SDK版本？
- 是和minSdkVersion相对应的上限吗？
- 如果我运行在比targetSdkVersion高的设备上，会出现什么？
- 如果是比targetSdkVersion低的设备呢？
首先targetSdkVersion是android向前兼容的主要方式，怎么说呢？官方是这样说的：
除非更新targetSdkVersion，否则不改变应用的行为。 这允许您在处理行为更改之前使用新的API（如您更新过的compileSdkVersion）
简单的说就是你的应用已经针对这个版本的手机，做了充分的兼容性处理和测试性处理，比如 if(Build.VERSION.SDK_INT >= 23) { ... } ，这样针对不同的SDK版本做不同的处理，这就说明我们不能随便的改变targetSdkVersion得值，我们必须做好充足的兼容性处理和测试处理才行。
在 Android 4.4 (API 19）以后，AlarmManager 的 set() 和 setRepeat() 这两个 API 的行为发生了变化。在 Android 4.4 以前，这两个 API 设置的都是精确的时间，系统能保证在 API 设置的时间点上唤醒 Alarm。因为省电原因 Android 4.4 系统实现了 AlarmManager 的对齐唤醒，这两个 API 设置唤醒的时间，系统都对待成不精确的时间，系统只能保证在你设置的时间点之后某个时间唤醒。虽然api的名字没有改变，但是功能结果已经发生改变，我们设置targetSdkVersion为16，Android4.4之前,那么我们在Android4.4之后运行会出现什么呢？难道就不能用了吗？不准确了吗？
当然不是，系统通过targetSdkVersion来保证Android的向前兼容性，在Android4.4之后的设备上，系统会判断你的targetSdkVersion是否小于19，如果小于的话，那就按照19之前的api方法，如果大于等于19，那么就按照之后的api方法来走，保证了程序运行的一致性。也就是向前兼容性。
但是还有一个问题：
Android 6.0新增加了动态权限申请，我们的targetSdkVersion是5.0，如果我们运行在Android 6.0的设备上怎么办？
因为我们这个可以向前兼容，向后不行啊，如果你的代码里处理了Android 6.0的动态权限处理，那么可以的，如果没呢？你想啥呢大哥？更新应用处理呗~~
targetSdkVersion 的大部分更新变化都会记录在VERSION_CODES，所有的细节也会在每个版本的平台亮点写明。
targetSdkVersion保证的是api的一致性。
所以一般minSdkVersion <targetSdkVersion<= compileSdkVersion
不随意更改targetSdkVersion，更改targetSdkVersion必须做好兼容。
Gradle和SDK版本
所以设置正确的compileSdkVersion，minSdkVersion和targetSdkVersion很重要。正如Gradle和Android Studio的世界中的那样，这些值通过包含在我们模块的build.gradle文件中（也可通过Android Studio中的Project Structure选项获得）集成到工具系统中:
android {
compileSdkVersion 23
buildToolsVersion“23.0.1”
defaultConfig {
applicationId“com.example.checkyourtargetsdk”
minSdkVersion 7
targetSdkVersion 23
versionCode 1
versionName“1.0”
}
}
compileSdkVersion是一个编译时的事情（TMD这谁知道），是与我们的构建工具版本一起使用的Android设置之一。
minSdkVersion和targetSdkVersion不同于compileSdkVersion，因为它们包含在APK中。查看生成的AndroidManifest.xml
<uses-sdk android：targetSdkVersion =“23”android：minSdkVersion =“16”/>
理清楚这些后，下次更改这些参数的时候，就不会犯一些低级错误了。但是其中的更细节的东西，需要看android编译原理和运行原理了，任重而道远，这只是一个结果论。