compileSdkVersion
compileSdkVersion 告诉 Gradle 用哪个 Android SDK 版本编译你的应用。它纯粹只是在编译的时候使用。当你修改了 compileSdkVersion 的时候，可能会出现新的编译警告、编译错误等（你真的应该修复这些警告，他们的出现一定是有原因的）。需要强调的是修改 compileSdkVersion 不会改变运行时的行为，compileSdkVersion 并不会打包进APK里只是在编译时使用
因此我们强烈推荐总是使用最新的 SDK 进行编译。在自己的代码上使用最新SDK的编译检查（lint？）可以获得很多好处，可以避免使用最新弃用的 API ，并且为使用新的 API 做好准备。
minSdkVersion
minSdkVersion 是应用可以运行的最低版本要求。minSdkVersion 是 Google Play 商店用来判断用户设备是否可以安装某个应用的标志之一。
targetSdkVersion
compileSdkVersion 和 minSdkVersion 都非常好理解，前者表示编译的 SDK 版本，后者表示应用兼容的最低 SDK 版本。但是对于 targetSdkVersion 其实很难一句话解析清楚，原文：The most interesting of the three, however, is targetSdkVersion. 。以前我也有一些迷糊，看到有些人和我有同样的困惑，本文试图彻底解决这个问题。
原文：targetSdkVersion is the main way Android provides forward compatibility
targetSdkVersion 是 Android 系统提供前向兼容的主要手段。这是什么意思呢？随着 Android 系统的升级，某个 API 或者模块的行为可能会发生改变，但是为了保证APK 的行为还是和以前一致。只要 APK 的 targetSdkVersion 不变，即使这个 APK 安装在新 Android 系统上，其行为还是保持老的系统上的行为，这样就保证了系统对老应用的前向兼容性。
这时，虽然 API 没有任何变化，但是实际上 API 的行为却发生了变化，如果 APK 中使用了此 API，并且在应用中的行为非常依赖 AlarmManager 在精确的时间唤醒，例如闹钟应用。如果 Android 系统不能保证兼容，老的 APK 安装在新系统手机上，就会出现问题。
Android 系统是怎么保证这种兼容性的呢？这时候 targetSdkVersion 就起作用了。APK 在调用系统 AlarmManager 的 set() 或者 setRepeat() 的时候，系统首先会查一下调用的 APK 的 targetSdkVersion 信息，如果小于 19，就还是按照老的行为，即精确设置唤醒时间，否者执行新的行为。
我们来看一下 Android 4.4 上 AlarmManger 的一部分源代码：
private final boolean mAlwaysExact;
AlarmManager(IAlarmManager service, Context ctx) {
mService = service;
final int sdkVersion = ctx.getApplicationInfo().targetSdkVersion;
mAlwaysExact = (sdkVersion < Build.VERSION_CODES.KITKAT);
}
看到这里，首选获取应用的 targetSdkVersion，判断是否是小于 Build.VERSION_CODES.KITKAT (即 API Level 19)，来设置 mAlwaysExact 变量，表示是否使用精确时间模式。
public static final long WINDOW_EXACT = 0;
public static final long WINDOW_HEURISTIC = -1;
private long legacyExactLength() {
return (mAlwaysExact ? WINDOW_EXACT : WINDOW_HEURISTIC);
}
public void set(int type, long triggerAtMillis, PendingIntent operation) {
setImpl(type, triggerAtMillis, legacyExactLength(), 0, operation, null);
}
这里看到，直接影响到 set() 方法给 setImpl() 传入不同的参数，从而影响到了 set() 的执行行为。具体的实现在 AlarmManagerService.java，这里就不往下深究了。
看到这里，发现其实 Android 的 targetSdkVersion 并没有什么特别的，系统使用它也非常直接，甚至很“粗糙”。仅仅是用过下面的 API 来获取 targetSdkVersion，来判断是否执行哪种行为：getApplicationInfo().targetSdkVersion;
最后，我们也可以理解原文中说的那句话的含义，明白了为什么修改了 APK 的 targetSdkVersion 行为会发生变化，也明白了为什么修改 targetSdkVersion 需要做完整的测试了。
Gradle和SDK版本
所以设置正确的 compileSdkVersion, minSdkVersion 和 targetSdkVersion 很重要。
build.gradle设置<uses-sdk android:targetSdkVersion="23" android:minSdkVersion="7" />
如果你在 manifest 文件中手工设置，你会发现 Gradle 在构建时会忽略它们（尽管其它构建系统如eclipse、ant可能会依赖它们）。
综合来看如果你按照上面示例那样配置，你会发现这三个值的关系是：
minSdkVersion <= targetSdkVersion <= compileSdkVersion
理想上，在稳定状态下三者的关系应该更像这样：
minSdkVersion (lowest possible) <= targetSdkVersion == compileSdkVersion (latest SDK)
用较低的 minSdkVersion 来覆盖最大的人群，用最新的 SDK 设置 target 和 compile 来获得最好的外观和行为。