Android中的compileSdkVersion,minSdkVersion,targetSdkVersion和buildToolsVersion

引言

使用Android Studio编写构建一个Android项目时,需要我们配置build.gradle文件,如下:

……
android {
    compileSdkVersion 23
    buildToolsVersion "23.0.3"

    defaultConfig {
        minSdkVersion 16
        targetSdkVersion 22
    }
    ……
}

对于compileSdkVersionminSdkVersiontargetSdkVersionbuildToolsVersion这四个参数的意义,可能很多人和我一样并没有清楚地了解。

以下就来分析一下它们的概念。

compileSdkVersion

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

需要强调的是修改compileSdkVersion不会改变运行时的行为。当你修改了compileSdkVersion的时候,可能会出现新的编译警告、编译错误,但新的compileSdkVersion不会被包含到APK中:它纯粹只是在编译的时候使用。(你真的应该修复这些警告,他们的出现一定是有原因的)

因此我们强烈推荐总是使用最新的SDK进行编译。在现有代码上使用新的编译检查可以获得很多好处,避免新弃用的API,并且为使用新的API做好准备。

注意,如果使用Support Library,那么使用最新发布的Support Library就需要使用最新的SDK编译。例如,要使用23.1.1版本的Support Library,compileSdkVersion就必需至少是23(大版本号要一致)。通常,新版的Support Library随着新的系统版本而发布,它为系统新增加的API和新特性提供兼容性支持。

minSdkVersion

minSdkVersion表示应用可以运行的最低要求。minSdkVersion是Google Play商店用来判断用户设备是否可以安装某个应用的标志之一。如果设备的API低于minSdkVersion,那就安装不上该应用。

在开发时minSdkVersion也起到一个重要角色:lint 默认会在项目中运行,它在你使用了高于minSdkVersion的API时会警告你,帮你避免调用不存在的API的运行时问题。如果只在较高版本的系统上才使用某些API,通常使用运行时检查系统版本的方式解决,例如:

这里写图片描述
Android Studio的提示,很明显,requestPermissions()只能在API大于等于23上的设备上才可以调用

那我们就针对该情况特殊处理:

        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {
            requestPermissions(new String[]{""}, REQUEST_CODE_ASK_CALL_PHONE);
        } else {
            //不需要申请权限直接调用我们需要处理的方法。
        }

当设备的版本号大于Android6.0,就调用requestPermissions(),否则就不做处理

请记住,你所使用的库,如Support Library或 Google Play Services,可能有他们自己的 minSdkVersion。你的应用设置的minSdkVersion必需大于等于这些库的minSdkVersion。例如有三个库,它们的minSdkVersion分别是4, 7和9,那么你的minSdkVersion必需至少是9才能使用它们。在少数情况下,你仍然想用一个比你应用的minSdkVersion还高的库(处理所有的边缘情况,确保它只在较新的平台上使用),你可以使用tools:overrideLibrary标记,但请做彻底的测试。

targetSdkVersion

三个版本号中最有趣的就是targetSdkVersion了。targetSdkVersion是Android提供向前兼容的主要依据,在应用的targetSdkVersion没有更新之前系统不会应用最新的行为变化。这允许你在适应新的行为变化之前就可以使用新的API(因为你已经更新了compileSdkVersion不是吗?)。

targetSdkVersion所暗示的许多行为变化都记录在VERSION_CODES文档中了,但是所有恐怖的细节也都列在每次发布的平台亮点中了,在这个API Level表中可以方便地找到相应的链接。

例如,Android 6.0变化文档中谈了target为API 23时会如何把你的应用转换到运行时权限模型上,Android 4.4行为变化阐述了target为API 19及以上时使用set()和setRepeating()设置alarm会有怎样的行为变化。

由于某些行为的变化对用户是非常明显的(弃用的menu按钮,运行时权限等),所以将target更新为最新的SDK是所有应用都应该优先处理的事情。但这不意味着你一定要使用所有新引入的功能,也不意味着你可以不做任何测试就盲目地更新 targetSdkVersion ,请一定在更新 targetSdkVersion 之前做测试。

