參考：
Android targetSdkVersion 原理
如何選擇 compileSdkVersion, minSdkVersion 和 targetSdkVersion
Google 官方文章:Picking your compileSdkVersion, minSdkVersion, and targetSdkVersion
Android Develop
Google 官方發(fā)布文章解析 compileSdkVersion纵诞、minSdkVersion 以及 targetSdkVersion 的含義，以及合理設(shè)置各個值的意義培遵，原文 Picking your compileSdkVersion, minSdkVersion, and targetSdkVersion
compileSdkVersion
compileSdkVersion 告訴 Gradle 用哪個 Android SDK 版本編譯你的應(yīng)用浙芙。它純粹只是在編譯的時候使用。當你修改了 compileSdkVersion 的時候籽腕，可能會出現(xiàn)新的編譯警告嗡呼、編譯錯誤等（你真的應(yīng)該修復這些警告，他們的出現(xiàn)一定是有原因的）皇耗。需要強調(diào)的是修改 compileSdkVersion 不會改變運行時的行為南窗，compileSdkVersion 并不會打包進APK里只是在編譯時使用
因此我們強烈推薦總是使用最新的 SDK 進行編譯。在自己的代碼上使用最新SDK的編譯檢查（lint郎楼？）可以獲得很多好處万伤，可以避免使用最新棄用的 API ，并且為使用新的 API 做好準備呜袁。
注意敌买，如果使用 Support Library ，那么使用最新發(fā)布的 Support Library 就需要使用最新的 SDK 編譯阶界。通常虹钮，新版的 Support Library 隨著新的系統(tǒng)版本而發(fā)布，它為系統(tǒng)新增加的 API 和新特性提供兼容性支持荐操。例如芜抒，要使用 23.1.1 版本的 Support Library 珍策，compileSdkVersion 就必需至少是 23 （大版本號要一致Ｍ衅簟）。
minSdkVersion
minSdkVersion 是應(yīng)用可以運行的最低版本要求攘宙。minSdkVersion 是 Google Play 商店用來判斷用戶設(shè)備是否可以安裝某個應(yīng)用的標志之一屯耸。
在開發(fā)時 minSdkVersion 也起到一個重要角色：lint 默認會在項目中運行，它在你使用了高于 minSdkVersion 的 API 時會警告你蹭劈，幫你避免調(diào)用不存在的 API 的運行時問題疗绣。如果只在較高版本的系統(tǒng)上才使用某些 API，通常使用運行時檢查系統(tǒng)版本的方式解決铺韧。
請記住多矮，你所使用的庫可能有他們自己的 minSdkVersion 。你的應(yīng)用設(shè)置的 minSdkVersion 必需大于等于這些庫的 minSdkVersion 。例如有三個庫塔逃，它們的 minSdkVersion 分別是 4, 7 和 9 讯壶，那么你的 minSdkVersion 必需至少是 9 才能使用它們。在少數(shù)情況下湾盗，你仍然想用一個比你應(yīng)用的 minSdkVersion 還高的庫（處理所有的邊緣情況伏蚊，確保它只在較新的平臺上使用），你可以使用 tools:overrideLibrary 標記格粪，但請做徹底的測試躏吊！
targetSdkVersion
compileSdkVersion 和 minSdkVersion 都非常好理解，前者表示編譯的 SDK 版本帐萎，后者表示應(yīng)用兼容的最低 SDK 版本比伏。但是對于 targetSdkVersion 其實很難一句話解析清楚，原文：The most interesting of the three, however, is targetSdkVersion. 疆导。以前我也有一些迷糊凳怨，看到有些人和我有同樣的困惑，本文試圖徹底解決這個問題是鬼。
原文：targetSdkVersion is the main way Android provides forward compatibility
targetSdkVersion 是 Android 系統(tǒng)提供前向兼容的主要手段肤舞。這是什么意思呢？隨著 Android 系統(tǒng)的升級均蜜，某個 API 或者模塊的行為可能會發(fā)生改變李剖，但是為了保證APK 的行為還是和以前一致。只要 APK 的 targetSdkVersion 不變囤耳，即使這個 APK 安裝在新 Android 系統(tǒng)上篙顺，其行為還是保持老的系統(tǒng)上的行為，這樣就保證了系統(tǒng)對老應(yīng)用的前向兼容性充择。
這里還是用原文的例子德玫，在 Android 4.4 (API 19）以后，AlarmManager 的 set() 和setRepeat() 這兩個 API 的行為發(fā)生了變化椎麦。在 Android 4.4 以前宰僧，這兩個 API 設(shè)置的都是精確的時間，系統(tǒng)能保證在 API 設(shè)置的時間點上喚醒 Alarm观挎。因為省電原因 Android 4.4 系統(tǒng)實現(xiàn)了 AlarmManager 的對齊喚醒琴儿，這兩個 API 設(shè)置喚醒的時間，系統(tǒng)都對待成不精確的時間嘁捷，系統(tǒng)只能保證在你設(shè)置的時間點之后某個時間喚醒造成。
這時，雖然 API 沒有任何變化雄嚣，但是實際上 API 的行為卻發(fā)生了變化晒屎，如果 APK 中使用了此 API，并且在應(yīng)用中的行為非常依賴 AlarmManager 在精確的時間喚醒，例如鬧鐘應(yīng)用鼓鲁。如果 Android 系統(tǒng)不能保證兼容履肃，老的 APK 安裝在新系統(tǒng)手機上，就會出現(xiàn)問題坐桩。
Android 系統(tǒng)是怎么保證這種兼容性的呢尺棋？這時候 targetSdkVersion 就起作用了。APK 在調(diào)用系統(tǒng) AlarmManager 的 set() 或者 setRepeat() 的時候绵跷，系統(tǒng)首先會查一下調(diào)用的 APK 的 targetSdkVersion 信息膘螟，如果小于 19，就還是按照老的行為碾局，即精確設(shè)置喚醒時間荆残，否者執(zhí)行新的行為。
我們來看一下 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);
}
看到這里净当，首選獲取應(yīng)用的 targetSdkVersion内斯，判斷是否是小于 Build.VERSION_CODES.KITKAT (即 API Level 19)，來設(shè)置 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() 傳入不同的參數(shù)忽冻，從而影響到了 set() 的執(zhí)行行為真朗。具體的實現(xiàn)在 AlarmManagerService.java，這里就不往下深究了僧诚。
看到這里遮婶，發(fā)現(xiàn)其實 Android 的 targetSdkVersion 并沒有什么特別的，系統(tǒng)使用它也非常直接湖笨，甚至很“粗糙”旗扑。僅僅是用過下面的 API 來獲取 targetSdkVersion，來判斷是否執(zhí)行哪種行為：getApplicationInfo().targetSdkVersion;
所以慈省，我們可以猜測到臀防，如果 Android 系統(tǒng)升級，發(fā)生這種兼容行為的變化時辫呻，一般都會保存新舊兩種邏輯清钥，并通過 if-else 方法來判斷執(zhí)行哪種邏輯。果然放闺，在源碼中搜索，我們會發(fā)現(xiàn)不少類似 getApplicationInfo().targetSdkVersion < Buid.XXXX 這樣的代碼缕坎，相對于浩瀚的 Android 源碼量來說怖侦，這些還是相對較少了。其實原則上，這種會導致兼容性問題的修改還是越少越好匾寝，所以每次發(fā)布新的 Android 版本的時候搬葬，Android 開發(fā)者網(wǎng)站都會列出做了哪些改變，在這里艳悔，開發(fā)者需要特別注意急凰。
最后，我們也可以理解原文中說的那句話的含義猜年，明白了為什么修改了 APK 的 targetSdkVersion 行為會發(fā)生變化抡锈，也明白了為什么修改 targetSdkVersion 需要做完整的測試了。
Gradle和SDK版本
所以設(shè)置正確的 compileSdkVersion, minSdkVersion 和 targetSdkVersion 很重要乔外。
所以編譯時用到的 compileSdkVersion 是和其他構(gòu)建設(shè)置放在一起的（如上圖的： buildToolsVersion）作為Android 的設(shè)置床三。其他兩個稍有不同，他們在構(gòu)建變體(build variant)的那里聲明杨幼。defaultConfig 是所有構(gòu)建變體的基礎(chǔ)撇簿，也是設(shè)置這些默認值的地方。
你可以想象在一個更復雜的系統(tǒng)中差购，應(yīng)用的某些版本可能會有不同的 minSdkVersion 四瘫。
minSdkVersion 和 targetSdkVersion 會被打包進最終的 APK 文件中，如果你查看生成的 AndroidManifest.xml 文件欲逃，你會看到類似下面這樣的標簽：
<uses-sdk android:targetSdkVersion="23" android:minSdkVersion="7" />
如果你在 manifest 文件中手工設(shè)置莲组，你會發(fā)現(xiàn) Gradle 在構(gòu)建時會忽略它們（盡管其它構(gòu)建系統(tǒng)如eclipse、ant可能會依賴它們）暖夭。
綜合來看如果你按照上面示例那樣配置锹杈，你會發(fā)現(xiàn)這三個值的關(guān)系是：
minSdkVersion <= targetSdkVersion <= compileSdkVersion
理想上，在穩(wěn)定狀態(tài)下三者的關(guān)系應(yīng)該更像這樣：
minSdkVersion (lowest possible) <= targetSdkVersion == compileSdkVersion (latest SDK)
用較低的 minSdkVersion 來覆蓋最大的人群迈着，用最新的 SDK 設(shè)置 target 和 compile 來獲得最好的外觀和行為竭望。
附:部分英文原文
compileSdkVersion
compileSdkVersion is your way to tell Gradle what version of the Android SDK to compile your app with. Using the new Android SDK is a requirement to use any of the new APIs added in that level.
It should be emphasized that changing your compileSdkVersion does not change runtime behavior. While new compiler warnings/errors may be present when changing your compileSdkVersion, your compileSdkVersion is not included in your APK: it is purely used at compile time. (You should really fix those warnings though?—?they were added for a reason!)
Therefore it is strongly recommended that you always compile with the latest SDK. You’ll get all the benefits of new compilation checks on existing code, avoid newly deprecated APIs, and be ready to use new APIs.
Note that if you use the Support Library, compiling with the latest SDK is a requirement for using the latest Support Library releases. For example, to use the 23.1.1 Support Library, you must have a compileSdkVersion of at least 23 (those first numbers need to match!). In general, a new version of the Support Library is released alongside a new platform version, providing compatibility shims to newly added APIs as well as new features.
minSdkVersion
If compileSdkVersion sets the newest APIs available to you, minSdkVersion is the lower bound for your app. The minSdkVersion is one of the signals the Google Play Store uses to determine which of a user’s devices an app can be installed on.
It also plays an important role during development: by default lint runs against your project, warning you when you use any APIs above your minSdkVersion, helping you avoid the runtime issue of attempting to call an API that doesn’t exist. Checking the system version at runtime is a common technique when using APIs only on newer platform versions.
Keep in mind that libraries you use, such as any of the Support Libraries or Google Play services, may have their own minSdkVersion?—?your app’s minSdkVersion must be at least as high as your dependencies’ minSdkVersion?—?if you have libraries that require 4, 7, and 9, your minSdkVersion must be at least 9. In rare cases where you want to continue to use a library with a higher minSdkVersion than your app (and deal with all edge cases/ensure the library is only used on newer platform versions), you can use the tools:overrideLibrary marker, but make sure to test thoroughly!
When deciding on a minSdkVersion, you should consider the stats on theDashboards, which give you a global look on all devices that visited the Google Play Store in the prior 7 days?—?that’s your potential audience when putting an app on Google Play. It is ultimately a business decision on whether supporting an additional 3% of devices is worth the development and testing time required to ensure the best experience.
Of course, if a new API is key to your entire app, then that makes the minSdkVersion discussion quite a bit easier. Just remember that even 0.7% of 1.4 billion devices is a lot of devices.
targetSdkVersion
The most interesting of the three, however, is targetSdkVersion. targetSdkVersion is the main way Android provides forward compatibility by not applying behavior changes unless the targetSdkVersion is updated. This allows you to use new APIs (as you did update your compileSdkVersion right?) prior to working through the behavior changes.
Much of the behavior changes that targetSdkVersion implies are documented directly in the VERSION_CODES, but all of the gory details are also listed on the each releases’ platform highlights, nicely linked in the API Levels table.
For example, the Android 6.0 changes talk through how targeting API 23 transitions your app to the runtime permissions model and the Android 4.4 behavior changes detail how targeting API 19 or higher changes how alarms set with set() and setRepeating() work.
With some of the behavior changes being very visible to users (the deprecation of the menu button, runtime permissions, etc), updating to target the latest SDK should be a high priority for every app. That doesn’t mean you have to use every new feature introduced nor should you blindly update your targetSdkVersion without testing?—?please, please test before updating your targetSdkVersion! Your users will thank you.
