行為變更：所有應用程式

Android 17 平台包含可能對應用程式造成影響的行為變更。無論 targetSdkVersion 為何，凡是在 Android 17 上執行的應用程式，「一律」都會受到下列行為變更所影響。您必須測試自己的應用程式，並視需要進行修改，以便在適當情況下支援這些變更。

另請務必查看僅對指定 Android 17 為目標版本的應用程式造成影響的行為變更。

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

核心功能

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

應用程式記憶體限制

Android 17 introduces app memory limits based on the device's total RAM to create a more stable and deterministic environment for your apps and Android users. These limits focus on memory leaks and other outliers before they trigger system-wide instability resulting in UI stuttering, higher battery drain, and apps being killed. While we anticipate minimal impact on the vast majority of app sessions, we recommend the following memory best practices, including establishing a baseline for memory.

You can determine if your app session was impacted by calling getDescription in ApplicationExitInfo; if your app was affected, the exit reason will be REASON_OTHER and the description will contain the string "MemoryLimiter:AnonSwap" along with other information. You can also use trigger-based profiling with TRIGGER_TYPE_ANOMALY to get heap dumps that are collected when the memory limit is hit.

The Manage your app's memory documentation gives information to help you diagnose your app's memory issues and optimize its resource consumption.

Test your app's behavior under the memory constraints

You can use Android Debug Bridge (adb) to adjust or disable the memory limits on any device that imposes them. The shell command am provides three subcommands to adjust the memory limits. (These commands have no effect on a device which does not impose memory limits.)

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

ignore

Instructs the memory limiter to ignore some or all processes. Passing a UID (Android User ID) instructs the memory limiter to ignore enforcement on all processes associated with that UID. You can also pass all (ignore all apps) or none (do not ignore any apps). Passing none overrides any previous calls to am memory-limiter ignore.

If you instruct the memory limiter to ignore a UID, you can still apply a manual memory limit to a process within the app by calling am memory-limiter manual.

manual

Instructs the system to impose a memory constraint on the process with the specified PID (Process ID). The memory constraint is specified as an integer number of MB; for example, passing 30 specifies that the process is limited to 30 MB of memory. Passing max removes all memory limits on that process. Passing none removes any manual limits set on the process, restoring the system's default limit (if any).

status

Reports the current status of the memory limiter. The status includes the memory limits imposed on visible and non-visible processes.

隱私權

Android 17 包含下列異動，可提升使用者隱私。

簡訊動態密碼防護

從 Android 17 開始，Android 將擴大保護含有動態密碼 (OTP) 的簡訊。

在舊版 Android 中，這項保護措施主要著重於簡訊擷取器格式。對於大多數應用程式，含有簡訊擷取器雜湊的訊息傳送作業延遲了三小時。不過，某些應用程式 (例如預設簡訊處理常式) 和擁有雜湊的應用程式不受延遲影響。

從 Android 17 開始，這項保護措施也適用於 WebOTP 格式訊息。如果應用程式有權讀取簡訊，但不是 WebOTP 訊息的預定接收者 (由網域驗證決定)，則在收到訊息後三小時內，應用程式無法存取該訊息。這項異動旨在提升使用者安全性，確保只有與訊息中提及的網域相關聯的應用程式，才能以程式輔助方式讀取驗證碼。

在這三小時的延遲期間，系統會暫緩 SMS_RECEIVED_ACTION 廣播，並篩除「簡訊供應商」資料庫查詢。延遲時間過後，這些應用程式就能取得簡訊。這項異動適用於所有應用程式，無論目標 API 級別為何。

某些應用程式 (例如預設簡訊小幫手應用程式、連結裝置隨附應用程式等) 不受這項延遲限制。所有需要讀取簡訊來擷取動態密碼的應用程式，都應改用 SMS Retriever 或 SMS User Consent API，確保功能持續運作。

注意： 如果應用程式指定 Android 17 (API 級別 37) 以上版本，這項保護措施也會擴及標準簡訊。詳情請參閱「行為變更：指定 Android 17 的應用程式」說明文件中的「標準簡訊的動態密碼保護」一節。

安全性

Android 17 對裝置和應用程式安全性進行了下列改善。

usesClearTraffic 淘汰計畫

我們計劃在日後推出的版本中淘汰 usesCleartextTraffic 元素。如果應用程式需要建立未加密 (HTTP) 連線，應改用網路安全設定檔案，指定應用程式需要建立明文連線的網域。

請注意，網路安全性設定檔僅支援 API 級別 24 以上版本。如果應用程式的最低 API 級別低於 24，請同時執行下列兩項操作：

• 將 usesCleartextTraffic 屬性設為 true
• 使用網路設定檔