一个Android系统,对外提供一套API,如何选择targetSdkVersion取决于应用程序需要实现的功能,如果你的应用程序使用API 7就可以实现的功能,可以不用考虑使用API 24,使用低版本API的其中一个好处,可以让更多的Android系统运行的效果保持一致,即兼容性更好,打个比方:API 7开发的APP可能兼容98%以上的Android手机,而API 24开发的APP可能兼容仅有60%,所谓的不兼容并不是无法正常运行,而是在不同Android系统的手机运行的效果差异比较大,会让用户感觉难以接受;使用低版本API的其中一个不足,显示的效果比较OUT,提供的可用的接口或类比较少,本来一句代码可以完成的功能(封装的类或接口),需要自己花一天琢磨写很多的代码,也就是有高版本API的其中一个原因,提供更多的或封装好的应用程序接口让开发者使用。

系统版本和targetSdkVersion关系

1.系统版本高于targetSdkVersion

假设我们的targetSdkVersion是22(就是5.0)不需要动态申请权限,但是我们的系统是6.0的。现在程序运行到了需要某个需要权限的地方了。此时想想我们的手机该怎么办?系统逻辑是这样的:

        final int targetSdkVersion= getApplicationContext().getApplicationInfo().targetSdkVersion;
        if (targetSdkVersion < Build.VERSION_CODES.M) {
            //这里的M就是level 23也就是6.0的系统
            //这里的判断是如果当前的打包的targetSdkVersion小于23
            //那么这里就不需要动态申请权限直接可以调取开放的权限
        } else {
            //否则系统认为你需要动态申请权限
        }

以上这不代码系统源码,只是说处理逻辑。

注意这里是系统处理,不需要你显式地写这些代码,是系统内部的代码和自动处理。

2.系统版本等于targetSdkVersion

当安装app的时候targetSdkVersion刚好等需系统的level,这个时候Andorid平台会认为这个程序在此版本上已经经过了充分的测试。不必为此程序开启兼容性检查判断的工作了。也就是说,如果targetSdkVersion与目标设备的API版本相同时,运行效率可能会高一些

3.系统版本小于targetSdkVersion

还是举个例子:targetSdkVersion=23的时候,但是系统版本是22,很明显你在代码里面做了动态权限分配,但是系统版本不支持。

之前minSdkVersion中的例子已经做了处理了。

buildToolsVersion

buildToolsVersion表示的是构建工具的版本号,规则是可以用高版本的构建工具来构建使用低版本SDK的工程

其他

minSdkVersion和targetSdkVersion与compileSdkVersion的区别

另一个不同之处是minSdkVersion和targetSdkVersion会被包含进最终的APK文件中,而compileSdkVersion则不会,如果你查看生成的AndroidManifest.xml文件,你会看到类似下面这样的标签:

<uses-sdkandroid:targetSdkVersion="23" android:minSdkVersion="7"/>

如果你在AndroidManifest文件中手工设置,你会发现 Gradle 在构建时会忽略它们(尽管其它构建系统可能会明确依赖它们)。

关于Support Library

不管是引用v4,v7还是v13,总体来说他们就是一个libs,和我们引用在github上的libs一模一样。

因为android版本碎片化太严重了,说一个案例,在刚开始的时候Android系统是没有ViewPager的。是后面的系统才出现的。那么以前的系统想用ViewPager该怎么办呢?好办,和我们项目需要自定义某些特殊的View一样,没有的话我们要么自己写,要么到github上面去找然后引入到我们的项目中。这里就引入Support Library。

v4的意思是什么呢?就是说这个包可以兼容到1.6的系统,所以1.6以下的系统是用不了的。v7包的意思就是可以兼容到2.3的系统。另外v7包是依赖v4包的。可以看出v4包的minSdk肯定是等于1.6了。v7包的minSdk就会是2.3。

v13包主要是在平板上使用,一般在手机端不会用。

参考:
1.android开发如何选择compileSdkVersion, minSdkVersion 和 targetSdkVersion
2.关于Android SDK里的compileSdk、minSdk、targetSdk、buildTools、Tools、Platform-tools
3.compileSdkVersion,minSdkVersion,targetSdkVersion 的区别和比较
4.新手的第一个Android项目该如何选择targetSdkVersion
5.Android targetSdkVersion 原理

猜你喜欢

转载自blog.csdn.net/sted_zxz/article/details/78342527