与之前的版本一样,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.
Android skills
View on GitHub
Manage AppWidget updates and bitmap memory
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
Bitmapand bitmap-backedIconobjects (Icon.TYPE_BITMAPandIcon.TYPE_ADAPTIVE_BITMAP) stored inRemoteViews.mBitmapCache(such as calls tosetImageViewBitmap,Icon.createWithBitmap,Icon.createWithAdaptiveBitmap, or Jetpack GlanceImageProvider(bitmap)). Each uniqueBitmapor bitmap-backedIconinstance inmBitmapCacheis counted once perRemoteViewshierarchy. - URI-backed images (
Icon.createWithContentUri,setImageViewUri, or GlanceImageProvider(uri)) don't count toward theRemoteViewsIPC byte cap insystem_server, but the widget host process decodes the referencedcontent://file at full resolution into its own heap. Always write a downsampled image intocontext.cacheDirbefore exposing it through aFileProviderURI.
Mitigation steps
To keep your widget updates within the memory ceiling across phones, tablets, and foldables, do the following:
Compute your runtime memory budget from
WindowMetrics: On API level 30 and higher, read the active window bounds fromWindowManager.currentWindowMetrics.boundsrather thanresources.displayMetrics. On multi-resolution devices and foldables,displayMetricscan report inactive display dimensions. Estimate your total widget image budget at6L * 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() }Downsample images to the widget's viewable dimensions and use
RGB_565: Decode bitmaps with power-of-twoBitmapFactory.Options.inSampleSizevalues sized to the widget's maximum display dimensions (maxWidthDpbymaxHeightDp), and useBitmap.Config.RGB_565(2bytes per pixel) instead ofARGB_8888(4bytes per pixel) for opaque photographs and thumbnails.Hoist bitmap decoding outside
provideContentin Jetpack Glance: When usingSizeMode.ResponsiveorSizeMode.Exact, Glance invokes yourprovideContentlambda once per size bucket. Decode each sharedBitmaponce insideprovideGlancebefore callingprovideContentso all size buckets reference the sameBitmapinstance inRemoteViews.mBitmapCache.Use full
updateAppWidgetcalls when replacing images: In classicAppWidgetProviderimplementations, avoid callingAppWidgetManager.partiallyUpdateAppWidgetto swapBitmaporIconviews. Partial updates merge new actions into the existingRemoteViewstree insystem_serverwithout evicting previously cached image actions. Build a completeRemoteViewslayout and callupdateAppWidgetinstead.Provide an error fallback layout: In Jetpack Glance, override
onCompositionErrorto render a zero-bitmapRemoteViewsfallback 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
InputConnectioncan retrieve candidate selection data by callingTextAttribute.isTextSuggestionSelected(). These apps should then callAccessibilityEvent.setTextChangeTypes()when dispatchingTYPE_VIEW_TEXT_CHANGEDevents. Apps targeting Android 17 (API level 37) that use the standardTextViewwill have this feature enabled by default. (That is,TextViewwill 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_CHANGEDevents can callAccessibilityEvent.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 legacyMODE_BACKGROUND_ACTIVITY_START_ALLOWEDconstant. Instead, you should adopt granular controls likeMODE_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_ALARMaudio 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.