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 来获得最好的外观和行为。