Android targetSdkVersion 原理

前幾天 Google 官方發布文章解析 compileSdkVersion、minSdkVersion 以及 targetSdkVersion 的含義，以及合理設置各個值的意義，原文 Picking your compileSdkVersion, minSdkVersion, and targetSdkVersion （后面簡稱 “原文”），還有 翻譯版 。

其中，compileSdkVersion 和 minSdkVersion 都非常好理解，前者表示編譯的 SDK 版本，后者表示應用兼容的最低 SDK 版本。但是對于 targetSdkVersion 其實很難一句話解析清楚，原文用了“萬能”的詞 —— interesting 來描述。以前我也有一些迷糊，看到有些人和我有同樣的困惑，本文試圖徹底解決這個問題。

原文是這么說的：

targetSdkVersion 是 Android 系統提供前向兼容的主要手段。這是什么意思呢？隨著 Android 系統的升級，某個系統的 API 或者模塊的行為可能會發生改變，但是為了保證老 APK 的行為還是和以前兼容。只要 APK 的 targetSdkVersion 不變，即使這個 APK 安裝在新 Android 系統上，其行為還是保持老的系統上的行為，這樣就保證了系統對老應用的前向兼容性。

這里還是用原文的例子，在 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 這樣的代碼。

最后，我們也可以理解原文中說的那句話的含義，明白了為什么修改了 APK 的 targetSdkVersion 行為會發生變化，也明白了為什么修改 targetSdkVersion 需要做完整的測試了。

寫完這篇文章，再回頭去看一下原文的 targetSdkVersion 那一段，發現作者是說的多么“滴水不漏”。