和先前版本一樣，Android 17 也包含可能會影響應用程式的行為變更。以下行為變更僅適用於指定 Android 17 以上版本的應用程式。如果您的應用程式指定 Android 17 以上版本，建議您視情況修改應用程式，以支援這些行為。
此外，無論應用程式的 targetSdkVersion 為何，請務必查看對所有 Android 17 應用程式有影響的行為變更清單。
核心功能
Android 17 包含下列異動項目，這類變更會修改或擴充 Android 系統的各種核心功能。
MessageQueue 的新無鎖實作
Beginning with Android 17, apps targeting Android 17 (API level 37)
or higher receive a new lock-free implementation of
android.os.MessageQueue. The new implementation improves performance and
reduces missed frames, but may break clients that reflect on MessageQueue
private fields and methods.
For more information, including mitigation strategies, see MessageQueue behavior change guidance.
靜態最終欄位現在無法修改
Apps running on Android 17 or higher that target
Android 17 (API level 37) or higher cannot change static final fields. If
an app attempts to change a static final field by using reflection, it will
cause an IllegalAccessException. Attempting to modify one of these fields
through JNI APIs (such as SetStaticLongField()) will cause the app to crash.
無障礙設定
Android 17 進行下列變更，提升無障礙功能。
支援複雜 IME 實體鍵盤輸入的無障礙功能
這項功能引進新的 AccessibilityEvent 和 TextAttribute API，可強化中文、日文、韓文和越南文輸入的螢幕閱讀器語音回饋。CJKV 輸入法編輯器應用程式現在可以指出在文字撰寫期間是否已選取文字轉換候選字。含有編輯欄位的應用程式可以在傳送文字變更無障礙功能事件時，指定文字變更類型。舉例來說，應用程式可以指定文字在文字撰寫期間發生變更，或是文字變更是由提交作業所致。這樣一來，螢幕閱讀器等無障礙服務就能根據文字修改的性質，提供更精確的回饋。
應用程式採用數
輸入法編輯器應用程式：在編輯欄位中設定撰寫文字時，輸入法編輯器可以使用
TextAttribute.Builder.setTextSuggestionSelected()指出是否已選取特定轉換候選字。可編輯欄位的應用程式：維護自訂
InputConnection的應用程式可以呼叫TextAttribute.isTextSuggestionSelected()擷取候選人選取資料。這些應用程式應在分派TYPE_VIEW_TEXT_CHANGED事件時呼叫AccessibilityEvent.setTextChangeTypes()。如果應用程式以 Android 17 (API 級別 37) 為目標，並使用標準TextView，這項功能就會預設為啟用。(也就是說，TextView會處理從輸入法擷取資料，以及在將事件傳送至無障礙服務時設定文字變更類型)。無障礙服務：處理
TYPE_VIEW_TEXT_CHANGED事件的無障礙服務可以呼叫AccessibilityEvent.getTextChangeTypes()，判斷修改性質並相應調整意見回饋策略。
隱私權
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.
在實體裝置上隱藏密碼
如果應用程式指定 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.
安全性
Android 17 在裝置和應用程式安全性方面有以下改進。
活動安全性
Android 17 平台持續朝「預設安全」架構邁進，推出一系列強化功能，旨在防範網路釣魚、互動劫持和混淆副手攻擊等高嚴重性攻擊。這項更新要求開發人員明確選擇採用新的安全標準，以維持應用程式相容性並保護使用者。
對開發人員的主要影響包括：
- 強化 BAL 並改善啟用程序：我們將擴大保護範圍至
IntentSender，進一步完善背景活動啟動 (BAL) 限制。開發人員必須從舊版MODE_BACKGROUND_ACTIVITY_START_ALLOWED常數遷移。您應改為採用細微控制項，例如MODE_BACKGROUND_ACTIVITY_START_ALLOW_IF_VISIBLE，將活動啟動限制在呼叫應用程式可見的情況，大幅減少攻擊面。 - 採用工具：開發人員應使用嚴格模式和更新的 Lint 檢查，找出舊版模式，確保符合日後目標 SDK 的規定。
預設啟用 CT
如果應用程式指定 Android 17 (API 級別 37) 以上版本，系統預設會啟用憑證透明化 (CT)。(在 Android 16 上，CT 可供使用，但應用程式必須選擇加入)。
更安全的 Native 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) 以上版本，則聯絡人供應程式 2 (CP2) 會限制資料檢視畫面中的特定欄位，避免顯示個人識別資訊 (PII)。啟用這項變更後，系統會從資料檢視畫面中移除這些資料欄，以提升使用者隱私權。受限的資料欄包括：
如果應用程式使用 ContactsContract.Data 中的這些資料欄，可以改為透過與 RAW_CONTACT_ID 聯結，從 ContactsContract.RawContacts 中擷取資料。
在 CP2 中強制執行嚴格的 SQL 檢查
For apps targeting Android 17 (API level Android 17 (API level 37)) and
higher, Contacts Provider 2 (CP2) enforces strict SQL query validation when
the ContactsContract.Data table is accessed without
READ_CONTACTS permission.
With this change, if an app doesn't have READ_CONTACTS
permission, StrictColumns and
StrictGrammar options are set when querying
the ContactsContract.Data table. If a query
uses a pattern that isn't compatible with these, it will be
rejected and cause an exception to be thrown.
媒體
Android 17 包含下列媒體行為變更。
背景音訊強化
從 Android 17 開始，音訊架構會強制限制背景音訊互動，包括音訊播放、音訊焦點要求和音量變更 API，確保這些變更是由使用者刻意啟動。
所有應用程式都必須遵守部分音訊限制。不過，如果應用程式指定 Android 17 (API 級別 37)，限制會更加嚴格。如果這些應用程式在背景與音訊互動，就必須執行前景服務。此外，應用程式也必須符合下列一或多項規定：
- 前景服務必須具備「僅限使用期間」權限。
- 應用程式必須具備精確鬧鐘權限，並與
USAGE_ALARM音訊串流互動。
如需更多資訊 (包括緩解策略)，請參閱「背景音訊強化」。
裝置板型規格
Android 17 包含下列異動項目，可改善各種尺寸和板型規格裝置的使用者體驗。
平台 API 異動，可忽略大螢幕 (sw>=600dp) 的螢幕方向、大小調整和長寬比限制
We introduced Platform API changes in Android 16 to ignore orientation, aspect ratio, and resizability restrictions on large screens (sw >= 600dp) for apps targeting API level 36 or higher. Developers have the option to opt out of these changes with SDK 36, but this opt-out will no longer be available for apps that target Android 17 (API level 37) or higher.
For more information, see Restrictions on orientation and resizability are ignored.
連線能力
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.