行為變更：所有應用程式

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

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

核心功能

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

應用程式記憶體限制

Android 17 根據裝置的總 RAM 推出應用程式記憶體限制，為應用程式和 Android 使用者打造更穩定、更確定的環境。這些限制著重於記憶體流失和其他異常狀況，避免觸發系統不穩定，導致 UI 延遲、電池耗電量增加，以及應用程式遭到終止。雖然我們預期絕大多數應用程式工作階段受到的影響微乎其微，但仍建議您遵循下列記憶體最佳做法，包括建立記憶體基準。

您可以呼叫 ApplicationExitInfo 中的 getDescription，判斷應用程式工作階段是否受到影響。如果應用程式受到影響，結束原因會是 REASON_OTHER，說明則會包含 "MemoryLimiter:AnonSwap" 字串和其他資訊。您也可以搭配 TRIGGER_TYPE_ANOMALY 使用觸發條件式剖析，取得在達到記憶體限制時收集的記憶體快照資料。

「管理應用程式的記憶體」說明文件提供相關資訊，協助您診斷應用程式的記憶體問題，並最佳化資源消耗量。

測試應用程式在記憶體限制下的行為

您可以使用 Android Debug Bridge (adb)，在任何裝置上調整或停用記憶體限制。殼層指令 am 提供三個子指令，可用於調整記憶體限制。(如果裝置未施加記憶體限制，這些指令就不會產生任何作用)。

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

指示記憶體限制器忽略部分或所有程序。傳遞 UID (Android 使用者 ID)，指示記憶體限制器忽略與該 UID 相關聯的所有程序。您也可以傳遞 all (忽略所有應用程式) 或 none (不忽略任何應用程式)。傳遞 none 會覆寫先前對 am memory-limiter ignore 的任何呼叫。

如果指示記憶體限制器忽略 UID，您仍可呼叫 am memory-limiter manual，對應用程式中的程序套用手動記憶體限制。

manual

指示系統對指定 PID (程序 ID) 的程序施加記憶體限制。記憶體限制是以 MB 為單位的整數，例如傳遞 30 會指定程序限制為 30 MB 的記憶體。傳遞 max 會移除該程序的所有記憶體限制。傳遞 none 會移除程序中設定的所有手動限制，並還原系統的預設限制 (如有)。

status

回報記憶體限制器的目前狀態。狀態包括對可見和不可見程序施加的記憶體限制。

隱私權

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

簡訊動態密碼防護

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

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

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

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

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

安全性

Android 17 包含下列裝置和應用程式安全性改善項目。

usesClearTraffic 淘汰計畫

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

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

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

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

限制隱含 URI 授權

目前，如果應用程式啟動的意圖含有動作 ACTION_SEND、ACTION_SEND_MULTIPLE 或 ACTION_IMAGE_CAPTURE 的 URI，系統會自動將讀取和寫入 URI 權限授予目標應用程式。從 Android 18 開始，系統不會再自動授予這些權限。因此，建議應用程式明確授予相關 URI 權限，而非依賴系統授予。

如要偵測應用程式中這些意圖的使用情形，請搭配使用 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 意圖：

Kotlin

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION)

Java

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION);

為 ACTION_IMAGE_CAPTURE 意圖加入 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 包含下列異動項目，會影響應用程式與鍵盤和觸控板等人機輸入裝置互動的方式。

擷取指標時，觸控板預設會傳送相對事件

自 Android 17 起，如果應用程式使用 View.requestPointerCapture() 要求擷取指標，且使用者使用觸控板，系統會辨識使用者觸控時的指標移動和捲動手勢，並向應用程式回報，回報方式與擷取滑鼠的指標和滾輪移動相同。在大多數情況下，支援擷取滑鼠的應用程式不需要為觸控板新增特殊處理邏輯。詳情請參閱 View.POINTER_CAPTURE_MODE_RELATIVE 的說明文件。

先前，系統不會嘗試辨識觸控板的手勢，而是以類似觸控螢幕觸控的格式，將原始、絕對的手指位置傳送至應用程式。如果應用程式仍需要這項絕對資料，應改為使用 View.POINTER_CAPTURE_MODE_ABSOLUTE 呼叫新的 View.requestPointerCapture(int) 方法。

媒體

Android 17 包含下列媒體行為變更。

背景音訊強化

從 Android 17 開始，音訊架構會對背景音訊互動強制執行限制，包括音訊播放、音訊焦點要求和音量變更 API，確保這些變更是由使用者刻意啟動。

如果應用程式在無效的生命週期內嘗試呼叫音訊 API，音訊播放和音量變更 API 會自動失敗，不會擲回例外狀況或提供失敗訊息。音訊焦點 API 失敗，結果代碼為 AUDIOFOCUS_REQUEST_FAILED。

如需更多資訊 (包括緩解策略)，請參閱「背景音訊強化」。

連線能力

Android 17 包含下列異動項目，可強化裝置連線能力。

藍牙連線中斷時自動重新配對

Android 17 推出自主重新配對功能，這項系統層級強化功能可自動解決藍牙綁定遺失的問題。

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

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

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

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

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