行為變更：指定 Android 16 以上版本的應用程式

透過集合功能整理內容 你可以依據偏好儲存及分類內容。

和先前版本一樣，Android 16 也包含可能會影響應用程式的行為變更。以下行為變更僅適用於指定 Android 16 以上版本的應用程式。如果您的應用程式指定 Android 16 以上版本，建議您視情況修改應用程式，以支援這些行為。

此外，無論應用程式的 targetSdkVersion 為何，請務必查看影響所有在 Android 16 上執行的應用程式行為變更清單。

使用者體驗和系統使用者介面

Android 16 (API 級別 36) 包含下列變更，旨在打造更一致、直覺的使用者體驗。

無邊框螢幕的選擇不採用功能即將停用

Android 15 針對以 Android 15 (API 級別 35) 為目標版本的應用程式強制執行邊到邊，但您的應用程式可以將 R.attr#windowOptOutEdgeToEdgeEnforcement 設為 true，即可選擇不採用。如果應用程式指定 Android 16 (API 級別 36) 為目標版本，R.attr#windowOptOutEdgeToEdgeEnforcement 已淘汰並停用，且應用程式無法選擇不採用全螢幕模式。

• 如果應用程式指定 Android 16 (API 級別 36) 版本為目標，且在搭載 Android 15 的裝置上執行，R.attr#windowOptOutEdgeToEdgeEnforcement 仍會繼續運作。
• 如果應用程式指定 Android 16 (API 級別 36) 為目標版本，且在 Android 16 裝置上執行，R.attr#windowOptOutEdgeToEdgeEnforcement 就會停用。

如要在 Android 16 Beta 3 中進行測試，請確認您的應用程式支援無邊框設計，並移除任何 R.attr#windowOptOutEdgeToEdgeEnforcement 用途，以便應用程式在 Android 15 裝置上也支援無邊框設計。如要支援邊到邊，請參閱 Compose 和 Views 指南。

必須遷移或選擇不採用預測返回功能

For apps targeting Android 16 (API level 36) or higher and running on an Android 16 or higher device, the predictive back system animations (back-to-home, cross-task, and cross-activity) are enabled by default. Additionally, onBackPressed is not called and KeyEvent.KEYCODE_BACK is not dispatched anymore.

If your app intercepts the back event and you haven't migrated to predictive back yet, update your app to use supported back navigation APIs. or temporarily opt out by setting the android:enableOnBackInvokedCallback attribute to false in the <application> or <activity> tag of your app's AndroidManifest.xml file.

Elegant 字型 API 已淘汰並停用

Apps targeting Android 15 (API level 35) have the elegantTextHeight TextView attribute set to true by default, replacing the compact font with one that is much more readable. You could override this by setting the elegantTextHeight attribute to false.

Android 16 deprecates the elegantTextHeight attribute, and the attribute will be ignored once your app targets Android 16. The "UI fonts" controlled by these APIs are being discontinued, so you should adapt any layouts to ensure consistent and future proof text rendering in Arabic, Lao, Myanmar, Tamil, Gujarati, Kannada, Malayalam, Odia, Telugu or Thai.

核心功能

Android 16 (API 級別 36) 包含下列變更，可修改或擴充 Android 系統的各種核心功能。

固定費率工作排程最佳化

在指定 Android 16 之前，如果 scheduleAtFixedRate 因不在有效的程序生命週期中而錯過執行工作，則應用程式返回有效生命週期時，所有錯過的執行作業會立即執行。

針對 Android 16 進行指定時，應用程式返回有效生命週期時，最多會立即執行 一次遺漏的 scheduleAtFixedRate 執行作業。這項行為異動預計可改善應用程式效能。在應用程式中測試這項行為，確認應用程式是否受到影響。您也可以使用應用程式相容性架構，並啟用 STPE_SKIP_MULTIPLE_MISSED_PERIODIC_TASKS 相容性標記來進行測試。

裝置板型規格

Android 16 (API 級別 36) 針對在大型螢幕裝置上顯示的應用程式，包含下列變更。

自動調整式版面配置

由於 Android 應用程式現在可在各種裝置 (例如手機、平板電腦、折疊式裝置、電腦、車輛和電視) 上執行，且可在大型螢幕上使用視窗模式 (例如分割畫面和電腦視窗模式)，因此開發人員應建構可在任何螢幕和視窗大小下運作的 Android 應用程式，無論裝置方向為何皆可。在現今的多裝置世界中，限制螢幕方向和大小調整等模式過於嚴苛。

忽略螢幕方向、是否可調整大小和顯示比例限制

