Android 17 平台包含一些行为变更,这些变更可能会影响您的应用。
以下行为变更将影响在 Android 17 上运行的 所有应用,
无论其采用哪种 targetSdkVersion 都不例外。您应该测试您的应用,然后根据需要酌情修改,以便支持这些变更。
此外,请务必查看仅影响以 Android 17 为目标平台的应用的行为变更列表 。
核心功能
Android 17(API 级别 37)包含以下变更,这些变更会修改或扩展 Android 系统的各种核心功能。
应用内存限制
Android 17 引入了基于设备总 RAM 的应用内存限制,旨在为您的应用和 Android 用户打造更稳定、更具确定性的环境。在 Android 17 中,限制设置得较为保守,目的是建立系统基准,在极端内存泄漏和其他异常情况触发系统范围的不稳定性(导致界面卡顿、耗电过快和应用被终止)之前,先针对这些情况。虽然我们预计对绝大多数 应用会话的影响很小,但我们建议遵循以下内存最佳实践, 包括建立内存基准。
您可以通过在 ApplicationExitInfo 中调用
getDescription 来确定应用会话是否受到影响;如果您的应用受到
影响,退出原因将为 REASON_OTHER 并且
说明将包含字符串 "MemoryLimiter:AnonSwap" 以及
其他信息。您还可以使用 基于触发器的分析(使用
TRIGGER_TYPE_ANOMALY)来获取在达到
内存限制时收集的堆转储。
为了帮助您查找内存泄漏,Android Studio Panda 直接在 Android Studio 性能分析器中添加了 LeakCanary 集成,作为 IDE 中特定任务,并与您的源代码完全集成。
安全
Android 17 包含设备和应用安全方面的以下改进。
usesClearTraffic 弃用计划
In a future release, we plan to deprecate the usesCleartextTraffic element.
Apps that need to make unencrypted (HTTP) connections should migrate to
using a network security configuration file, which lets you
specify which domains your app needs to make cleartext connections to.
Be aware that network security configuration files are only supported on API levels 24 and higher. If your app has a minimum API level lower than 24, you should do both of the following:
- Set the
usesCleartextTrafficattribute totrue - Use a network configuration file
If your app's minimum API level is 24 or higher, you can use a network
configuration file and you don't need to set usesCleartextTraffic.
限制隐式 URI 授权
Currently, if an app launches an intent with a URI that has the action Send,
SendMultiple, or ImageCapture, the system automatically grants the read and
write URI permissions to the target app. We plan to change this behavior in
Android 18. For this reason, we recommend that apps explicitly
grant the relevant URI permissions instead of relying on the system to grant
them.
每个应用的密钥库限制
应用应避免在 Android 密钥库中创建过多的密钥,因为它是设备上所有应用的共享资源。从 Android 17 开始,系统会强制限制应用可拥有的密钥数量。对于以 Android 17(API 级别 37)或更高版本为目标平台的非系统应用,密钥数量上限为 50,000 个;对于所有其他应用,密钥数量上限为 200,000 个。无论系统应用以哪个 API 级别为目标,其密钥数量上限均为 20 万。
如果应用尝试创建超出限制的密钥,则创建会失败并显示 KeyStoreException。异常的消息字符串包含有关密钥限制的信息。如果应用针对异常调用 getNumericErrorCode(),则返回值取决于应用的目标 API 级别:
- 如果应用以 Android 17(API 级别 37)或更高版本为目标平台,
getNumericErrorCode()会返回新的ERROR_TOO_MANY_KEYS值。 - 所有其他应用:
getNumericErrorCode()返回ERROR_INCORRECT_USAGE。
用户体验和系统界面
Android 17 包含以下变更,旨在打造更加一致、直观的用户体验。
在旋转后恢复默认 IME 可见性
从 Android 17 开始,当设备的配置发生变化(例如,通过旋转)且应用本身未处理此变化时,系统不会恢复之前的 IME 可见性。
如果应用经历了它无法处理的配置更改,并且应用需要在更改后显示键盘,您必须明确请求此行为。您可以通过以下方式之一提出此要求:
- 将
android:windowSoftInputMode属性设置为stateAlwaysVisible。 - 在 activity 的
onCreate()方法中以编程方式请求显示软键盘,或添加onConfigurationChanged()方法。
人工干预
Android 17 包含以下变更,这些变更会影响应用与键盘和触控板等人工输入设备的互动方式。
在指针捕获期间,触控板默认提供相对事件
Beginning with Android 17, if an app requests pointer capture using
View.requestPointerCapture() and the user uses a touchpad, the system
recognizes pointer movement and scrolling gestures from the user's touches and
reports them to the app in the same way as pointer and scroll wheel movements
from a captured mouse. In most cases, this removes the need for apps that
support captured mice to add special handling logic for touchpads. For more
details, see the documentation for View.POINTER_CAPTURE_MODE_RELATIVE.
Previously, the system did not attempt to recognize gestures from the touchpad,
and instead delivered the raw, absolute finger locations to the app in a similar
format to touchscreen touches. If an app still requires this absolute data, it
should call the new View.requestPointerCapture(int) method with
View.POINTER_CAPTURE_MODE_ABSOLUTE instead.
媒体
Android 17 包含媒体行为方面的以下变更。
后台音频安全加固
Beginning with Android 17, the audio framework enforces restrictions on background audio interactions including audio playback, audio focus requests, and volume change APIs to ensure that these changes are started intentionally by the user.
If the app tries to call audio APIs while the app is not in a valid lifecycle,
the audio playback and volume change APIs fail silently without throwing an
exception or providing a failure message. The audio focus API fails with the
result code AUDIOFOCUS_REQUEST_FAILED.
For more information, including mitigation strategies, see Background audio hardening.
连接
Android 17 包含以下变更,旨在增强设备连接。
在蓝牙绑定丢失时自动重新配对
Android 17 introduces autonomous re-pairing, a system-level enhancement designed to automatically resolve Bluetooth bond loss.
Previously, if a bond was lost, users had to manually navigate to Settings to unpair and then re-pair the peripheral. This feature builds upon the security improvement of Android 16 by allowing the system to re-establish bonds in the background without requiring users to manually navigate to Settings to unpair and re-pair peripherals.
While most apps will not require code changes, developers should be aware of the following behavior changes in Bluetooth stack:
- New pairing context: The
ACTION_PAIRING_REQUESTnow includes theEXTRA_PAIRING_CONTEXTextra which allows apps to distinguish between a standard pairing request and an autonomous system-initiated re-pairing attempt. - Conditional key updates: Existing security keys will only be replaced if the re-pairing is successful and new connection meets or exceeds the security level of the previous bond.
- Modified intent timing: The
ACTION_KEY_MISSINGintent is now broadcast only if the autonomous re-pairing attempt fails. This reduces unnecessary error handling in the app if the system successfully recovers the bond in the background. - User notification: The system manages re-pairing via new UI notifications and dialogs. Users will be prompted to confirm the re-pairing attempt to ensure they are aware of the reconnection.
Peripheral device manufacturers and companion app developers should verify that hardware and app gracefully handle bond transitions. To test this behavior, simulate a remote bond loss using either of the following methods:
- Manually remove the bond information from the peripheral device
- Manually unpair the device in: Settings > Connected devices