先抛出一个问题：
我们的应用开发的时候android最新版本是6.0，当一年过去之后，7.0发布了，那么我们的应用在7.0手机上是否还能运行？会奔溃吗？

根据我们的实际经验，觉得应该不会奔溃，可能有些功能会有问题，但是具体是那一块呢？又说不太好，这就涉及到了Android的向前兼容的问题了。

我们在创建App的时候经常会设置这几个参数

android {compileSdkVersion 23buildToolsVersion “23.0.1”defaultConfig {applicationId “com.example.checkyourtargetsdk"minSdkVersion 16targetSdkVersion 23versionCode 1versionName “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 23buildToolsVersion“23.0.1” defaultConfig { applicationId“com.example.checkyourtargetsdk” minSdkVersion 7 targetSdkVersion 23versionCode 1 versionName“1.0” }
}

compileSdkVersion是一个编译时的事情（TMD这谁知道），是与我们的构建工具版本一起使用的Android设置之一。

minSdkVersion和targetSdkVersion不同于compileSdkVersion，因为它们包含在APK中。查看生成的AndroidManifest.xml

<uses-sdk android：targetSdkVersion =“23”android：minSdkVersion =“16”/>

理清楚这些后，下次更改这些参数的时候，就不会犯一些低级错误了。但是其中的更细节的东西，需要看android编译原理和运行原理了，任重而道远，这只是一个结果论。

大家可以点个关注，告诉我大家想要深入探究哪些问题，希望看到哪方面的文章，我可以免费给你写专题文章。。哈哈。。。
希望大家多多支持。。你的一个关注，是我坚持的最大动力。。