行為變更：指定 Android 17 以上版本的應用程式

和先前版本一樣，Android 17 也包含可能會影響應用程式的行為變更。以下行為變更僅適用於指定 Android 17 以上版本的應用程式。如果應用程式指定 Android 17 以上版本，建議您視情況修改應用程式，以支援這些行為。

此外，無論應用程式的 targetSdkVersion 為何，請務必查看對所有 Android 17 應用程式有影響的行為變更清單。

注意： 本頁面列出部分較重要的異動。詳情請參閱 Android 17 版本資訊。

使用者體驗和系統 UI

Android 17 包含下列異動項目，旨在打造更一致、直覺的使用者體驗。

記憶體限制小工具

自 Android 17 起，如果應用程式指定 Android 17 (API 級別 37) 以上版本為目標，系統會對 RemoteViews 更新強制執行嚴格的記憶體限制。當應用程式將 RemoteViews 物件傳遞至 AppWidgetManager.updateAppWidget 時，system_server 會計算酬載中所有方向和大小值區的所有圖片資料總記憶體用量。如果總記憶體超過系統上限 (mMaxWidgetBitmapMemory)，系統會拒絕更新並擲回 IllegalArgumentException：

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

如果應用程式指定 API 級別 36 以下，系統會將這項記憶體違規記錄為警告 (Slog.w)，不會擲回例外狀況。

Android 技能

前往 GitHub 查看

管理 AppWidget 更新和點陣圖記憶體

使用 AppWidget 更新和記憶體 Android 技能，對小工具點陣圖進行降取樣、簡化回應式圖片，並確保 Glance 和傳統 AppWidgetProvider 小工具的記憶體用量，符合 Android 17 RemoteViews 限制。

如要透過 Android CLI 安裝技能，請執行：

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

系統如何計算記憶體上限

系統會根據目前顯示設定，將小工具點陣圖記憶體預算設為 6 * width * height 位元組 (1.5 * 4 * width * height，相當於全螢幕 ARGB_8888 緩衝區大小的 1.5 倍)。在 API 級別 37 以上，這項計算會包含下列兩項：

• 儲存在 RemoteViews.mBitmapCache 中的記憶體內 Bitmap 和點陣圖支援的 Icon 物件 (Icon.TYPE_BITMAP 和 Icon.TYPE_ADAPTIVE_BITMAP)，例如呼叫 setImageViewBitmap、Icon.createWithBitmap、Icon.createWithAdaptiveBitmap 或 Jetpack Glance ImageProvider(bitmap)。mBitmapCache 中每個不重複的 Bitmap 或點陣圖支援的 Icon 例項，在每個 RemoteViews 階層中都會計入一次。
• URI 支援的圖片 (Icon.createWithContentUri、setImageViewUri 或 Glance ImageProvider(uri)) 不會計入 system_server 中的 RemoteViews IPC 位元組上限，但小工具主機程序會將參照的 content:// 檔案以完整解析度解碼至自己的堆積。請務必先將降取樣圖片寫入 context.cacheDir，再透過 FileProvider URI 公開。

緩解步驟

如要確保手機、平板電腦和摺疊式裝置的小工具更新不超過記憶體上限，請按照下列步驟操作：

1. 從 WindowMetrics 計算執行階段記憶體預算：在 API 級別 30 以上，請從 WindowManager.currentWindowMetrics.bounds 讀取有效視窗邊界，而非 resources.displayMetrics。在多解析度裝置和摺疊式裝置上，displayMetrics 可能會回報未啟用的螢幕尺寸。請將小工具圖片總預算估算為 6L * bounds.width() * bounds.height()，如以下範例所示：

   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. 將圖片降取樣至小工具的可檢視尺寸，並使用 RGB_565： 使用 2 的乘冪 BitmapFactory.Options.inSampleSize 值解碼點陣圖，其大小應為小工具的最大顯示尺寸 (maxWidthDp 乘以 maxHeightDp)，並針對不透明相片和縮圖使用 Bitmap.Config.RGB_565 (每個像素 2 位元組)，而非 ARGB_8888 (每個像素 4 位元組)。

3. 在 Jetpack Glance 中，將點陣圖解碼作業移至 provideContent 外部：使用 SizeMode.Responsive 或 SizeMode.Exact 時，Glance 會針對每個大小值區叫用一次 provideContent lambda。在呼叫 provideContent 之前，在 provideGlance 內解碼每個共用的 Bitmap 一次，讓所有大小值區都參照 RemoteViews.mBitmapCache 中的同一個 Bitmap 執行個體。

4. 替換圖片時，請使用完整的 updateAppWidget 呼叫：在傳統 AppWidgetProvider 實作中，請避免呼叫 AppWidgetManager.partiallyUpdateAppWidget 來切換 Bitmap 或 Icon 檢視畫面。部分更新會將新動作合併至 system_server 中現有的 RemoteViews 樹狀結構，不會移除先前快取的映像檔動作。請建構完整的 RemoteViews 版面配置，並改為呼叫 updateAppWidget。

5. 提供錯誤備用版面配置：在 Jetpack Glance 中，覆寫 onCompositionError，在更新失敗時轉譯零點陣圖 RemoteViews 備用版面配置。

如要檢查已連結裝置上小工具目前的序列化點陣圖記憶體用量，請執行下列指令：

adb shell dumpsys appwidget

核心功能

Android 17 包含下列異動項目，這類變更會修改或擴充 Android 系統的各種核心功能。

MessageQueue 的新無鎖定實作

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

如需了解详情（包括缓解措施），请参阅 MessageQueue 行为变更指南。

靜態最終欄位現在無法修改

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

無障礙設定

Android 17 進行下列變更，提升無障礙功能。

支援複雜輸入法實體鍵盤輸入的無障礙功能

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 (Encrypted Client 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 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 並改善選擇加入機制：我們正在調整背景活動啟動 (BAL) 限制，將保護措施擴展至 IntentSender。開發人員必須停止使用舊版 MODE_BACKGROUND_ACTIVITY_START_ALLOWED 常數。建議改用 MODE_BACKGROUND_ACTIVITY_START_ALLOW_IF_VISIBLE 等精細控制項，限制只有在呼叫端應用程式可見時，才能啟動活動，大幅縮小攻擊面。
• 採用工具：開發人員應使用嚴格模式和更新後的 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 欄位

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

• ACCOUNT_NAME
• ACCOUNT_TYPE
• ACCOUNT_TYPE_AND_DATA_SET

使用 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) 上忽略螢幕方向、大小調整和顯示比例限制

我們在 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.