如果應用程式指定 Android 16 (API 級別 36)，Android 16 會針對系統管理方向、大小調整和顯示比例限制的方式進行變更。在最小寬度大於等於 600 dp 的螢幕上，系統不再套用這些限制。無論顯示比例或使用者偏好的螢幕方向為何，應用程式都會填滿整個顯示視窗，且不會使用上下黑邊。

這項變更會引入新的標準平台行為。Android 正朝向新模型邁進，應用程式應能根據各種方向、螢幕大小和顯示比例自動調整。固定螢幕方向或限制尺寸調整功能等限制會影響應用程式的適應性，因此建議讓應用程式具備適應性，以便提供最佳使用者體驗。

您也可以使用應用程式相容性架構並啟用 UNIVERSAL_RESIZABLE_BY_DEFAULT 相容性標記，來測試這項行為。

常見的破壞性變更

忽略方向、可調整大小和顯示比例限制，可能會影響某些裝置上的應用程式 UI，尤其是針對鎖定為直向的較小版面配置設計的元素：例如，經過拉伸的版面配置和畫面外動畫和元件等問題。任何有關顯示比例或方向的假設都可能導致應用程式出現視覺問題。請參閱這篇文章，進一步瞭解如何避免這些問題，並改善應用程式的自適應行為。

允許裝置旋轉會導致更多活動重建，如果未妥善保留，可能會導致使用者狀態遺失。如要瞭解如何正確儲存 UI 狀態，請參閱「儲存 UI 狀態」。

導入作業詳細資料

在全螢幕和多視窗模式下，系統會忽略大型螢幕裝置的下列資訊清單屬性和執行階段 API：

• screenOrientation
• resizableActivity
• minAspectRatio
• maxAspectRatio
• setRequestedOrientation()
• getRequestedOrientation()

系統會忽略 screenOrientation、setRequestedOrientation() 和 getRequestedOrientation() 的下列值：

• portrait
• reversePortrait
• sensorPortrait
• userPortrait
• landscape
• reverseLandscape
• sensorLandscape
• userLandscape

就螢幕可調整大小而言，android:resizeableActivity="false"、android:minAspectRatio 和 android:maxAspectRatio 都沒有任何影響。

針對以 Android 16 (API 級別 36) 為目標的應用程式，系統預設會忽略應用程式方向、大小調整和顯示比例限制，但所有尚未完全就緒的應用程式都可以選擇暫時覆寫這項行為 (這會導致系統將應用程式置於相容性模式，而導致先前的行為)。

例外狀況

在下列情況下，Android 16 的方向、大小調整和顯示比例限制不適用：

• 遊戲 (根據 android:appCategory 標記)
• 使用者在裝置的顯示比例設定中，明確選擇啟用應用程式的預設行為
• 螢幕大小小於 sw600dp

暫時退出

如要選擇不顯示特定活動，請宣告 PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY 資訊清單屬性：

<activity ...>
  <property android:name="android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY" android:value="true" />
  ...
</activity>

如果應用程式有太多部分尚未準備好支援 Android 16，您可以在應用程式層級套用相同的屬性，完全選擇拒絕：

<application ...>
  <property android:name="android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY" android:value="true" />
</application>

健康與健身

Android 16 (API 級別 36) 包含下列與健康與健身資料相關的變更。

健康與健身權限

For apps targeting Android 16 (API level 36) or higher, BODY_SENSORS permissions are transitioning to the granular permissions under android.permissions.health also used by Health Connect. Any API previously requiring BODY_SENSORS or BODY_SENSORS_BACKGROUND now requires the corresponding android.permissions.health permission. This affects the following data types, APIs, and foreground service types:

• HEART_RATE_BPM from Wear Health Services
• Sensor.TYPE_HEART_RATE from Android Sensor Manager
• heartRateAccuracy and heartRateBpm from Wear ProtoLayout
• FOREGROUND_SERVICE_TYPE_HEALTH where the respective android.permission.health permission is needed in place of BODY_SENSORS

If your app uses these APIs, it should now request the respective granular permissions:

• For while-in-use monitoring of Heart Rate, SpO2, or Skin Temperature: request the granular permission under android.permissions.health, such as READ_HEART_RATE instead of BODY_SENSORS.
• For background sensor access: request READ_HEALTH_DATA_IN_BACKGROUND instead of BODY_SENSORS_BACKGROUND.

These permissions are the same as those that guard access to reading data from Health Connect, the Android datastore for health, fitness, and wellness data.

Mobile apps

Mobile apps migrating to use the READ_HEART_RATE and other granular permissions must also declare an activity to display the app's privacy policy. This is the same requirement as Health Connect.

