本篇文章介绍了Android SDK更新的包里关于compileSdk、minSdk、targetSdk、buildTools、Tools、Platform-tools的概念
0 前言
在开发中经常发现有AS有更新提示，在之前没有完全弄明白这些SDK，Tools的概念前都不敢轻易去更新，总担心更完就编译出错，API不能用==情况。所以对这几个概念进行深度梳理。
1 参考文章
国外一篇很清楚的关于compileSdk、minSdk、targetSdk的文章，建议看完译文后再重新看一遍原文
原文：picking-your-compilesdkversion-minsdkversion-targetsdkversion
译文：如何选择 compileSdkVersion, minSdkVersion 和 targetSdkVersion
关于tools的解释：Android关于buildToolVersion与CompileSdkVersion的区别
2 compileSdk、minSdk、targetSdk到概念
以下内容摘自译文
2.1 compileSdkVersion
compileSdkVersion 告诉 Gradle 用哪个 Android SDK 版本编译你的应用。使用任何新添加的 API 就需要使用对应 Level 的 Android SDK。
需要强调的是 修改 compileSdkVersion 不会改变运行时的行为 。当你修改了 compileSdkVersion 的时候，可能会出现新的编译警告、编译错误，但新的 compileSdkVersion 不会被包含到 APK 中：它纯粹只是在编译的时候使用。（你真的应该修复这些警告，他们的出现一定是有原因的）
因此我们强烈推荐 总是使用最新的 SDK 进行编译 。在现有代码上使用新的编译检查可以获得很多好处，避免新弃用的 API ，并且为使用新的 API 做好准备。
注意，如果使用 Support Library ，那么使用最新发布的 Support Library 就需要使用最新的 SDK 编译。例如，要使用 23.1.1 版本的 Support Library ，compileSdkVersion 就必需至少是 23 （大版本号要一致！）。通常，新版的 Support Library 随着新的系统版本而发布，它为系统新增加的 API 和新特性提供兼容性支持。
2.2 minSdkVersion
如果 compileSdkVersion 设置为可用的最新 API，那么 minSdkVersion 则是应用可以运行的最低要求。minSdkVersion 是 Google Play 商店用来判断用户设备是否可以安装某个应用的标志之一。
在开发时 minSdkVersion 也起到一个重要角色：lint 默认会在项目中运行，它在你使用了高于 minSdkVersion 的 API 时会警告你，帮你避免调用不存在的 API 的运行时问题。如果只在较高版本的系统上才使用某些 API，通常使用运行时检查系统版本的方式解决。
请记住，你所使用的库，如 Support Library 或 Google Play services，可能有他们自己的 minSdkVersion 。你的应用设置的 minSdkVersion 必需大于等于这些库的 minSdkVersion 。例如有三个库，它们的 minSdkVersion 分别是 4, 7 和 9 ，那么你的 minSdkVersion 必需至少是 9 才能使用它们。在少数情况下，你仍然想用一个比你应用的 minSdkVersion 还高的库（处理所有的边缘情况，确保它只在较新的平台上使用），你可以使用 tools:overrideLibrary 标记，但请做彻底的测试！
当你决定使用什么 minSdkVersion 时候，你应该参考当前的 Android 分布统计，它显示了最近 7 天所有访问 Google Play 的设备信息。他们就是你把应用发布到 Google Play 时的潜在用户。最终这是一个商业决策问题，取决于为了支持额外 3% 的设备，确保最佳体验而付出的开发和测试成本是否值得。
当然，如果某个新的 API 是你整个应用的关键，那么确定 minSdkVersion 的值就比较容易了。不过要记得 14 亿设备中的 0.7％ 也是个不小的数字。
2.3 targetSdkVersion
三个版本号中最有趣的就是 targetSdkVersion 了。 targetSdkVersion 是 Android 提供向前兼容的主要依据，在应用的 targetSdkVersion 没有更新之前系统不会应用最新的行为变化。这允许你在适应新的行为变化之前就可以使用新的 API （因为你已经更新了 compileSdkVersion 不是吗？）。
targetSdkVersion 所暗示的许多行为变化都记录在 VERSION_CODES 文档中了，但是所有恐怖的细节也都列在每次发布的平台亮点中了，在这个 API Level 表中可以方便地找到相应的链接。
例如，Android 6.0 变化文档中谈了 target 为 API 23 时会如何把你的应用转换到运行时权限模型上，Android 4.4 行为变化阐述了 target 为 API 19 及以上时使用 set() 和 setRepeating() 设置 alarm 会有怎样的行为变化。由于某些行为的变化对用户是非常明显的（弃用的 menu 按钮，运行时权限等），所以将 target 更新为最新的 SDK 是所有应用都应该优先处理的事情。但这不意味着你一定要使用所有新引入的功能，也不意味着你可以不做任何测试就盲目地更新 targetSdkVersion ，请一定在更新 targetSdkVersion 之前做测试！你的用户会感谢你的。
3 buildTools、Tools、Platform-tools
buildTools、Tools、Platform-tools这3个东西其实都是开发工具，即它的版本更新并不会影响运行的APP，只是工具上的升级。
在 build.gradle 中的 buildToolsVersion 版本号一般是API-LEVEL.0.0，其中API-LEVEL要大于等于compileSdkVersion。
在前面的compileSdkVersion解释中建议选用最新的SDK Version，so，buildToolsVersion也建议选择最新的版本号。build.gradle中这2个的修改可以让你体验最新的API和工具。
至于Tools、Platform-tools这2个东西，直接更新最新吧。Only 工具。
总结
经过上面的深入了解后，总结以下：
当AS提示Gradle或者Android SDK更新后，大胆更新吧，先全部下载下来
更新完后，直接将compileSdkVersion、buildToolsVersion修改为最新的版本号，放心的更改，该完后如果有废弃API编译器还会给你提示。
minSdkVersion 和 targetSdkVersion 要慎重修改。除非核心代码中会提高minSdkVersion的版本号，其他的建议运行时判断版本号。targetSdkVersion的修改要注意代码是否适应更新后的版本号，要测试完全，最典型的例子就是23版本的运行时权限问题的处理。如果targetSdkVersion提升到了23，如果代码没有进行运行时权限判断会直接崩溃。
