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

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

无论应用的 targetSdkVersion 为何,都请务必查看对 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.

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. Always write a downsampled image into context.cacheDir before exposing it through a FileProvider URI.

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 的全新无锁实现

从 Android 17 开始,以 Android 17(API 级别 37)或更高版本为目标平台的应用会收到 android.os.MessageQueue 的全新无锁实现。新实现可提升性能并减少丢帧,但可能会破坏反映 MessageQueue 私有字段和方法的客户端。

如需了解详情(包括缓解措施),请参阅 MessageQueue 行为变更指南。

静态 final 字段现在不可修改

Apps running on Android 17 or higher that target Android 17 (API level 37) or higher cannot change static final fields. If an app attempts to change a static final field by using reflection, it will cause an IllegalAccessException. Attempting to modify one of these fields through JNI APIs (such as SetStaticLongField()) will cause the app to crash.

无障碍

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 introduces platform support for Encrypted Client Hello (ECH), a TLS extension that enhances user privacy by encrypting the Server Name Indication (SNI) in the TLS handshake. This encryption helps prevent network observers from easily identifying the specific domain your app is connecting to.

For apps targeting Android 17 (API level 37) or higher, ECH is used for TLS connections. ECH is active only if the networking library used by the app (for example, HttpEngine, WebView, or OkHttp) has integrated ECH support and the remote server also supports the ECH protocol. If ECH cannot be negotiated, the client sends an ECH extension with randomized contents (a mechanism called ECH GREASE). See RFC 9849 for more details on how ECH GREASE works.

To allow apps to customize this behavior, Android 17 adds a new <domainEncryption> element to the Network Security Configuration file. Developers can use <domainEncryption> within <base-config> or <domain-config> tags to select an ECH mode (for example, "enabled" or "disabled") on a global or per-domain basis.

For more information, see the Encrypted Client Hello documentation.

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

Android 17 引入了 ACCESS_LOCAL_NETWORK 运行时权限,以保护用户免遭未经授权的本地网络访问。由于此权限属于现有的 NEARBY_DEVICES 权限组,因此系统不会再次提示已授予其他 NEARBY_DEVICES 权限的用户。这项新要求可防止恶意应用利用不受限制的本地网络访问权限进行隐蔽的用户跟踪和指纹识别。通过声明和请求此权限,您的应用可以发现并连接到局域网 (LAN) 上的设备,例如智能家居设备或投屏接收器。

以 Android 17(API 级别 37)或更高版本为目标平台的应用现在可以通过两种方式与局域网设备保持通信:采用系统介导、可保护隐私的设备选择器来跳过权限提示,或在运行时明确请求这项新权限,以保持本地网络通信。

如需了解详情,请参阅本地网络权限文档。

在实体设备上隐藏密码

If an app targets Android 17 (API level 37) or higher and the user is using a physical input device (for example, an external keyboard), the Android operating system applies the new show_passwords_physical setting to all characters in the password field. By default, that setting hides all password characters.

The Android system shows the last-typed password character to help the user see if they mistyped the password. However, this is much less necessary with larger external keyboards. In addition, devices with external keyboards often have larger displays, which increases the danger of someone seeing the typed password.

If the user is using the device's touchscreen, the system applies the new show_passwords_touch setting.

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

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.

安全

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

Activity 安全性

In Android 17, the platform continues its shift toward a "secure-by-default" architecture, introducing a suite of enhancements designed to mitigate high-severity exploits such as phishing, interaction hijacking, and confused deputy attacks. This update requires developers to explicitly opt in to new security standards to maintain app compatibility and user protection.

Key impacts for developers include:

  • BAL hardening & improved opt-in: We are refining Background Activity Launch (BAL) restrictions by extending protections to IntentSender. Developers must migrate away from the legacy MODE_BACKGROUND_ACTIVITY_START_ALLOWED constant. Instead, you should adopt granular controls like MODE_BACKGROUND_ACTIVITY_START_ALLOW_IF_VISIBLE, which restricts activity starts to scenarios where the calling app is visible, significantly reducing the attack surface.
  • Adoption tools: Developers should utilize strict mode and updated lint checks to identify legacy patterns and ensure readiness for future target SDK requirements.

默认启用 CT

如果应用以 Android 17(API 级别 37)或更高版本为目标平台,则默认启用证书透明度 (CT)。(在 Android 16 中,CT 可用,但应用必须选择启用。)

更安全的原生 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 字段

对于以 Android 17(API 级别 37)及更高版本为目标平台的应用,Contacts Provider 2 (CP2) 会限制数据视图中包含个人身份信息 (PII) 的某些列。启用此变更后,系统会从数据视图中移除这些列,以加强用户隐私保护。 受限列包括:

使用 ContactsContract.Data 中这些列的应用可以改为通过与 RAW_CONTACT_ID 联接,从 ContactsContract.RawContacts 中提取这些列。

在 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) 上忽略屏幕方向、尺寸调整和宽高比限制

We introduced Platform API changes in Android 16 to ignore orientation, resizability, and aspect ratio restrictions on large screens (sw >= 600dp) for apps targeting API level 36 or higher. Developers have the option to opt out of these changes with SDK 36, but this opt-out will no longer be available for apps that target Android 17 (API level 37) or higher.

For more information, see Restrictions on orientation and resizability are ignored.

连接

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.