Android 13 适配指南
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Android 13 适配指南相关的知识,希望对你有一定的参考价值。
参考技术A2022 的Google I/O 发布了 android 13 beta 2 和 Android 13 Beta 1 国内厂商的设备支持列表,虽然按照惯例, Android 13 应该是年末才发布正式版,但是相信有的开发者已经收到了平台的 Android13 的适配要求,所以本篇也是结合 Oppo 的 Android 13 应用兼容性适配指导 和官方提供的一些文档内容做一个整理测试。
目前 Android 13 主要的兼容问题还是在于隐私权限上,所以本次的适配指南相关内容也是着重在这一部分, 这里涉及面比较广的应该就是相册和通知权限 。
这个动图大家可能看到过, 这是 Android 13 上提供的系统图片选择器,通过 Intent(MediaStore.ACTION_PICK_IMAGES); 就可以打开,支持视频、音频、图片分类,支持多选和单选 ,另外官方也表示过,这个特性不仅仅会在 Android 13 中出现,谷歌还会将其放置到 Play 商店中,向 Android 11 和 Android 12 设备推送。
我们通过调整 TargetSDK 设置为 PreView ,然后运行到 Tiramisu 的模拟器上进行测试,主要测试 TargetSDK 在低于 "Tiramisu" 和等于 "Tiramisu" 时的不同情况。
如下图所示:
总结: 所以如果是 TargetSDK 在 Android 13 以下,不需要处理,如果在 Android 13 以及以上 ,需要增加申请权限 。
在 Android R 上设置里开始支持在设置里对应用的通知权限进行管理,但是应用自身是无法修改应用级别的通知权限,所以 App 无法知道自身有没有发送通知的权限
所以在 Android 13 里增加了通知的运行时权限 ,其中 Android 13 (33) 的通知会根据正在运行的应用程序的目标 API 级别进行不同的处理, 不过不管应用程序的目标API级别如何,Android 13 都会提示用户授予应用程序发送通知的权限 。
例如下图,是 targetSdk 30 运行在 Android 13 模拟器上,依然会弹出让用户是否允许推送 。
当然,系统也会根据应用程序的目标 API 级别处理通知访问:
如果是 现有应用更新 ,程序的目标 API 级别为:
最后测试和总结一下:
由于 Android 之前可以通过跟踪附近的 Wi-Fi AP 和蓝牙设备来推断设备的位置,所以这次谷歌决定禁止应用程序 访问蓝牙 结果,除非这类应用需要声明 ACCESS_FINE_LOCATION 权限。
在 Android 13 中,Google 将 Wi-Fi 扫描与位置相关内容分离, Android 13 为管理设备与周围 Wi-Fi 热点连接的应用添加 NEARBY_WIFI_DEVICES 运行时权限 (属于 NEARBY_DEVICES 权限组),从而在不需要 ACCESS_FINE_LOCATION 权限的情况下,也可以让应用访问附近的 Wi-Fi 设备。
此前,对于仅需要连接 Wi-Fi 设备,但实际上并不需要了解设备位置的应用来说,以 Android 13 (33)为目标平台的应用现在可以通过 “ neverForLocation ” 属性来完善申请 NEARBY_WIFI_DEVICES 权限。
这项新权限会影响几个不同的 Wi-Fi 用例,包括以下用例:
所以开发需要区分不同api对应的权限;
由于 NEARBY_WIFI_DEVICES 权限仅适用于 Android 13 或更高版本, 如果是 Android12L(32) 以及以下的 App 应保留对 ACCESS_FINE_LOCATION 的所有声明:
以 Android 13(33) 为目标平台时,如果应用不会通过 Wi-Fi API 推导物理位置,请在清单文件中将 usesPermissionFlags 属性设为 neverForLocation。
所以总结: 以 Android 13(33) 为目标平台的应用程序,访问附近的 WI-FI 设备。除特例API需要申请ACCESS_FINE_LOCATION外,其他需要申请 android.permission.NEARBY_WIFI_DEVICES 运行时权限 ;
Android 13 中引入了 “在使用时” 访问身体传感器(例如心率、体温和血氧饱和度)的概念,此访问模式与 Android 10(API 级别 29)系统为位置信息 引入的模式非常相似。
如果你的 App 以 Android 13(33) 为目标平台,并且在后台运行时需要访问身体传感器信息,那么除了现有的 BODY_SENSORS 权限外,还必须声明新的 BODY_SENSORS_BACKGROUND 权限 。
当 App 以 Android 13(33) 或更高版本为 Target 的其他应用的导出组件发送 intent 时,仅当该 intent 与接收应用中的 <intent-filter> 元素匹配时,系统才会传送该 intent,换言之系统会屏蔽所有不匹配的 intent,但以下情况除外:
为了帮助提高运行时接收器的安全性,Android 13 允许你指定 App 中的特定广播接收器是否应被导出以及是否对设备上的其他应用可见,此变更是 Android 12 更安全的组件 的延续;
以 Android 13(33) 或更高版本为目标平台的应用,必须为每个广播接收器指定 RECEIVER_EXPORTED 或 RECEIVER_NOT_EXPORTED ,否则当 App 尝试注册广播接收器时,系统会抛出 SecurityException
在 Android 13中,谷歌添加了一个新的API,允许开发者降级权限。
应用程序可以触发撤销授予调用 API 的包的一个或多个运行时权限,不需要访问特定运行时权限控制 API 的应用程序可以自行撤销这些权限,这样用户就可以确保这些应用程序不会在不知情的情况下使用这些API。
如需撤消特定运行时权限,请将该权限的名称传入 revokeOwnPermissionOnKill() 方法,如需同时撤消一组运行时权限,请将这组权限的名称传入 revokeOwnPermissionsOnKill() 。
系统只有在安全的情况下才会触发撤消操作,也就是当有应用组件仍在前台运行,或者有另一个应用正在访问你应用的组件(如 content provider)时不会发生撤消。
Android 之前一直提供了一个剪贴板服务,所有 App 都可以使用它来放置和检索文本。
尽管从技术上讲,任何应用都可以清除全局剪贴板中的主内容(只要它们是前台应用或 Android 10+ 上的默认输入法),但 Android 本身不会自动清除剪贴板。
这意味着任何留在全局剪贴板中的剪贴板内容,都可以在以后被应用程序读取,尽管 Android 的剪贴板访问有 toast 消息可能会提醒用户。
Android 13 增加了剪贴板自动清除功能,此功能在默认情况下处于禁用状态,在经过设定的时间后,将自动从全局剪贴板中清除主剪辑, 默认情况下经过3600000毫秒(60分钟)后,剪贴板将被清除。
每次执行复制/读取(写入剪贴板 setPrimaryClip ,读 getPrimaryClip )时,会重置一个消息 timeout(60min),之后会自动清除剪贴板内存中的内容,即60min内,如果一直没有写入剪贴板的操作,剪贴板的内容会被自动清除。
Android 13 的新前台服务( Foreground Services:FGS)任务管理器显示当前运行前台服务的应用程序列表,此列表称为活动应用程序,可以通过下拉通知抽屉并点击启示来访问,这时候每个应用程序旁边都会有一个“停止”按钮。
利用 JobScheduler,应用可使用 JobInfo.Builder.setPrefetch() 将特定作业标记为“预提取”,这意味着理想情况下这些作业应该在应用下一次启动前提前一点运行,以提升用户体验。
过去,JobScheduler 仅使用该信号让预提取作业有机会使用免费或多余的数据,在 Android 13 中系统现在会尝试确定应用下次启动的时间,并根据该估算值运行预提取作业,应用应尝试使用“预提取”来完成他们想要在下次应用启动前完成的任何工作。
Android 13 中引入了 电池资源利用率 功能,以便为系统提供多种方法来更好地管理设备电池续航时间:
Android 适配指南
AndroidVersionAdapter: 安卓版本适配全套指南
Android 版本适配全套指南
-
当我在做 Android 版本适配工作的时候很痛苦,那个时候我在想有没有一个文档,将所有的关于 Android 版本适配资料全部收集起来,这样就不需要在网上东找西找了,这样就能把时间和精力投入适配工作中,每当一个新的 Android 版本发布的时候,这个想法越加强烈,终于在 Android 11 刚发布的时候筹划了这件事情,最终赶在 Android 12 刚发布的时候完成了,整个过程耗时非常漫长,因为我正在不断收集优质的资料,同时我也在不断思考,什么样的适配文档才是大家所需要的,我将适配文档简单划分成了以下几部分:
-
官方文档
-
新特性
-
行为变更
-
-
相关资源
-
适配文章链接
-
适配框架链接
-
-
-
为什么要把这个做成开源项目?因为我会不断更新,同时欢迎大家如果有好的文章也可以通过 issue 推荐给我,我审核通过之后会放上去,做好一个开源项目需要大家的添砖加瓦,开源是一个互帮互助的过程,没有大家的支持我很难做好它。
适配流程
-
这里以适配
Android 12
为例子,第一步将主模块中的build.gradle
文件中修改targetSdkVersion
和compileSdkVersion
这两个的值
android compileSdkVersion 31 defaultConfig targetSdkVersion 31
-
接下来在代码中做一些版本的判断,并且做好新版本的适配和旧版本的兼容
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.S) ...... else ......
-
到这里,大家可能有一个疑问,targetSdkVersion 和 compileSdkVersion 有啥区别?
-
targetSdkVersion:目标适配版本,告知系统 App 适配的情况,如果应用的 targetSdkVersion 比系统版本要低,那么在一些新特性上新系统会做向下兼容性处理,如果我们想要适配某个 Android 版本,必须要将 targetSdkVersion 调整到这个版本等级之上,否则在某些机型上面可能会出现一些适配异常的情况。如果我们只是简单调高了 targetSdkVersion 等级而没有适配新版本的特性,那么应用在新系统上可能会出现功能异常的情况,一般情况表现为应用崩溃或者获取不到数据。
-
compileSdkVersion:编译源码版本,我们可以通过修改这个版本等级来改变我们在代码中所看到的 Android SDK 源码的版本,同时也决定了编译器在进行代码检查时所用的版本。
-
-
最后附上一张 Android 版本信息对应表
Android 版本 | API 等级 | 版本代号 | 发布时间 |
---|---|---|---|
Android 12L | 32 | S_V2 | 预计 2022 年 3 月 |
Android 12 | 31 | S | 2021 年 10 月 4 日 |
Android 11 | 30 | R | 2020 年 9 月 9 日 |
Android 10 | 29 | Q | 2019 年 9 月 3 日 |
Android 9.0 | 28 | P | 2018 年 8 月 7 日 |
Android 8.1 | 27 | O_MR1 | 2017 年 12 月 5 日 |
Android 8.0 | 26 | O | 2017 年 8 月 22 日 |
Android 7.1 | 25 | N_MR1 | 2016 年 12 月 5 日 |
Android 7.0 | 24 | N | 2016 年 8 月 22 日 |
Android 6.0 | 23 | M | 2015 年 9 月 29 日 |
Android 5.1 | 22 | LOLLIPOP_MR1 | 2015 年 3 月 10 日 |
Android 5.0 | 21 | LOLLIPOP | 2014 年 10 月 15 日 |
Android 4.4 | 19 | KITKAT | 2013 年 10 月 31 日 |
文档目录
Android 12.0 / 12L
新特性
行为变更
相关资源
Android 11.0
概览
隐私权变更 | 受影响的应用 | 缓解策略 |
---|---|---|
强制执行分区存储机制 以 Android 11 或更高版本为目标平台的应用始终会受分区存储行为的影响 | 以 Android 11 或更高版本为目标平台的应用,以及以 Android 10 为目标平台且未将 requestLegacyExternalStorage 设为 true 以停用分区存储的应用 | 更新您的应用以使用分区存储 详细了解分区存储变更 |
单次授权 使用单次授权功能,用户可以授予对位置信息、麦克风和摄像头的临时访问权限 | 在 Android 11 或更高版本上运行且请求位置信息、麦克风或摄像头权限的应用 | 在尝试访问受某项权限保护的数据之前,检查您的应用是否具有该权限 遵循请求权限方面的最佳做法 |
自动重置权限 如果用户在 Android 11 或更高版本上几个月未与应用互动,系统会自动重置应用的敏感权限 | 以 Android 11 或更高版本为目标平台且在后台执行大部分工作的应用 | 要求用户阻止系统重置应用的权限 详细了解自动重置权限 |
后台位置信息访问权限 Android 11 更改了用户向应用授予后台位置信息权限的方式 | 以 Android 11 或更高版本为目标平台且需要在后台访问位置信息的应用 | 通过对权限请求方法的多次单独调用,逐步请求在前台(粗略或精确)和后台访问位置信息的权限。必要时,说明用户授予该权限所能得到的益处 详细了解 Android 11 中的在后台访问位置信息的权限 |
软件包可见性 Android 11 更改了应用查询同一设备上的其他已安装应用及与之互动的方式 | 以 Android 11 或更高版本为目标平台且与设备上的其他已安装应用交互的应用 | 将 <queries> 元素添加到应用的清单 详细了解软件包可见性 |
前台服务 Android 11 更改了前台服务访问位置信息、摄像头和麦克风相关数据的方式 | 在 Android 11 或更高版本上运行且在前台服务中访问位置信息、摄像头或麦克风的应用 | 分别针对需要访问摄像头和麦克风的前台服务,声明 camera 和 microphone 前台服务类型。但请注意,应用在后台运行时启动的前台服务通常无法访问位置信息、摄像头或麦克风。 详细了解前台服务的变更 |
新特性
行为更变
相关资源
Android 10.0
概览
隐私权变更 | 受影响的应用 | 缓解策略 |
---|---|---|
分区存储 针对外部存储的过滤视图,可提供对特定于应用的文件和媒体集合的访问权限 | 访问和共享外部存储中的文件的应用 | 使用特定于应用的目录和媒体集合目录 了解详情 |
增强了用户对位置权限的控制力 仅限前台权限,可让用户更好地控制应用对设备位置信息的访问权限 | 在后台时请求访问用户位置信息的应用 | 确保在没有后台位置信息更新的情况下优雅降级 使用 Android 10 中引入的权限在后台获取位置信息 了解详情 |
系统执行后台 Activity 针对从后台启动 Activity 实施了限制 | 不需要用户互动就启动 Activity 的应用 | 使用通知触发的 Activity 了解详情 |
不可重置的硬件标识符 针对访问设备序列号和 IMEI 实施了限制 | 访问设备序列号或 IMEI 的应用 | 使用用户可以重置的标识符 了解详情 |
无线扫描权限 访问某些 WLAN、WLAN 感知和蓝牙扫描方法需要获得精确位置权限 | 使用 WLAN API 和蓝牙 API 的应用 | 针对相关使用场景请求 ACCESS_FINE_LOCATION 权限 了解详情 |
新特性
行为更变
相关资源
Android 9.0
新特性
行为更变
-
-
以上是关于Android 13 适配指南的主要内容,如果未能解决你的问题,请参考以下文章
个推解读Android13,发布《Android13适配指南》
个推解读Android13新特性,发布《Android13适配指南》