Android targetSdkVersion

先抛出一个问题：
我们的应用开发的时候android最新版本是6.0，当一年过去之后，7.0发布了，那么我们的应用在7.0手机上是否还能运行？会奔溃吗？

根据我们的实际经验，觉得应该不会奔溃，可能有些功能会有问题，但是具体是那一块呢？又说不太好，这就涉及到了Android的向前兼容的问题了。

我们在创建App的时候经常会设置这几个参数

android {
  compileSdkVersion 23
  buildToolsVersion “23.0.1”
 
  defaultConfig {
    applicationId “com.example.checkyourtargetsdk"
    minSdkVersion 16
    targetSdkVersion 23
    versionCode 1
    versionName “1.0”
  }
}
其中著名的就是compileSdkVersion，minSdkVersion，targetSdkVersion。平时这些参数都是自动设置的，我们只需设置minSdkVersion，最低SDK版本，然后compileSdkVersion和targetSdkVersion可能是一致的。这就是我们平时使用AS的时候不注意的问题，平时操作习惯了，但是真的不知道这几个参数是什么意思。

minSdkVersion
最好理解的就是minSdkVersion了，就是我们的app能够运行的最小版本，如果选择16，那么就是Android 4.1 以及以上的设备才能运行我们app，如果小于这个版本，那么抱歉运行不了，我们不支持。这是应用程序支持api的下限。这也是应用商店判断这个应用是否能运行在设备上的一个依据之一。

在开发中也会根据这个下限去判断，是否可以用某个api方法，如果是下限之下的那么就会有警告，避免调用一些在新的版本已经改变或者过时的方法。

当我们引用了第三方的库，如果某几个库的minSdkVersion分别是API5，API10，API16的方法，那么我们的minSdkVersion最少就是16。

对于minSdkVersion的选择，我们应该看各个api的占比，不过因为基数太大了（十几亿）所以就算是0.7%也是个天文数字，所以我们需要根据自己应用的受众，以及是否需要适配低版本的需要，一般说来我们适配4.1以上，即minSdkVersion=16，不过还要根据自己的实际情况，去选择相应的版本号。

compileSdkVersion
compileSdkVersion是我们告诉Gradle，我们是用哪一版本的Android Sdk去编译程序的，可以使用这个版本的API，比如我们使用的是7.0的版本，compileSdkVersion=24，那么我们对于拍照裁剪图片等功能的操作，就可以使用FileProvider了。

我们需要注意的是：我们改变compileSdkVersion的版本号，本质上改变不了我们程序的运行，虽然可能会报错误❌或者警告⚠️，但compileSdkVersion 只会在编译期间起作用，因为环境是compileSdkVersion这个版本的SDK，所以你可以用一些这个版本的API，但是只是IDE给你的便利性帮助而已，帮助你检测代码，避免使用一些弃用的API。就算你用个低版本的compileSdkVersion，你依然可以那么写，但是可能会报错，报警告，但是你强制打包，其实也是没有问题的。IDE只是个工具，他的环境也只是工具的环境，不代表你应用运行时的表现。

所以希望大家用最新的sdk版本作为开发环境，compileSdkVersion设置成最新的，这样我们可以使用到最新SDK的API方法和机制。

如果我们使用了比如V4，V7包，有没有发现必须和compileSdkVersion的版本相匹配，比如我们compileSdkVersion = 26，那么V4，v7的版本也要相应的是26.xx.xx，首位的26必须一致，后两位没有要求，就是说明编译所依赖的SDK和依赖包必须是统一版本，不然两个不兼容，编译会通不过。同时也是为了使用该版本的新特性。

targetSdkVersion
targetSdkVersion是这哥三里面最难以理解的一个了，不过也是最有趣的一个。

targetSdkVersion的含义对于我们来说就有点陌生而熟悉了。

什么是目标设备SDK版本？
是和minSdkVersion相对应的上限吗？
如果我运行在比targetSdkVersion高的设备上，会出现什么？
如果是比targetSdkVersion低的设备呢？
满满的疑问

首先targetSdkVersion是android向前兼容的主要方式，怎么说呢？官方是这样说的：

除非更新targetSdkVersion，否则不改变应用的行为。 这允许您在处理行为更改之前使用新的API（如您更新过的compileSdkVersion）
简单的说就是你的应用已经针对这个版本的手机，做了充分的兼容性处理和测试性处理，比如 if(Build.VERSION.SDK_INT >= 23) { ... } ，这样针对不同的SDK版本做不同的处理，这就说明我们不能随便的改变targetSdkVersion得值，我们必须做好充足的兼容性处理和测试处理才行。

