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很重要。正如GradleAndroid 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编译原理和运行原理了,任重而道远,这只是一个结果论。

大家可以点个关注,告诉我大家想要深入探究哪些问题,希望看到哪方面的文章,我可以免费给你写专题文章。。哈哈。。。
希望大家多多支持。。你的一个关注,是我坚持的最大动力。。

当您的Android应用程序的目标SDK版本设置为30(API level 30),即Android 11,您可能会遇到一些新的权限管理和隐私规则的变化。以下是针对Android 11的一些常见问题及解决方案: 1. **运行时权限**: API 30引入了运行时权限请求,您需要在运行时动态请求用户的敏感权限,如`READ_EXTERNAL_STORAGE`和`WRITE_EXTERNAL_STORAGE`。使用`ContextCompat.checkSelfPermission()`检查权限,并通过`Activity#requestPermissions()`发起请求。 ```java if (ContextCompat.checkSelfPermission(this, Manifest.permission.READ_EXTERNAL_STORAGE) != PackageManager.PERMISSION_GRANTED) { ActivityCompat.requestPermissions(this, new String[]{Manifest.permission.READ_EXTERNAL_STORAGE}, REQUEST_READ_EXTERNAL_STORAGE); } ``` 2. **Notification行为**: Android 11更改了通知的行为,需要提供通知信息以及明确的理由。创建`NotificationManagerCompat`实例并设置`NotificationChannel`。 3. **Media Storage Access**: 对媒体文件存储的访问需要用户明确许可。您可以使用`MediaStore`的`ACTION_OPEN_DOCUMENT_TREE`动作引导用户选择文件夹。 4. **工作模式(Work Manager)**: 如果应用需要后台服务,需要使用WorkManager而非Service,因为后台服务的生命周期更受限制。 5. **焦点模式**: 应用在前台运行时应遵守焦点模式,确保不会滥用设备资源。考虑使用`AppOpsManager`管理操作权限。 如果遇到特定问题,可以查阅官方文档[Android Developer Guide](https://developer.android.com/training/permissions/requesting) 或搜索Google开发者社区获取详细的解决方案。同时,确保测试应用在模拟器和真机上,以便准确了解兼容性问题。
评论 5
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值