行为变更：以 Android 17 或更高版本为目标平台的应用

与之前的版本一样，Android 17 包含一些可能会影响应用的行为变更。以下行为变更仅影响以 Android 17 或更高版本为目标平台的应用。如果您的应用以 Android 17 或更高版本为目标平台，您应该修改自己的应用以支持这些行为（如果适用）。

无论应用的 targetSdkVersion 为何，都请务必查看对 Android 17 上运行的所有应用都有影响的行为变更列表。

注意： 本页面列出了一些较为重要的变更。如需了解详情，请参阅 Android 17 版本说明。

用户体验和系统界面

Android 17 包含以下变更，旨在打造更一致、更直观的用户体验。

内存上限微件

Beginning with Android 17, the system enforces a strict memory limit on RemoteViews updates for apps targeting Android 17 (API level 37) or higher. When an app passes a RemoteViews object to AppWidgetManager.updateAppWidget, system_server calculates the total memory footprint of all image data across every orientation and size bucket in the payload. If the total memory exceeds the system ceiling (mMaxWidgetBitmapMemory), the system rejects the update and throws an IllegalArgumentException:

java.lang.IllegalArgumentException: RemoteViews for widget update exceeds maximum bitmap memory usage (used: XXXXX, max: YYYYY)

For apps targeting API level 36 or lower, the system logs this memory violation as a warning (Slog.w) without throwing an exception.

Android skills

View on GitHub

Manage AppWidget updates and bitmap memory

Use the AppWidget Updates and Memory Android skill to downsample widget bitmaps, deduplicate responsive images, and stay within Android 17 RemoteViews memory limits across Glance and classic AppWidgetProvider widgets.

To install the skill from the Android CLI, run:

android skills add glance-appwidget-updates-and-memory

How the system calculates the memory ceiling

The system sets the widget bitmap memory budget at 6 * width * height bytes (1.5 * 4 * width * height, equivalent to 1.5 times the size of a full-screen ARGB_8888 buffer) for the active display configuration. Under API level 37 and higher, this calculation includes both of the following:

• In-memory Bitmap and bitmap-backed Icon objects (Icon.TYPE_BITMAP and Icon.TYPE_ADAPTIVE_BITMAP) stored in RemoteViews.mBitmapCache (such as calls to setImageViewBitmap, Icon.createWithBitmap, Icon.createWithAdaptiveBitmap, or Jetpack Glance ImageProvider(bitmap)). Each unique Bitmap or bitmap-backed Icon instance in mBitmapCache is counted once per RemoteViews hierarchy.
• URI-backed images (Icon.createWithContentUri, setImageViewUri, or Glance ImageProvider(uri)) don't count toward the RemoteViews IPC byte cap in system_server, but the widget host process decodes the referenced content:// file at full resolution into its own heap. Prefer passing a downsampled Bitmap directly in memory (androidx.glance.ImageProvider(bitmap) or setImageViewBitmap), as FileProvider URI permission grants fail when a work-profile widget is placed on a personal home screen. If your widget must use a FileProvider URI, always write a downsampled image into context.cacheDir first.

Mitigation steps

To keep your widget updates within the memory ceiling across phones, tablets, and foldables, do the following:

1. Compute your runtime memory budget from WindowMetrics: On API level 30 and higher, read the active window bounds from WindowManager.currentWindowMetrics.bounds rather than resources.displayMetrics. On multi-resolution devices and foldables, displayMetrics can report inactive display dimensions. Estimate your total widget image budget at 6L * bounds.width() * bounds.height() as shown in the following example:

   private const val FALLBACK_MAX_BYTES = 15_000_000L
   
   fun calculateWidgetMemoryCapBytes(context: Context): Long {
       if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.R) {
           val wm = context.getSystemService(WindowManager::class.java)
               ?: return FALLBACK_MAX_BYTES
           val bounds = wm.currentWindowMetrics.bounds
           return 6L * bounds.width().toLong() * bounds.height().toLong()
       }
       val dm = context.resources.displayMetrics
       return 6L * dm.widthPixels.toLong() * dm.heightPixels.toLong()
   }
   