如果應用程式的最低 API 級別為 24 以上，您可以使用網路設定檔，不必設定 usesCleartextTraffic。

限制隱含 URI 授權

目前，如果应用启动具有操作 ACTION_SEND、ACTION_SEND_MULTIPLE 或 ACTION_IMAGE_CAPTURE 的 URI 的 intent，系统会自动向目标应用授予读取和写入 URI 权限。从 Android 18 开始，系统将不再自动授予这些权限。因此，我们建议应用明确授予相关 URI 权限，而不是依赖系统来授予这些权限。

如需检测应用中这些 intent 的使用情况，请将 StrictMode 与 detectImplicitUriPermissionGrant() 搭配使用，以触发违规行为：

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);

或者，您也可以监控记录的异常，其中包含系统隐式设置授权时显示的消息 Please set the grant explicitly in the app。您可以使用以下 adb 命令监控这些日志：

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

如需明确授予必要的权限，请将 FLAG_GRANT_READ_URI_PERMISSION 标志添加到 ACTION_SEND 和 ACTION_SEND_MULTIPLE intent：

Kotlin

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION)

Java

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION);

为 ACTION_IMAGE_CAPTURE intent 添加 FLAG_GRANT_READ_URI_PERMISSION 和 FLAG_GRANT_WRITE_URI_PERMISSION 标志：

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);

個別應用程式金鑰庫限制

應用程式應避免在 Android KeyStore 中建立過多金鑰，因為這是裝置上所有應用程式的共用資源。從 Android 17 開始，系統會強制限制應用程式可擁有的金鑰數量。如果非系統應用程式指定 Android 17 (API 級別 37) 以上版本，金鑰上限為 50,000 個，其他所有應用程式則為 200,000 個。無論目標 API 級別為何，系統應用程式的金鑰數量上限皆為 200,000 個。

如果應用程式嘗試建立超過上限的金鑰，建立作業會失敗，並顯示 KeyStoreException。例外狀況的訊息字串包含金鑰限制的相關資訊。如果應用程式對例外狀況呼叫 getNumericErrorCode()，傳回值會因應用程式指定的 API 級別而異：

• 指定 Android 17 (API 級別 37) 以上版本的應用程式：getNumericErrorCode() 會傳回新的 ERROR_TOO_MANY_KEYS 值。
• 所有其他應用程式：getNumericErrorCode() 會傳回 ERROR_INCORRECT_USAGE。

封鎖跨設定檔回送流量

自 Android 17 起，系統預設不再允許跨設定檔回送流量。同一設定檔內的回送流量不受影響。無論應用程式指定的 API 級別為何，這項異動適用於在 Android 17 以上版本執行的所有應用程式。

使用者體驗和系統 UI

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

裝置旋轉後自動恢復預設的 IME 版面空間

從 Android 17 開始，如果裝置設定變更 (例如旋轉)，且應用程式本身未處理這項變更，系統就不會還原先前的輸入法編輯器顯示設定。

如果應用程式發生未處理的設定變更，且在變更後需要顯示鍵盤，您必須明確要求顯示鍵盤。您可以透過下列任一方式提出要求：

• 將 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 推出自主重新配對功能，這項系統層級強化功能可自動解決藍牙綁定遺失的問題。

過去，如果繫結中斷，使用者必須手動前往「設定」解除配對，然後重新配對周邊裝置。這項功能以 Android 16 的安全性改善項目為基礎，可讓系統在使用者同意後重新建立繫結。這樣一來，使用者就不必手動前往「設定」解除配對，再重新配對周邊裝置。

雖然大多數應用程式不需要變更程式碼，但開發人員應留意藍牙堆疊中的下列行為變更：

• 新的配對情境：ACTION_PAIRING_REQUEST 現在包含 EXTRA_PAIRING_CONTEXT 額外資訊，可讓應用程式區分標準配對要求和自主系統啟動的重新配對嘗試。
• 條件式金鑰更新：只有在重新配對成功，且新連線達到或超過先前綁定的安全性等級時，才會更換現有的安全金鑰。
• 修改意圖時間：現在只有在自主重新配對失敗時，才會廣播 ACTION_KEY_MISSING 意圖。如果系統在背景成功復原繫結，就能減少應用程式中不必要的錯誤處理。
• 使用者通知：系統會透過新的 UI 通知和對話方塊管理重新配對。系統會提示使用者確認重新配對，確保他們知道重新連線。

周邊裝置製造商和隨附應用程式開發人員應確認硬體和應用程式能妥善處理繫結轉換。如要測試這項行為，請使用下列任一方法模擬遠端綁定中斷：

• 手動移除周邊裝置的繫結資訊
• 依序前往「設定」>「已連結的裝置」，手動解除裝置配對