連線能力

Android 16 (API 級別 36) 的藍牙堆疊包含下列變更，可改善與周邊裝置的連線能力。

處理失效連結和加密變更的新意圖

為了改善連結遺失處理機制，Android 16 也推出了 2 個新的意圖，讓應用程式更能察覺連結遺失和加密變更。

鎖定 Android 16 的應用程式現在可以：

• 在偵測到遠端連結遺失時接收 ACTION_KEY_MISSING 意圖，以便提供更實用的使用者意見回饋，並採取適當行動。
• 每當連結的加密狀態變更時，就會收到 ACTION_ENCRYPTION_CHANGE 意圖。包括加密狀態變更、加密演算法變更和加密金鑰大小變更。如果應用程式稍後收到 ACTION_ENCRYPTION_CHANGE 意圖，且連結已成功加密，則必須考慮恢復連結。

如果您的應用程式目前使用自訂機制處理連結遺失問題，請改用新的意圖 ACTION_KEY_MISSING 來偵測及管理連結遺失事件。建議您在應用程式中引導使用者確認遠端裝置是否在範圍內，再開始忘記裝置和重新配對。

此外，如果裝置在收到 ACTION_KEY_MISSING 意圖後中斷連線，您的應用程式應注意重新連線至裝置，因為該裝置可能不再與系統綁定。

安全性

Android 16 (API 級別 36) 包含下列安全性變更。

MediaStore 版本鎖定

For apps targeting Android 16 or higher, MediaStore#getVersion() will now be unique to each app. This eliminates identifying properties from the version string to prevent abuse and usage for fingerprinting techniques. Apps shouldn't make any assumptions around the format of this version. Apps should already handle version changes when using this API and in most cases shouldn't need to change their current behavior, unless the developer has attempted to infer additional information that is beyond the intended scope of this API.

更安全的意圖

Safer Intents 功能是一項多階段安全性計畫，旨在改善 Android 意圖解析機制的安全性。目的是在意圖處理期間加入檢查，並篩除不符合特定條件的意圖，藉此保護應用程式免受惡意行為影響。

在 Android 15 中，這項功能著重於傳送應用程式，但在 Android 16 中，這項功能會將控制權轉移至接收應用程式，讓開發人員可以使用應用程式資訊清單選擇啟用嚴格的意圖解析。

我們正在實施兩項重大變更：

1. 明確意圖必須符合目標元件意圖篩選器：如果意圖明確指定元件，則應符合該元件意圖篩選器。

2. 沒有動作的意圖無法與任何意圖篩選器相符：沒有指定動作的意圖不應解析至任何意圖篩選器。

這些變更僅適用於涉及多個應用程式的情況，不會影響單一應用程式中的意圖處理作業。

影響

選擇採用的性質表示開發人員必須在應用程式資訊清單中明確啟用這項功能，才能生效。因此，這項功能只會影響開發人員符合下列條件的應用程式：

• 瞭解 Safer Intents 功能及其優點。
• 主動選擇在應用程式中納入更嚴格的意圖處理做法。

這種選擇加入方式可降低破壞現有應用程式的風險，因為這些應用程式可能會依賴目前較不安全的意圖解析行為。

雖然 Android 16 的初始影響可能有限，但 Safer Intents 計畫有發展藍圖，可在未來的 Android 版本中帶來更廣泛的影響。我們最終的計畫是將嚴格意圖解析設為預設行為。

安全意圖功能可大幅提升 Android 生態系統的安全性，因為惡意應用程式將難以利用意圖解析機制中的安全漏洞。

不過，您必須謹慎管理轉換至選擇停用和強制執行的過程，以便解決現有應用程式可能發生的相容性問題。

實作

開發人員必須在應用程式資訊清單中使用 intentMatchingFlags 屬性，明確啟用更嚴格的意圖比對功能。以下是整個應用程式為自選功能，但在接收器上停用/選擇停用的範例：

<application android:intentMatchingFlags="enforceIntentFilter">
    <receiver android:name=".MyBroadcastReceiver" android:exported="true" android:intentMatchingFlags="none">
        <intent-filter>
            <action android:name="com.example.MY_CUSTOM_ACTION" />
        </intent-filter>
        <intent-filter>
            <action android:name="com.example.MY_ANOTHER_CUSTOM_ACTION" />
        </intent-filter>
    </receiver>
</application>

進一步瞭解支援的標記：

測試和偵錯