2. Downsample images to the widget's viewable dimensions and use RGB_565: Decode bitmaps with power-of-two BitmapFactory.Options.inSampleSize values sized to the widget's maximum display dimensions (maxWidthDp by maxHeightDp), and use Bitmap.Config.RGB_565 (2 bytes per pixel) instead of ARGB_8888 (4 bytes per pixel) for opaque photographs and thumbnails.

3. Hoist bitmap decoding outside provideContent in Jetpack Glance: When using SizeMode.Responsive or SizeMode.Exact, Glance invokes your provideContent lambda once per size bucket. Decode each shared Bitmap once inside provideGlance before calling provideContent so all size buckets reference the same Bitmap instance in RemoteViews.mBitmapCache.

4. Use full updateAppWidget calls when replacing images: In classic AppWidgetProvider implementations, avoid calling AppWidgetManager.partiallyUpdateAppWidget to swap Bitmap or Icon views. Partial updates merge new actions into the existing RemoteViews tree in system_server without evicting previously cached image actions. Build a complete RemoteViews layout and call updateAppWidget instead.

5. Provide an error fallback layout: In Jetpack Glance, override onCompositionError to render a zero-bitmap RemoteViews fallback if an update fails.

You can inspect your widget's current serialized bitmap memory usage on a connected device by running the following:

adb shell dumpsys appwidget

核心功能

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

MessageQueue 的全新无锁实现

Beginning with Android 17, apps targeting Android 17 (API level 37) or higher receive a new lock-free implementation of android.os.MessageQueue. The new implementation improves performance and reduces missed frames, but may break clients that reflect on MessageQueue private fields and methods.

For more information, including mitigation strategies, see MessageQueue behavior change guidance.

静态 final 字段现在不可修改

在 Android 17 或更高版本上运行且以 Android 17（API 级别 37）或更高版本为目标平台的应用无法更改 static final 字段。如果应用尝试使用反射来更改 static final 字段，则会导致 IllegalAccessException。尝试通过 JNI API（例如 SetStaticLongField()）修改其中一个字段会导致应用崩溃。

无障碍

Android 17 进行了以下更改，以改进无障碍功能。

复杂 IME 实体键盘输入的无障碍支持

This feature introduces new AccessibilityEvent and TextAttribute APIs to enhance screen reader spoken feedback for CJKV language input. CJKV IME apps can now signal whether a text conversion candidate has been selected during text composition. Apps with edit fields can specify text change types when sending text changed accessibility events. For example, apps can specify that a text change occurred during text composition, or that a text change resulted from a commit. Doing this enables accessibility services such as screen readers to deliver more precise feedback based on the nature of the text modification.

App adoption

• IME Apps: When setting composing text in edit fields, IMEs can use TextAttribute.Builder.setTextSuggestionSelected() to indicate whether a specific conversion candidate was selected.

• Apps with Edit Fields: Apps that maintain a custom InputConnection can retrieve candidate selection data by calling TextAttribute.isTextSuggestionSelected(). These apps should then call AccessibilityEvent.setTextChangeTypes() when dispatching TYPE_VIEW_TEXT_CHANGED events. Apps targeting Android 17 (API level 37) that use the standard TextView will have this feature enabled by default. (That is, TextView will handle retrieving data from the IME and setting text change types when sending events to accessibility services).

• Accessibility Services: Accessibility services that process TYPE_VIEW_TEXT_CHANGED events can call AccessibilityEvent.getTextChangeTypes() to identify the nature of the modification and adjust their feedback strategies accordingly.

隐私权

Android 17 包含以下旨在改进用户隐私保护的变更。

已启用 ECH（加密客户端 Hello）

Android 17 引入了对加密客户端问候 (ECH) 的平台支持，这是一种 TLS 扩展，可通过在 TLS 握手中加密服务器名称指示 (SNI) 来增强用户隐私。这种加密有助于防止网络观察者轻易识别出应用连接到的特定网域。

对于以 Android 17（API 级别 37）或更高版本为目标平台的应用，ECH 用于 TLS 连接。只有在应用使用的网络库（例如 HttpEngine、WebView 或 OkHttp）集成了 ECH 支持，并且远程服务器也支持 ECH 协议时，ECH 才会处于活跃状态。如果无法协商 ECH，客户端会发送包含随机内容的 ECH 扩展程序（一种称为 ECH GREASE 的机制）。如需详细了解 ECH GREASE 的运作方式，请参阅 RFC 9849。

