行为变更：所有应用

Android 17 平台包含一些可能会影响您的应用的行为变更。以下行为变更将影响在 Android 17 上运行的所有应用，无论采用哪种 targetSdkVersion 都不例外。您应该测试您的应用，然后根据需要酌情修改，以便支持这些变更。

此外，请务必查看仅影响以 Android 17 为目标平台的应用的行为变更列表。

注意： 本页列出了一些比较重要的变更。如需了解更多详细信息，请参阅 Android 17 版本说明。

核心功能

Android 17（API 级别 37）包含以下变更，这些变更会修改或扩展 Android 系统的各种核心功能。

应用内存限制

Android 17 引入了基于设备总 RAM 的应用内存限制，以便为您的应用和 Android 用户打造更稳定、更确定的环境。在 Android 17 中，系统会保守地设置限制，以建立系统基准，在极端内存泄漏和其他异常情况导致系统范围内的不稳定（导致界面卡顿、耗电过快和应用被终止）之前，针对这些情况采取措施。虽然我们预计此变化对绝大多数应用会话的影响微乎其微，但我们建议您遵循以下内存最佳实践，包括建立内存基准。

注意： 内存限制仅适用于部分 Android 设备。

您可以通过在 ApplicationExitInfo 中调用 getDescription 来确定应用会话是否受到影响；如果应用受到影响，退出原因将为 REASON_OTHER，说明将包含字符串 "MemoryLimiter:AnonSwap" 以及其他信息。您还可以将 TRIGGER_TYPE_ANOMALY 与基于触发器的分析搭配使用，以获取在达到内存限制时收集的堆转储。

管理应用的内存文档提供的信息可帮助您诊断应用的内存问题并优化其资源消耗。

在内存受限的情况下测试应用的运行情况

您可以使用 Android 调试桥 (adb) 调整或停用任何施加内存限制的设备上的内存限制。shell 命令 am 提供了三个用于调整内存限制的子命令。（这些命令对未施加内存限制的设备没有影响。）

• am memory-limiter ignore <uid>|none|all
• am memory-limiter manual <pid> <limit>|max|none
• am memory-limiter status

ignore

指示内存限制器忽略部分或全部进程。传递 UID（Android 用户 ID）会指示内存限制器忽略对与该 UID 相关联的所有进程的强制执行。您还可以传递 all（忽略所有应用）或 none（不忽略任何应用）。传递 none 会替换之前对 am memory-limiter ignore 的任何调用。

如果您指示内存限制器忽略某个 UID，您仍然可以通过调用 am memory-limiter manual 为应用内的进程应用手动内存限制。

manual

指示系统对具有指定 PID（进程 ID）的进程施加内存限制。内存限制以整数形式的 MB 数指定；例如，传递 30 指定进程的内存限制为 30 MB。传递 max 会移除相应进程的所有内存限制。 传递 none 会移除对进程设置的所有手动限制，从而恢复系统的默认限制（如果有）。

status

报告内存限制器的当前状态。该状态包括对可见进程和非可见进程施加的内存限制。

隐私权

Android 17 包含以下变更，旨在提升用户隐私保护。

动态短信密码保护

Beginning with Android 17, Android is expanding its protection for SMS messages containing one-time passwords (OTP).

In previous versions of Android, this protection was primarily focused on the SMS Retriever format. Delivery of messages containing an SMS retriever hash was delayed for most apps for three hours. However, certain apps (like the default SMS handler) were exempt from the delay, and the app that owned the hash was also exempted.

Beginning with Android 17, the protection is also applied to WebOTP format messages. If an app has permission to read SMS messages but is not the intended recipient of a WebOTP message (as determined by domain verification), the message is not accessible to the app until three hours after the message's receipt. This change is intended to improve user security by ensuring that only apps associated with the domain mentioned in the message can programmatically read the verification code.

During this three hour delay, the SMS_RECEIVED_ACTION broadcast is withheld and SMS provider database queries are filtered. The SMS message is available to these apps after the delay. This change applies to all apps, regardless of their target API level.

Certain apps such as the default SMS assistant app, connected device companion apps, etc., are exempted from this delay. All apps that rely on reading SMS messages for OTP extraction should transition to using SMS Retriever or SMS User Consent APIs to ensure continued functionality.

Note: If your app targets Android 17 (API level 37) or higher, this protection is also extended to standard SMS messages. For more information, see OTP protection for standard SMS messages in the Behavior changes: Apps targeting Android 17 documentation.

安全

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 usesCleartextTraffic attribute to true
• 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 ACTION_SEND, ACTION_SEND_MULTIPLE, or ACTION_IMAGE_CAPTURE, the system automatically grants the read and write URI permissions to the target app. Starting in Android 18, the system will no longer automatically grant these permissions. For this reason, we recommend that apps explicitly grant the relevant URI permissions instead of relying on the system to grant them.

To detect the usage of these intents in your app, use StrictMode with detectImplicitUriPermissionGrant() to trigger a violation:

Kotlin

val policy = StrictMode.VmPolicy.Builder()
    .detectImplicitUriPermissionGrant()
    .penaltyLog()
    .build()
StrictMode.setVmPolicy(policy)

Java

StrictMode.VmPolicy policy = new StrictMode.VmPolicy.Builder()
    .detectImplicitUriPermissionGrant()
    .penaltyLog()
    .build();
StrictMode.setVmPolicy(policy);

Alternatively, you can monitor for logged exceptions containing the message Please set the grant explicitly in the app that appears when system implicitly sets the grant. You can monitor for these logs using the following adb command:

adb logcat | grep "Please set the grant explicitly in the app"

To explicitly grant the necessary permissions, add the FLAG_GRANT_READ_URI_PERMISSION flag to ACTION_SEND and ACTION_SEND_MULTIPLE intents:

Kotlin

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION)

Java

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION);

Include both FLAG_GRANT_READ_URI_PERMISSION and FLAG_GRANT_WRITE_URI_PERMISSION flags for ACTION_IMAGE_CAPTURE intents:

Kotlin

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION or Intent.FLAG_GRANT_WRITE_URI_PERMISSION)

Java

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION | Intent.FLAG_GRANT_WRITE_URI_PERMISSION);

每个应用的密钥库限制

Apps should avoid creating excessive numbers of keys in Android Keystore, because it is a shared resource for all apps on the device. Beginning with Android 17, the system enforces a limit on the number of keys an app can own. The limit is 50,000 keys for non-system apps targeting Android 17 (API level 37) or higher, and 200,000 keys for all other apps. System apps have a limit of 200,000 keys, regardless of which API level they target.

If an app attempts to create keys beyond the limit, the creation fails with a KeyStoreException. The exception's message string contains information about the key limit. If the app calls getNumericErrorCode() on the exception, the return value depends on what API level the app targets:

• Apps targeting Android 17 (API level 37) or higher: getNumericErrorCode() returns the new ERROR_TOO_MANY_KEYS value.
• All other apps: getNumericErrorCode() returns ERROR_INCORRECT_USAGE.

阻止跨资料环回流量

从 Android 17 开始，默认情况下不再允许跨个人资料环回流量。同一个人资料内的环回流量不受影响。 此项变更适用于在 Android 17 或更高版本上运行的所有应用，无论应用以哪个 API 级别为目标平台。

用户体验和系统界面

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.

Note: The restrictions are more stringent if an app targets Android 17 (API level 37). For these apps, the foreground service must have while-in-use (WIU) capabilities, unless the app has the exact alarm permission and is interacting with USAGE_ALARM audio streams.

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_REQUEST now includes the EXTRA_PAIRING_CONTEXT extra 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_MISSING intent 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