和先前版本一樣，Android 17 也包含可能會影響應用程式的行為變更。以下行為變更僅適用於指定 Android 17 以上版本的應用程式。如果應用程式指定 Android 17 以上版本，建議您視情況修改應用程式，以支援這些行為。
此外，無論應用程式的 targetSdkVersion 為何，請務必查看對所有 Android 17 應用程式有影響的行為變更清單。
使用者體驗和系統 UI
Android 17 包含下列異動項目，旨在打造更一致、直覺的使用者體驗。
記憶體限制小工具
自 Android 17 起，如果應用程式指定 Android 17 (API 級別 37) 以上版本，系統會對 RemoteViews 封包中點陣圖和圖示的合併記憶體用量，強制執行嚴格的記憶體限制 (1.5 * 螢幕寬度 * 螢幕高度 * 4)。如果超出這些限制，系統會擲回致命的 IllegalArgumentException，並導致應用程式程序停止運作。
詳情請參閱 UpdateAppWidget。
核心功能
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 進行下列變更，提升無障礙功能。
支援複雜輸入法實體鍵盤輸入的無障礙功能
這項功能導入了新的 AccessibilityEvent 和 TextAttribute API，可強化 CJKV 語言輸入的螢幕閱讀器互動朗讀功能。中日韓越文輸入法應用程式現在可以指出，在文字組合期間是否已選取文字轉換候選字。具有編輯欄位的應用程式，可在傳送文字變更無障礙事件時，指定文字變更類型。舉例來說，應用程式可以指定在文字組合期間發生文字變更，或文字變更是由修訂版本造成。這樣一來，螢幕閱讀器等無障礙服務就能根據文字修改的性質，提供更精確的回饋。
應用程式採用數
IME 應用程式：在編輯欄位中設定撰寫文字時，IME 可以使用
TextAttribute.Builder.setTextSuggestionSelected()指出是否已選取特定轉換候選字。具有編輯欄位的應用程式：維護自訂
InputConnection的應用程式可以呼叫TextAttribute.isTextSuggestionSelected()擷取候選字詞選取資料。這類應用程式應在調度TYPE_VIEW_TEXT_CHANGED事件時呼叫AccessibilityEvent.setTextChangeTypes()。如果應用程式指定 Android 17 (API 級別 37) 為目標，並使用標準TextView，則預設會啟用這項功能。(也就是說，TextView會處理從 IME 擷取資料，並在傳送事件至無障礙服務時設定文字變更類型)。無障礙服務：處理
TYPE_VIEW_TEXT_CHANGED事件的無障礙服務可以呼叫AccessibilityEvent.getTextChangeTypes()，以識別修改的性質並相應調整其回饋策略。
隱私權
Android 17 包含下列異動，可提升使用者隱私。
已啟用 ECH (Encrypted Client Hello)
Android 17 導入了對加密用戶端 Hello (ECH) 的平台支援，這是一種 TLS 擴充功能，可加密 TLS 握手程序中的伺服器名稱指示 (SNI)，進而強化使用者隱私。這項加密功能可防止網路觀察者輕易識別應用程式連線的特定網域。
如果應用程式指定 Android 17 (API 級別 37) 以上版本，則會使用 ECH 建立 TLS 連線。只有在應用程式使用的網路程式庫 (例如 HttpEngine、WebView 或 OkHttp) 整合 ECH 支援，且遠端伺服器也支援 ECH 通訊協定時，ECH 才會啟用。如果無法協商 ECH，用戶端會傳送含有隨機內容的 ECH 擴充功能 (這項機制稱為 ECH GREASE)。如要進一步瞭解 ECH GREASE 的運作方式，請參閱 RFC 9849。
為了讓應用程式自訂這項行為，Android 17 在網路安全性設定檔中新增了 <domainEncryption> 元素。開發人員可以在 <base-config> 或 <domain-config> 標記中使用 <domainEncryption>，在全域或個別網域層級選取 ECH 模式 (例如 "enabled" 或 "disabled")。
詳情請參閱加密用戶端 Hello 說明文件。
指定 Android 17 的應用程式需要區域網路權限
Android 17 推出 ACCESS_LOCAL_NETWORK 執行階段權限，保護使用者免受未經授權的區域網路存取。由於這屬於現有的 NEARBY_DEVICES 權限群組，因此已授予其他 NEARBY_DEVICES 權限的使用者不會再次收到提示。這項新規定可防止惡意應用程式利用不受限制的區域網路存取權，暗中追蹤使用者及收集數位指紋。只要宣告並要求這項權限，應用程式就能探索及連線至區域網路 (LAN) 上的裝置，例如智慧住宅裝置或投放接收器。
如果應用程式指定 Android 17 (API 級別 37) 以上版本，現在有兩種方式可與區域網路裝置保持通訊：採用系統中介、隱私權保護的裝置挑選器，略過權限提示，或在執行階段明確要求這項新權限，以維持區域網路通訊。
詳情請參閱區域網路權限說明文件。
在實體裝置上隱藏密碼
如果應用程式指定 Android 17 (API 級別 37) 以上版本，且使用者使用實體輸入裝置 (例如外接鍵盤)，Android 作業系統會將新的 show_passwords_physical 設定套用至密碼欄位中的所有字元。根據預設，這項設定會隱藏所有密碼字元。
Android 系統會顯示最後輸入的密碼字元，協助使用者確認是否輸入錯誤。不過，如果使用較大的外接鍵盤，就不太需要這麼做。此外，配備外接鍵盤的裝置通常螢幕較大，因此輸入的密碼更容易被他人看到。
如果使用者正在使用裝置的觸控螢幕，系統會套用新的 show_passwords_touch 設定。
標準簡訊動態密碼防護
從 Android 17 開始，Android 將擴大簡訊動態密碼保護功能，適用於標準簡訊 (包含動態密碼，但不使用 WebOTP 或簡訊擷取器格式的簡訊)。對於大多數指定 Android 17 (API 級別 37) 以上版本的應用程式，這些簡訊在收到後三小時內無法使用。這項延遲措施旨在防止動態密碼遭劫持。在這三小時的延遲期間，系統會保留 SMS_RECEIVED_ACTION 廣播，並篩選簡訊供應商資料庫查詢。延遲時間過後，這些應用程式就能取得簡訊。
某些應用程式 (例如預設簡訊小幫手應用程式、連結裝置隨附應用程式等) 不受這項延遲限制。所有需要讀取簡訊來擷取動態密碼的應用程式，都應改用 SMS Retriever 或 SMS User Consent API，確保功能持續運作。
安全性
Android 17 對裝置和應用程式安全性進行了以下改善。
Activity 安全性
在 Android 17 中，平台持續朝向「預設安全」架構發展，推出一系列強化功能，旨在緩解高嚴重性漏洞，例如網路釣魚、互動劫持和混淆代理攻擊。開發人員必須明確選擇加入新的安全性標準，才能維持應用程式相容性並保護使用者。
對開發人員的主要影響包括：
- 強化 BAL 並改善選擇加入機制：我們正在調整背景活動啟動 (BAL) 限制，將保護措施擴展至
IntentSender。開發人員必須停止使用舊版MODE_BACKGROUND_ACTIVITY_START_ALLOWED常數。建議改用MODE_BACKGROUND_ACTIVITY_START_ALLOW_IF_VISIBLE等精細控制項，限制只有在呼叫端應用程式可見時，才能啟動活動，大幅縮小攻擊面。 - 採用工具：開發人員應使用嚴格模式和更新後的 Lint 檢查，找出舊版模式，確保能因應未來的目標 SDK 規定。
預設啟用 CT
如果應用程式指定 Android 17 (API 級別 37) 以上版本，系統會預設啟用憑證透明化 (CT)。(在 Android 16 中，CT 可用，但應用程式必須選擇加入)。
更安全的原生 DCL - C
如果應用程式指定 Android 17 (API 級別 37) 以上版本，則 Android 14 針對 DEX 和 JAR 檔案推出的更安全動態程式碼載入 (DCL) 保護措施，現在也適用於原生程式庫。
使用 System.load() 載入的所有原生檔案都必須標示為唯讀。否則系統會擲回 UnsatisfiedLinkError。
我們建議應用程式盡量避免使用動態載入程式碼，否則應用程式很可能會因為程式碼插入或竄改程式碼而無法正常運作。
限制 CP2 資料檢視中的 PII 欄位
如果應用程式指定 Android 17 (API 級別 37) 以上版本，聯絡人供應程式 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 包含下列媒體行為變更。
背景音訊強化
從 Android 17 開始，音訊架構會對背景音訊互動強制執行限制，包括音訊播放、音訊焦點要求和音量變更 API，確保這些變更是由使用者刻意啟動。
部分音訊限制適用於所有應用程式。不過，如果應用程式指定 Android 17 (API 級別 37)，限制會更嚴格。如果其中一個應用程式在背景執行時與音訊互動，則必須執行前景服務。此外，應用程式必須符合下列一或兩項規定：
- 前景服務必須具備使用期間 (WIU) 功能。
- 應用程式必須具備精確鬧鐘權限，並與
USAGE_ALARM音訊串流互動。
如需更多資訊 (包括緩解策略)，請參閱「背景音訊強化」。
裝置板型規格
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() 行為一致
如果應用程式指定 Android 17 (API 級別 37) 為目標版本，當通訊端關閉或連線中斷時，從 RFCOMM 型 BluetoothSocket 取得的 InputStream 的 read() 方法現在會傳回 -1。
這項異動可讓 RFCOMM 通訊端行為與 LE CoC 通訊端保持一致，並符合標準 InputStream.read() 說明文件，其中指出到達串流結尾時會傳回 -1。
如果應用程式僅依賴擷取 IOException 來中斷讀取迴圈，可能會受到這項異動影響，因此應更新 BluetoothSocket 讀取迴圈，明確檢查傳回值是否為 -1。這可確保遠端裝置中斷連線或通訊端關閉時，迴圈能正確終止。如需建議導入方式的範例，請參閱「傳輸藍牙資料」指南中的程式碼片段。