行為變更：所有應用程式

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

另請務必查看僅對指定 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 (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，系統會自動將讀取和寫入 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 密钥库中创建过多密钥，因为密钥库是设备上所有应用的共享资源。从 Android 17 开始，系统会强制限制应用可以拥有的密钥数量。对于以 Android 17（API 级别 37）或更高版本为目标平台的非系统应用，此限制为 50,000 个键；对于所有其他应用，此限制为 200,000 个键。系统应用的密钥数量上限为 20 万，无论其目标 API 级别为何。

如果应用尝试创建超出限制的密钥，则创建会失败，并显示 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 (API 級別 37)，限制會更嚴格。對於這些應用程式，前景服務必須具備使用期間 (WIU) 功能，除非應用程式具有精確鬧鐘權限，且與 USAGE_ALARM 音訊串流互動。

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

連線能力

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

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

Android 17 引入了自主重新配对功能，这是一项系统级增强功能，旨在自动解决蓝牙绑定丢失问题。

以前，如果绑定丢失，用户必须手动前往“设置”取消配对外围设备，然后重新配对。此功能以 Android 16 的安全改进为基础，允许系统在后台重新建立绑定，而无需用户手动前往“设置”取消配对外围设备并重新配对。

虽然大多数应用不需要更改代码，但开发者应注意蓝牙堆栈中的以下行为变更：

• 新的配对上下文：ACTION_PAIRING_REQUEST 现在包含 EXTRA_PAIRING_CONTEXT extra，使应用能够区分标准配对请求和系统发起的自主重新配对尝试。
• 有条件地更新密钥：只有在重新配对成功且新连接的安全级别达到或超过之前绑定的安全级别时，系统才会替换现有安全密钥。
• 修改了 intent 时间：现在，仅当自主重新配对尝试失败时，系统才会广播 ACTION_KEY_MISSING intent。如果系统在后台成功恢复绑定，这会减少应用中不必要的错误处理。
• 用户通知：系统通过新的界面通知和对话框管理重新配对。系统会提示用户确认重新配对尝试，以确保他们知道重新连接。

外围设备制造商和配套应用开发者应验证硬件和应用是否能妥善处理绑定转换。如需测试此行为，请使用以下任一方法模拟远程绑定丢失：

• 手动从外围设备中移除绑定信息
• 在“设置”>“已连接的设备”中手动取消配对设备