引言

使用Android Studio编写构建一个Android项目时，需要我们配置build.gradle文件，如下：

……android {    compileSdkVersion 23    buildToolsVersion "23.0.3"    defaultConfig {        minSdkVersion 16        targetSdkVersion 22    }    ……}

对于compileSdkVersion，minSdkVersion，targetSdkVersion和buildToolsVersion这四个参数的意义，可能很多人和我一样并没有清楚地了解。

以下就来分析一下它们的概念。

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和新特性提供兼容性支持。

minSdkVersion

minSdkVersion表示应用可以运行的最低要求。minSdkVersion是Google Play商店用来判断用户设备是否可以安装某个应用的标志之一。如果设备的API低于minSdkVersion，那就安装不上该应用。

在开发时minSdkVersion也起到一个重要角色：lint 默认会在项目中运行，它在你使用了高于minSdkVersion的API时会警告你，帮你避免调用不存在的API的运行时问题。如果只在较高版本的系统上才使用某些API，通常使用运行时检查系统版本的方式解决，例如：

Android Studio的提示，很明显，requestPermissions()只能在API大于等于23上的设备上才可以调用。

那我们就针对该情况特殊处理：

        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {            requestPermissions(new String[]{""}, REQUEST_CODE_ASK_CALL_PHONE);        } else {            //不需要申请权限直接调用我们需要处理的方法。        }

当设备的版本号大于Android6.0，就调用requestPermissions()，否则就不做处理。

请记住，你所使用的库，如Support Library或 Google Play Services，可能有他们自己的 minSdkVersion。你的应用设置的minSdkVersion必需大于等于这些库的minSdkVersion。例如有三个库，它们的minSdkVersion分别是4, 7和9，那么你的minSdkVersion必需至少是9才能使用它们。在少数情况下，你仍然想用一个比你应用的minSdkVersion还高的库（处理所有的边缘情况，确保它只在较新的平台上使用），你可以使用tools:overrideLibrary标记，但请做彻底的测试。

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 之前做测试。

一个Android系统，对外提供一套API，如何选择targetSdkVersion取决于应用程序需要实现的功能，如果你的应用程序使用API 7就可以实现的功能，可以不用考虑使用API 24，使用低版本API的其中一个好处，可以让更多的Android系统运行的效果保持一致，即兼容性更好，打个比方：API 7开发的APP可能兼容98%以上的Android手机，而API 24开发的APP可能兼容仅有60%，所谓的不兼容并不是无法正常运行，而是在不同Android系统的手机运行的效果差异比较大，会让用户感觉难以接受；使用低版本API的其中一个不足，显示的效果比较OUT，提供的可用的接口或类比较少，本来一句代码可以完成的功能（封装的类或接口），需要自己花一天琢磨写很多的代码，也就是有高版本API的其中一个原因，提供更多的或封装好的应用程序接口让开发者使用。

系统版本和targetSdkVersion关系

1.系统版本高于targetSdkVersion

假设我们的targetSdkVersion是22（就是5.0）不需要动态申请权限，但是我们的系统是6.0的。现在程序运行到了需要某个需要权限的地方了。此时想想我们的手机该怎么办？系统逻辑是这样的：

        final int targetSdkVersion= getApplicationContext().getApplicationInfo().targetSdkVersion;        if (targetSdkVersion < Build.VERSION_CODES.M) {            //这里的M就是level 23也就是6.0的系统            //这里的判断是如果当前的打包的targetSdkVersion小于23            //那么这里就不需要动态申请权限直接可以调取开放的权限        } else {            //否则系统认为你需要动态申请权限        }

以上这不代码系统源码，只是说处理逻辑。

注意这里是系统处理，不需要你显式地写这些代码，是系统内部的代码和自动处理。

2.系统版本等于targetSdkVersion

当安装app的时候targetSdkVersion刚好等需系统的level，这个时候Andorid平台会认为这个程序在此版本上已经经过了充分的测试。不必为此程序开启兼容性检查判断的工作了。也就是说，如果targetSdkVersion与目标设备的API版本相同时，运行效率可能会高一些。

3.系统版本小于targetSdkVersion

还是举个例子：targetSdkVersion=23的时候，但是系统版本是22，很明显你在代码里面做了动态权限分配，但是系统版本不支持。

之前minSdkVersion中的例子已经做了处理了。

buildToolsVersion

buildToolsVersion表示的是构建工具的版本号，规则是可以用高版本的构建工具来构建使用低版本SDK的工程。

其他

minSdkVersion和targetSdkVersion与compileSdkVersion的区别

另一个不同之处是minSdkVersion和targetSdkVersion会被包含进最终的APK文件中，而compileSdkVersion则不会，如果你查看生成的AndroidManifest.xml文件，你会看到类似下面这样的标签：

<uses-sdkandroid:targetSdkVersion="23" android:minSdkVersion="7"/>

如果你在AndroidManifest文件中手工设置，你会发现 Gradle 在构建时会忽略它们（尽管其它构建系统可能会明确依赖它们）。

关于Support Library

不管是引用v4，v7还是v13，总体来说他们就是一个libs，和我们引用在github上的libs一模一样。

因为android版本碎片化太严重了，说一个案例，在刚开始的时候Android系统是没有ViewPager的。是后面的系统才出现的。那么以前的系统想用ViewPager该怎么办呢？好办，和我们项目需要自定义某些特殊的View一样，没有的话我们要么自己写，要么到github上面去找然后引入到我们的项目中。这里就引入Support Library。

v4的意思是什么呢？就是说这个包可以兼容到1.6的系统，所以1.6以下的系统是用不了的。v7包的意思就是可以兼容到2.3的系统。另外v7包是依赖v4包的。可以看出v4包的minSdk肯定是等于1.6了。v7包的minSdk就会是2.3。

v13包主要是在平板上使用，一般在手机端不会用。

参考：
1.android开发如何选择compileSdkVersion, minSdkVersion 和 targetSdkVersion
2.关于Android SDK里的compileSdk、minSdk、targetSdk、buildTools、Tools、Platform-tools
3.compileSdkVersion，minSdkVersion，targetSdkVersion 的区别和比较
4.新手的第一个Android项目该如何选择targetSdkVersion
5.Android targetSdkVersion 原理

Android中的compileSdkVersion，minSdkVersion，targetSdkVersion和buildToolsVersion

引言