在啟用強制執行功能後，如果意圖呼叫端已正確填入意圖，應用程式應可正常運作。不過，遭到封鎖的意圖會觸發警告記錄訊息，例如帶有標記 "PackageManager." 的 "Intent does not match component's intent filter:" 和 "Access blocked:"。這表示可能會影響應用程式的潛在問題，需要特別留意。

Logcat 篩選器：

tag=:PackageManager & (message:"Intent does not match component's intent filter:" | message: "Access blocked:")

隱私權

Android 16 (API 級別 36) 包含下列隱私權變更。

區域網路權限

Devices on the LAN can be accessed by any app that has the INTERNET permission. This makes it easy for apps to connect to local devices but it also has privacy implications such as forming a fingerprint of the user, and being a proxy for location.

The Local Network Protections project aims to protect the user's privacy by gating access to the local network behind a new runtime permission.

Release plan

This change will be deployed between two releases, 25Q2 and TBD respectively. It is imperative that developers follow this guidance for 25Q2 and share feedback because these protections will be enforced at a later Android release. Moreover, they will need to update scenarios which depend on implicit local network access by using the following guidance and prepare for user rejection and revocation of the new permission.

Impact

At the current stage, LNP is an opt-in feature which means only the apps that opt in will be affected. The goal of the opt-in phase is for app developers to understand which parts of their app depend on implicit local network access such that they can prepare to permission guard them for the next release.

Apps will be affected if they access the user's local network using:

• Direct or library use of raw sockets on local network addresses (e.g. mDNS or SSDP service discovery protocol)
• Use of framework level classes that access the local network (e.g. NsdManager)

Traffic to and from a local network address requires local network access permission. The following table lists some common cases:

These restrictions are implemented deep in the networking stack, and thus they apply to all networking APIs. This includes sockets created in native or managed code, networking libraries like Cronet and OkHttp, and any APIs implemented on top of those. Trying to resolve services on the local network (i.e. those with a .local suffix) will require local network permission.

Exceptions to the rules above:

• If a device's DNS server is on a local network, traffic to or from it (at port 53) doesn't require local network access permission.
• Applications using Output Switcher as their in-app picker won't need local network permissions (more guidance to come in 2025Q4).

Developer Guidance (Opt-in)

To opt into local network restrictions, do the following:

1. Flash the device to a build with 25Q2 Beta 3 or later.
2. Install the app to be tested.

3. Toggle the Appcompat flag in adb:

   adb shell am compat enable RESTRICT_LOCAL_NETWORK <package_name>
   

4. Reboot The device

Now your app's access to the local network is restricted and any attempt to access the local network will lead to socket errors. If you are using APIs that perform local network operations outside of your app process (ex: NsdManager), they won't be impacted during the opt-in phase.

To restore access, you must grant your app permission to NEARBY_WIFI_DEVICES.

1. Ensure the app declares the NEARBY_WIFI_DEVICES permission in its manifest.
2. Go to Settings > Apps > [Application Name] > Permissions > Nearby devices > Allow.

Now your app's access to the local network should be restored and all your scenarios should work as they did prior to opting the app in.

Once enforcement for local network protection begins, here is how the app network traffic will be impacted.

Use the following command to toggle-off the App-Compat flag

adb shell am compat disable RESTRICT_LOCAL_NETWORK <package_name>

Errors

Errors arising from these restrictions will be returned to the calling socket whenever it invokes send or a send variant to a local network address.

Example errors:

sendto failed: EPERM (Operation not permitted)

sendto failed: ECONNABORTED (Operation not permitted)

Local Network Definition

A local network in this project refers to an IP network that utilizes a broadcast-capable network interface, such as Wi-Fi or Ethernet, but excludes cellular (WWAN) or VPN connections.

The following are considered local networks:

IPv4:

• 169.254.0.0/16 // Link Local
• 100.64.0.0/10 // CGNAT
• 10.0.0.0/8 // RFC1918
• 172.16.0.0/12 // RFC1918
• 192.168.0.0/16 // RFC1918

IPv6:

• Link-local
• Directly-connected routes
• Stub networks like Thread
• Multiple-subnets (TBD)

Additionally, both multicast addresses (224.0.0.0/4, ff00::/8) and the IPv4 broadcast address (255.255.255.255) are classified as local network addresses.

應用程式擁有的相片

當指定 SDK 36 以上版本的應用程式在搭載 Android 16 以上版本的裝置上執行時，如果系統提示使用者授予相片和影片權限，選擇限制所選媒體存取權的使用者會在相片挑選器中看到應用程式預先選取的所有相片。使用者可以取消選取任何預先選取的項目，這樣一來，應用程式就無法存取這些相片和影片。