Android targetSdkVersion 原理+总结

懒人看总结：

1.targetSDKVersion是 Android 系统提供前向兼容的主要手段。随着 Android 系统的升级，某个系统的 API 或者模块的行为可能会发生改变，但是为了保证老 APK 的行为还是和以前兼容。只要 APK 的 targetSdkVersion 不变，即使这个 APK 安装在新 Android 系统上，其行为还是保持老的系统上的行为，这样就保证了系统对老应用的前向兼容性。

2.您可以通过将targetSdkVersion指定为与应用所运行平台的 API 级别一致来停用此类兼容性行为。 例如，如果将该值设置为“11”或更高，系统便可在您的应用运行在 Android 3.0 或更高版本的平台上时对其应用新的默认主题 (Holo)，还可在您的应用运行在更大屏幕上时停用屏幕兼容性模式（因为对 API 级别 11 的支持隐含了对更大屏幕的支持）。其默认值为minSdkVersion指定的值相等。

谷歌中文解释：https://developer.android.google.cn/guide/topics/manifest/uses-sdk-element.html#ApiLevels

-------------------------------------------------------------下面是摘抄分析----------------------------------------------- 

前几天 Google 官方发布文章解析 compileSdkVersion、minSdkVersion 以及 targetSdkVersion 的含义，以及合理设置各个值的意义，原文 Picking your compileSdkVersion, minSdkVersion, and targetSdkVersion（后面简称 “原文”），还有翻译版。

其中，compileSdkVersion 和 minSdkVersion 都非常好理解，前者表示编译的 SDK 版本，后者表示应用兼容的最低 SDK 版本。但是对于 targetSdkVersion 其实很难一句话解析清楚，原文用了“万能”的词 ―― interesting 来描述。以前我也有一些迷糊，看到有些人和我有同样的困惑，本文试图彻底解决这个问题。

原文是这么说的：

targetSdkVersion is the main way Android provides forward compatibility

targetSdkVersion 是 Android 系统提供前向兼容的主要手段。这是什么意思呢？随着 Android 系统的升级，某个系统的 API 或者模块的行为可能会发生改变，但是为了保证老 APK 的行为还是和以前兼容。只要 APK 的 targetSdkVersion 不变，即使这个 APK 安装在新 Android 系统上，其行为还是保持老的系统上的行为，这样就保证了系统对老应用的前向兼容性。

android:targetSdkVersion

一个用于指定应用的目标 API 级别的整数。如果未设置，其默认值与为 minSdkVersion 指定的值相等。

该属性用于通知系统，您已针对目标版本进行测试，并且系统不应启用任何兼容性行为来保持您的应用与目标版本的向前兼容性。 应用仍可在较低版本上运行（最低版本为 minSdkVersion）。

在 Android 随着每个新版本的推出而进化的过程中，一些行为甚至是外观可能会发生变化。不过，如果平台的 API 级别高于您的应用的targetSdkVersion 所声明的版本，系统就可以通过启用兼容性行为来确保您的应用继续以您所期望的方式工作。您可以通过将targetSdkVersion 指定为与应用所运行平台的 API 级别一致来停用此类兼容性行为。例如，如果将该值设置为“11”或更高，系统便可在您的应用运行在 Android 3.0 或更高版本的平台上时对其应用新的默认主题 (Holo)，还可在您的应用运行在更大屏幕上时停用屏幕兼容性模式（因为对 API 级别 11 的支持隐含了对更大屏幕的支持）。

系统可根据您为该属性设置的值启用许多兼容性行为。 Build.VERSION_CODES 参考资料中的相应平台版本对其中的几种行为做了说明。

要让您的应用与各 Android 版本保持同步，您应该增加该属性的值，使其与最新 API 级别一致，然后在相应平台版本上对您的应用进行全面测试。

这里还是用原文的例子，在 Android 4.4 (API 19）以后，AlarmManager 的 set() 和setRepeat() 这两个 API 的行为发生了变化。在 Android 4.4 以前，这两个 API 设置的都是精确的时间，系统能保证在 API 设置的时间点上唤醒 Alarm。因为省电原因 Android 4.4 系统实现了 AlarmManager 的对齐唤醒，这两个 API 设置唤醒的时间，系统都对待成不精确的时间，系统只能保证在你设置的时间点之后某个时间唤醒。

这时，虽然 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;

所以，我们可以猜测到，如果 Android 系统升级，发生这种兼容行为的变化时，一般都会在原来的保存新旧两种逻辑，并通过 if-else 方法来判断执行哪种逻辑。果然，在源码中搜索，我们会发现不少类似 getApplicationInfo().targetSdkVersion < Buid.XXXX 这样的代码，相对于浩瀚的 Android 源码量来说，这些还是相对较少了。其实原则上，这种会导致兼容性问题的修改还是越少越好，所以每次发布新的 Android 版本的时候，Android 开发者网站都会列出做了哪些改变，在这里，开发者需要特别注意。

最后，我们也可以理解原文中说的那句话的含义，明白了为什么修改了 APK 的 targetSdkVersion 行为会发生变化，也明白了为什么修改 targetSdkVersion 需要做完整的测试了。

写完这篇文章，再回头去看一下原文的 targetSdkVersion 那一段，发现作者是说的多么“滴水不漏”。

原文出处：http://www.race604.com/android-targetsdkversion/