作者：恋猫de小郭
❝
「是的，你没看错，现在就要带你适配 Android13」。
❞
2022 的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 以及以上 ，需要增加申请权限」。
<uses-permission android:name="android.permission.READ_MEDIA_IMAGES" />
<uses-permission android:name="android.permission.READ_MEDIA_AUDIO" />
<uses-permission android:name="android.permission.READ_MEDIA_VIDEO" />通知
在 Android R 上设置里开始支持在设置里对应用的通知权限进行管理，但是应用自身是无法修改应用级别的通知权限，所以 App 无法知道自身有没有发送通知的权限
「所以在 Android 13 里增加了通知的运行时权限」，其中 Android 13 (33) 的通知会根据正在运行的应用程序的目标 API 级别进行不同的处理，「不过不管应用程序的目标API级别如何，Android 13 都会提示用户授予应用程序发送通知的权限」。
「例如下图，是 targetSdk 30 运行在 Android 13 模拟器上，依然会弹出让用户是否允许推送」。
当然，系统也会根据应用程序的目标 API 级别处理通知访问:
如果是现有应用更新，程序的目标 API 级别为：
最后测试和总结一下：
由于 Android 之前可以通过跟踪附近的 Wi-Fi AP 和蓝牙设备来推断设备的位置，所以这次谷歌决定禁止应用程序访问蓝牙或Wi-Fi扫描结果，除非这类应用需要声明 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 来推导物理位置，那么当你以 Android 13 或更高版本为目标平台并使用 Wi-Fi API 时，就可以请求 NEARBY_WIFI_DEVICES 而不是 ACCESS_FINE_LOCATION。
❞
这项新权限会影响几个不同的 Wi-Fi 用例，包括以下用例：
所以开发需要区分不同api对应的权限；
由于 NEARBY_WIFI_DEVICES 权限仅适用于 Android 13 或更高版本， 如果是 Android12L(32) 以及以下的 App 应保留对 ACCESS_FINE_LOCATION 的所有声明：
<manifest ...>
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"
android:maxSdkVersion="32" />
<application ...>
...
</application>
</manifest>
以 Android 13(33) 为目标平台时，如果应用不会通过 Wi-Fi API 推导物理位置，请在清单文件中将 usesPermissionFlags 属性设为 neverForLocation。
<manifest ...>
<uses-permission android:name="android.permission.NEARBY_WIFI_DEVICES"
android:usesPermissionFlags="neverForLocation" />
<application ...>
...
</application>
</manifest>
所以总结：「以 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 权限」。
Intent 过滤器会屏蔽不匹配的 intent❝
「注意」：这是受到“硬性限制”的权限，除非设备的安装程序针对你的应用将该权限列入了许可名单，否则你的应用将无法获得此权限，如需了解详情，请参阅有关受限权限的指南。
❞
当 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
// This broadcast receiver should be able to receive broadcasts from other apps.
// This option causes the same behavior as setting the broadcast receiver's
// "exported" attribute to true in your app's manifest.
context.registerReceiver(sharedBroadcastReceiver, intentFilter,
RECEIVER_EXPORTED);
// For app safety reasons, this private broadcast receiver should **NOT**
// be able to receive broadcasts from other apps.
context.registerReceiver(privateBroadcastReceiver, intentFilter,
RECEIVER_NOT_EXPORTED);应用自撤销权限
在 Android 13中，谷歌添加了一个新的API，允许开发者降级权限。
应用程序可以触发撤销授予调用 API 的包的一个或多个运行时权限，不需要访问特定运行时权限控制 API 的应用程序可以自行撤销这些权限，这样用户就可以确保这些应用程序不会在不知情的情况下使用这些API。
如需撤消特定运行时权限，请将该权限的名称传入 revokeOwnPermissionOnKill() 方法，如需同时撤消一组运行时权限，请将这组权限的名称传入 revokeOwnPermissionsOnKill()。
❝
撤消是异步发生的，会终止与应用的 UID 相关联的所有进程。
❞
系统只有在安全的情况下才会触发撤消操作，也就是当有应用组件仍在前台运行，或者有另一个应用正在访问你应用的组件（如 content provider）时不会发生撤消。
剪贴板擦除❝
如果你想立即撤消权限，可以调用 exit()。但是进行 exit() 调用可能会导致当前正在访问 App 的其他应用出现崩溃。
❞
Android 之前一直提供了一个剪贴板服务，所有 App 都可以使用它来放置和检索文本。
尽管从技术上讲，任何应用都可以清除全局剪贴板中的主内容（只要它们是前台应用或 Android 10 上的默认输入法），但 Android 本身不会自动清除剪贴板。
这意味着任何留在全局剪贴板中的剪贴板内容，都可以在以后被应用程序读取，尽管 Android 的剪贴板访问有 toast 消息可能会提醒用户。
Android 13 增加了剪贴板自动清除功能，此功能在默认情况下处于禁用状态，在经过设定的时间后，将自动从全局剪贴板中清除主剪辑， 默认情况下经过3600000毫秒（60分钟）后，剪贴板将被清除。
每次执行复制/读取（写入剪贴板 setPrimaryClip，读 getPrimaryClip ）时，会重置一个消息 timeout（60min），之后会自动清除剪贴板内存中的内容，即60min内，如果一直没有写入剪贴板的操作，剪贴板的内容会被自动清除。
前台服务 (FGS) 任务管理器Android 13 的新前台服务（ Foreground Services：FGS）任务管理器显示当前运行前台服务的应用程序列表，此列表称为活动应用程序，可以通过下拉通知抽屉并点击启示来访问，这时候每个应用程序旁边都会有一个“停止”按钮。
❝
注意：当用户点击应用旁边的停止按钮时，系统会停止整个应用，而不仅仅是正在运行的前台服务。
❞
使用 JobScheduler 改进预提取处理❝
注意：如果系统检测到你的应用长时间运行某项前台服务（在 24 小时的时间段内至少运行 20 小时），便会发送通知邀请用户与 FGS 任务管理器进行互动，详见：https://developer.android.google.cn/about/versions/13/changes/fgs-manager#system-prompt-long-running-fgs
❞
利用 JobScheduler，应用可使用 JobInfo.Builder.setPrefetch() 将特定作业标记为“预提取”，这意味着理想情况下这些作业应该在应用下一次启动前提前一点运行，以提升用户体验。
过去，JobScheduler 仅使用该信号让预提取作业有机会使用免费或多余的数据，在 Android 13 中系统现在会尝试确定应用下次启动的时间，并根据该估算值运行预提取作业，应用应尝试使用“预提取”来完成他们想要在下次应用启动前完成的任何工作。
电池资源利用率Android 13 中引入了 电池资源利用率 功能，以便为系统提供多种方法来更好地管理设备电池续航时间：
TargetSDK 33 才会需要处理的变动：
影响所有应用的变动：
Copyright © 2008-2022 秒下下载站
m.down10s.com .All Rights Reserved
