minSdkVersion
我们的app能够运行的最小版本，如果选择16，那么就是Android 4.1 以及以上的设备才能运行我们app，如果小于这个版本，就运行不了。这是应用程序支持api的下限。这也是应用商店判断这个应用是否能运行在设备上的一个依据之一。
当我们引用了第三方的库，如果某几个库的minSdkVersion分别是API5，API10，API16的方法，那么我们的minSdkVersion最少就是16。
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，否则不改变应用的行为。 这允许您在处理行为更改之前使用新的API（如您更新过的compileSdkVersion）
在 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保证的是api的一致性，所以一般minSdkVersion <targetSdkVersion<=compileSdkVersion，不随意更改targetSdkVersion，更改targetSdkVersion必须做好兼容。