为了允许应用自定义此行为，Android 17 向网络安全配置文件添加了新的 <domainEncryption> 元素。开发者可以在 <base-config> 或 <domain-config> 标记中使用 <domainEncryption>，以全局或按网域选择 ECH 模式（例如 "enabled" 或 "disabled"）。

如需了解详情，请参阅加密客户端问候文档。

以 Android 17 为目标平台的应用需要本地网络权限

Android 17 introduces the ACCESS_LOCAL_NETWORK runtime permission to protect users from unauthorized local network access. Because this falls under the existing NEARBY_DEVICES permission group, users who have already granted other NEARBY_DEVICES permissions aren't prompted again. This new requirement prevents malicious apps from exploiting unrestricted local network access for covert user tracking and fingerprinting. By declaring and requesting this permission, your app can discover and connect to devices on the local area network (LAN), such as smart home devices or casting receivers.

Apps targeting Android 17 (API level 37) or higher now have two paths to maintain communication with LAN devices: Adopt system-mediated, privacy-preserving device pickers to skip the permission prompt, or explicitly request this new permission at runtime to maintain local network communication.

For more information, see the Local network permission documentation.

Note: In Android 16, apps could opt in to local network permissions. Beginning with Android 17, enforcement is mandatory for apps that target Android 17 (API level 37) or higher.

在实体设备上隐藏密码

如果应用以 Android 17（API 级别 37）或更高版本为目标平台，并且用户使用的是实体输入设备（例如外接键盘），则 Android 操作系统会将新的 show_passwords_physical 设置应用于密码字段中的所有字符。默认情况下，该设置会隐藏所有密码字符。

Android 系统会显示最后输入的密码字符，以帮助用户查看是否输错了密码。不过，对于较大的外接键盘，这种需求要小得多。此外，配备外接键盘的设备通常具有更大的显示屏，这会增加他人看到所输入密码的风险。

如果用户使用的是设备的触摸屏，系统会应用新的 show_passwords_touch 设置。

针对标准短信的动态密码保护

Beginning with Android 17, Android is extending its SMS OTP protection to apply to standard SMS messages (SMS messages containing an OTP that do not use the WebOTP or SMS Retriever formats). For most apps targeting Android 17 (API level 37) or higher, these SMS messages do not become available until three hours after receipt. This delay is intended to help prevent OTP hijacking. 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.

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: Additional SMS OTP protections for WebOTP and SMS Retriever format messages apply to all apps, regardless of their target API level. For more information, see SMS OTP protection in the Behavior changes for all apps documentation.

安全

Android 17 对设备和应用安全性进行了以下改进。

Activity 安全性

在 Android 17 中，平台继续向“默认安全”架构转变，引入了一系列旨在缓解高严重性漏洞利用（例如钓鱼式攻击、互动劫持和混淆代理攻击）的增强功能。此次更新要求开发者明确选择启用新的安全标准，以保持应用兼容性并保护用户。

对开发者产生的主要影响包括：

• BAL 强化和改进的选择启用：我们正在优化后台 activity 启动 (BAL) 限制，将保护范围扩展到 IntentSender。开发者必须停止使用旧版 MODE_BACKGROUND_ACTIVITY_START_ALLOWED 常量。相反，您应该采用精细控制，例如 MODE_BACKGROUND_ACTIVITY_START_ALLOW_IF_VISIBLE，它会将 activity 启动限制在调用应用可见的场景中，从而显著减少攻击面。
• 采用工具：开发者应利用严格模式和更新后的 lint 检查来识别旧版模式，并确保为未来的目标 SDK 要求做好准备。

默认启用 CT

If an app targets Android 17 (API level 37) or higher, certificate transparency (CT) is enabled by default. (On Android 16, CT is available but apps had to opt in.)

更安全的原生 DCL - C

If your app targets Android 17 (API level 37) or higher, the Safer Dynamic Code Loading (DCL) protection introduced in Android 14 for DEX and JAR files now extends to native libraries.

All native files loaded using System.load() must be marked as read-only. Otherwise, the system throws UnsatisfiedLinkError.

We recommend that apps avoid dynamically loading code whenever possible, as doing so greatly increases the risk that an app can be compromised by code injection or code tampering.

限制 CP2 数据视图中的 PII 字段