在 Android 4.4 (API 19）以后，AlarmManager 的 set() 和 setRepeat() 这两个 API 的行为发生了变化。在 Android 4.4 以前，这两个 API 设置的都是精确的时间，系统能保证在 API 设置的时间点上唤醒 Alarm。因为省电原因 Android 4.4 系统实现了 AlarmManager 的对齐唤醒，这两个 API 设置唤醒的时间，系统都对待成不精确的时间，系统只能保证在你设置的时间点之后某个时间唤醒。虽然api的名字没有改变，但是功能结果已经发生改变，我们设置targetSdkVersion为16，Android4.4之前,那么我们在Android4.4之后运行会出现什么呢？难道就不能用了吗？不准确了吗？
当然不是，系统通过targetSdkVersion来保证Android的向前兼容性，在Android4.4之后的设备上，系统会判断你的targetSdkVersion是否小于19，如果小于的话，那就按照19之前的api方法，如果大于等于19，那么就按照之后的api方法来走，保证了程序运行的一致性。也就是向前兼容性。

但是还有一个问题：

Android 6.0新增加了动态权限申请，我们的targetSdkVersion是5.0，如果我们运行在Android 6.0的设备上怎么办？
因为我们这个可以向前兼容，向后不行啊，如果你的代码里处理了Android 6.0的动态权限处理，那么可以的，如果没呢？你想啥呢大哥？更新应用处理呗~~

targetSdkVersion 的大部分更新变化都会记录在VERSION_CODES，所有的细节也会在每个版本的平台亮点写明。

targetSdkVersion保证的是api的一致性。
所以一般minSdkVersion <targetSdkVersion<= compileSdkVersion
不随意更改targetSdkVersion，更改targetSdkVersion必须做好兼容。

Gradle和SDK版本
所以设置正确的compileSdkVersion，minSdkVersion和targetSdkVersion很重要。正如Gradle和Android Studio的世界中的那样，这些值通过包含在我们模块的build.gradle文件中（也可通过Android Studio中的Project Structure选项获得）集成到工具系统中:

android { 
  compileSdkVersion 23
   buildToolsVersion“23.0.1” 
 
  defaultConfig { 
    applicationId“com.example.checkyourtargetsdk” 
    minSdkVersion 7 
    targetSdkVersion 23
     versionCode 1 
    versionName“1.0” 
  } 
}
compileSdkVersion是一个编译时的事情（TMD这谁知道），是与我们的构建工具版本一起使用的Android设置之一。

minSdkVersion和targetSdkVersion不同于compileSdkVersion，因为它们包含在APK中。查看生成的AndroidManifest.xml

<uses-sdk android：targetSdkVersion =“23”android：minSdkVersion =“16”/>
理清楚这些后，下次更改这些参数的时候，就不会犯一些低级错误了。但是其中的更细节的东西，需要看android编译原理和运行原理了，任重而道远，这只是一个结果论。
--------------------- 
 

本文出自于对以下两篇文章的整理总结 
http://chinagdg.org/2016/01/picking-your-compilesdkversion-minsdkversion-targetsdkversion/ 
http://www.race604.com/android-targetsdkversion/

这里先做个简单的介绍,后面详细的说明 
minSdkVersion:应用可以运行的最低要求 
compileSdkVersion:控制可以使用哪个版本的api 
targetSdkVersion:应用的兼容模式

minSdkVersion
见名之意,app运行所需的最低sdk版本.低于minSdkVersion的手机将无法安装.

在开发时 minSdkVersion 也起到一个重要角色：lint 默认会在项目中运行，它在你使用了高于 minSdkVersion 的 API 时会警告你，帮你避免调用不存在的 API 的运行时问题(比如 minSdkVersion 9但你使用了 sdkVersion 10 才有的API就会警告 )。

如果只在较高版本的系统上才使用某些 API，通常使用运行时检查系统版本的方式解决。 
比如这样

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP){
            //do something
}

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT && Build.VERSION.SDK_INT < Build.VERSION_CODES.LOLLIPOP){
            //do something
}
1
2
3
4
5
6
7

compileSdkVersion
compileSdkVersion 告诉 Gradle 用哪个 Android SDK 版本编译你的应用。使用任何新添加的 API 就需要使用对应版本的 Android SDK。

修改 compileSdkVersion 不会改变运行时的行为。当你修改了 compileSdkVersion 的时候，可能会出现新的编译警告、编译错误，但新的 compileSdkVersion 不会被包含到 APK 中：它纯粹只是在编译的时候使用。

注意，如果使用 Support Library ，那么使用最新发布的 Support Library 就需要使用最新的 SDK 编译。例如，要使用 23.1.1 版本的 Support Library ，compileSdkVersion 就必需至少是 23 。 

targetSdkVersion
三个属性中最难懂的就是这个了targetSdkVersion 是 Android 提供向前兼容的主要依据，在应用的 targetSdkVersion 没有更新之前系统不会应用最新的行为变化。

具体点就是随着 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 这两个 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);
}
1
2
3
4
5
6
7
看到这里，首选获取应用的 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);
}
1
2
3
4
5
6
7
8
9
10
这里看到，直接影响到 set() 方法给 setImpl() 传入不同的参数，从而影响到了 set() 的执行行为。具体的实现在 AlarmManagerService.java，这里就不往下深究了。

看到这里，发现其实 Android 的 targetSdkVersion 并没有什么特别的，系统使用它也非常直接，甚至很“粗糙”。仅仅是用过下面的 API 来获取 targetSdkVersion，来判断是否执行哪种行为：

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

所以当我们修改了 APK 的 targetSdkVersion 后行为会发生变化，也就必须做完整的测试了。 

综合来看三个属性的关系是 
minSdkVersion <= targetSdkVersion <= compileSdkVersion

理想上，在稳定状态下三者的关系应该更像这样： 
minSdkVersion (lowest possible) <= targetSdkVersion == compileSdkVersion (latest SDK) 
用较低的 minSdkVersion 来覆盖最大的人群，用最新的 SDK 设置 target 和 compile 来获得新版本最好的效果。
---------------------