For apps targeting Android 17 (API level 37) and higher, Contacts Provider 2 (CP2) restricts certain columns containing Personally Identifiable Information (PII) from the data view. When this change is enabled, these columns are removed from the data view to enhance user privacy. The restricted columns include:

• ACCOUNT_NAME
• ACCOUNT_TYPE
• ACCOUNT_TYPE_AND_DATA_SET

Apps that are using these columns from ContactsContract.Data can extract them from ContactsContract.RawContacts instead, by joining with RAW_CONTACT_ID.

在 CP2 中强制执行严格的 SQL 检查

对于以 Android 17（API 级别 37）及更高版本为目标平台的应用，如果在没有 READ_CONTACTS 权限的情况下访问 ContactsContract.Data 表，Contacts Provider 2 (CP2) 会强制执行严格的 SQL 查询验证。

做出此项更改后，如果应用没有 READ_CONTACTS 权限，则在查询 ContactsContract.Data 表时会设置 StrictColumns 和 StrictGrammar 选项。如果查询使用的模式与这些模式不兼容，则会被拒绝并导致抛出异常。

智能

Android 17 包含对系统智能的以下变更。

废弃 setContentCaptureEnabled

在某些设备上，内容捕获功能默认处于启用状态，以便设备端 AI 功能分析屏幕内容，从而提供智能体验。

从 Android 17 开始，ContentCaptureManager.setContentCaptureEnabled(boolean) API 方法已被废弃。对于以 Android 17（API 级别 37）或更高版本为目标平台的应用，调用 setContentCaptureEnabled(false) 不再会停用内容捕获功能。

如果您的应用需要继续停用内容捕获功能或限制系统捕获屏幕内容，您必须改用 FLAG_SECURE 窗口布局参数。

如需停用内容捕获，请在窗口中设置 FLAG_SECURE 标志，如以下示例所示：

Kotlin

window.setFlags(
    WindowManager.LayoutParams.FLAG_SECURE,
    WindowManager.LayoutParams.FLAG_SECURE
)

Java

getWindow().setFlags(
    WindowManager.LayoutParams.FLAG_SECURE,
    WindowManager.LayoutParams.FLAG_SECURE
);

如需了解详情，请参阅 WindowManager.LayoutParams.FLAG_SECURE 参考文档。

媒体

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.

Some audio restrictions apply to all apps. However, the restrictions are more stringent if an app targets Android 17 (API level 37). If one of these apps interacts with audio while it is in the background, it must have a foreground service running. In addition, the app must meet one or both of these requirements:

• The foreground service must have while-in-use (WIU) capabilities.
• The app must have the exact alarm permission and be interacting with USAGE_ALARM audio streams.

For more information, including mitigation strategies, see Background audio hardening.

设备规格

Android 17 包含以下变更，旨在提升各种尺寸和外形规格的设备上的用户体验。

平台 API 变更，在大屏设备 (sw>=600dp) 上忽略屏幕方向、尺寸调整和宽高比限制

我们在 Android 16 中引入了平台 API 变更，以便针对以 API 级别 36 或更高级别为目标平台的应用，忽略大屏设备（sw >= 600dp）上的屏幕方向、尺寸调整和宽高比限制。开发者可以选择在 SDK 36 中选择退出这些变更，但对于以 Android 17（API 级别 37）或更高版本为目标平台的应用，此选择退出选项将不再可用。

如需了解详情，请参阅系统会忽略对屏幕方向和可调整大小性的限制。

连接

Android 17 引入了以下变更，以提高一致性并与蓝牙 RFCOMM 套接字的标准 Java InputStream 行为保持一致。

RFCOMM 的 BluetoothSocket read() 行为保持一致

For apps targeting Android 17 (API level 37), the read() method of the InputStream obtained from an RFCOMM-based BluetoothSocket now returns -1 when the socket is closed or the connection is dropped.

This change makes RFCOMM socket behavior consistent with LE CoC sockets and aligns with the standard InputStream.read() documentation, which states that -1 is returned when the end of the stream is reached.

Apps that rely solely on catching an IOException to break out of a read loop may be impacted by this change and should update the BluetoothSocket read loops to explicitly check for a return value of -1. This ensures the loop terminates correctly when the remote device disconnects or the socket is closed. For an example of the recommended implementation, see the code snippet in the Transfer Bluetooth data guide.