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

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

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

使用者體驗和系統 UI

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

無邊框設計停用選項即將移除

Android 15 enforced edge-to-edge for apps targeting Android 15 (API level 35), but your app could opt-out by setting R.attr#windowOptOutEdgeToEdgeEnforcement to true. For apps targeting Android 16 (API level 36), R.attr#windowOptOutEdgeToEdgeEnforcement is deprecated and disabled, and your app can't opt-out of going edge-to-edge.

• If your app targets Android 16 (API level 36) and is running on an Android 15 device, R.attr#windowOptOutEdgeToEdgeEnforcement continues to work.
• If your app targets Android 16 (API level 36) and is running on an Android 16 device, R.attr#windowOptOutEdgeToEdgeEnforcement is disabled.

For testing in Android 16, ensure your app supports edge-to-edge and remove any use of R.attr#windowOptOutEdgeToEdgeEnforcement so that your app also supports edge-to-edge on an Android 15 device. To support edge-to-edge, see the Compose and Views guidance.

如要使用預測返回手勢，必須遷移或選擇停用

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) 會對應用程式進行下列變更。

自動調整式版面配置

With Android apps now running on a variety of devices (such as phones, tablets, foldables, desktops, cars, and TVs) and windowing modes on large screens (such as split screen and desktop windowing), developers should build Android apps that adapt to any screen and window size, regardless of device orientation. Paradigms like restricting orientation and resizability are too restrictive in today's multidevice world.

Ignore orientation, resizability, and aspect ratio restrictions

For apps targeting Android 16 (API level 36), orientation, resizability, and aspect ratio restrictions no longer apply on displays with smallest width >= 600dp. Apps fill the entire display window, regardless of aspect ratio or a user's preferred orientation, and pillarboxing isn't used.

This change introduces a new standard platform behavior. Android is moving toward a model where apps are expected to adapt to various orientations, display sizes, and aspect ratios. Restrictions like fixed orientation or limited resizability hinder app adaptability. Make your app adaptive to deliver the best possible user experience.

You can also test this behavior by using the app compatibility framework and enabling the UNIVERSAL_RESIZABLE_BY_DEFAULT compat flag.

Common breaking changes

Ignoring orientation, resizability, and aspect ratio restrictions might impact your app's UI on some devices, especially elements that were designed for small layouts locked in portrait orientation: for example, issues like stretched layouts and off-screen animations and components. Any assumptions about aspect ratio or orientation can cause visual issues with your app. Learn more about how to avoid them and improve your app's adaptive behaviour.

Allowing device rotation results in more activity re-creation, which can result in losing user state if not properly preserved. Learn how to correctly save UI state in Save UI states.

Implementation details

The following manifest attributes and runtime APIs are ignored across large screen devices in full-screen and multi-window modes:

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

The following values for screenOrientation, setRequestedOrientation(), and getRequestedOrientation() are ignored:

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

Regarding display resizability, android:resizeableActivity="false", android:minAspectRatio, and android:maxAspectRatio have no effect.

For apps targeting Android 16 (API level 36), app orientation, resizability, and aspect ratio constraints are ignored on large screens by default, but every app that isn't fully ready can temporarily override this behavior by opting out (which results in the previous behavior of being placed in compatibility mode).

Exceptions

The Android 16 orientation, resizability, and aspect ratio restrictions don't apply in the following situations:

• Games (based on the android:appCategory flag)
• Users explicitly opting in to the app's default behavior in aspect ratio settings of the device
• Screens that are smaller than sw600dp

Opt out temporarily

To opt out a specific activity, declare the PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY manifest property:

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

If too many parts of your app aren't ready for Android 16, you can opt out completely by applying the same property at the application level:

<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 use more granular permissions under android.permissions.health, which Health Connect also uses. As of Android 16, any API previously requiring BODY_SENSORS or BODY_SENSORS_BACKGROUND requires the corresponding android.permissions.health permission instead. This affects the following data types, APIs, and foreground service types:

• HEART_RATE_BPM from Health Services on Wear OS
• Sensor.TYPE_HEART_RATE from Android Sensor Manager
• heartRateAccuracy and heartRateBpm from ProtoLayout on Wear OS
• 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 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 意圖，且連結已成功加密，則必須考慮恢復連結。

因應不同原始設備製造商 (OEM) 實作

雖然 Android 16 推出了這些新意圖，但不同裝置製造商 (OEM) 的實作和廣播方式可能有所不同。為確保應用程式可在所有裝置上提供一致且可靠的體驗，開發人員應設計連結中斷處理機制，以便妥善因應這些潛在的變化。

我們建議您採用下列應用程式行為：

• 如果廣播 ACTION_KEY_MISSING 意圖：

  系統會中斷 ACL (非同步無連結) 連結，但會保留裝置的連結資訊 (如這裡所述)。

  應用程式應使用這個意圖做為偵測連結中斷的主要信號，並在啟動裝置忘記或重新配對功能前，引導使用者確認遠端裝置是否在範圍內。

  如果裝置在收到 ACTION_KEY_MISSING 後中斷連線，應用程式應謹慎重新連線，因為裝置可能已不再與系統綁定。

• 如果 ACTION_KEY_MISSING 意圖未廣播：

  ACL 連結會保持連線狀態，系統會移除裝置的連結資訊，這與 Android 15 的行為相同。

  在這種情況下，應用程式應繼續使用與先前 Android 版本相同的現有連結失效處理機制，以偵測及管理連結失效事件。

移除藍牙配對的新方式

所有以 Android 16 為目標版本的應用程式，現在都能使用 CompanionDeviceManager 中的公開 API 解除配對藍牙裝置。如果隨附裝置是以 CDM 關聯方式管理，應用程式可以在關聯裝置上使用新的 removeBond(int) API 觸發藍牙連結移除作業。應用程式可以監控連結狀態變更，方法是監聽藍牙裝置廣播事件 ACTION_BOND_STATE_CHANGED。

安全性

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

MediaStore 版本鎖定

針對指定 Android 16 以上版本的應用程式，MediaStore#getVersion() 現已成為每個應用程式的專屬值。這麼做可移除版本字串中的識別屬性，以免遭到濫用，並防止用於指紋辨識技術。應用程式不應對此版本的格式做出任何假設。應用程式在使用此 API 時應已處理版本變更，且在大多數情況下，不必變更目前的行為，除非開發人員嘗試推斷超出此 API 預期範圍的其他資訊。

更安全的意圖

「更安全的意圖」功能是一項多階段安全防護計畫，旨在提升 Android 意圖解析機制的安全性。目標是在意圖處理期間新增檢查，並篩除不符合特定條件的意圖，藉此保護應用程式免於惡意行為。

Android 15 的這項功能著重於傳送應用程式，現在 Android 16 則將控制權轉移至接收應用程式，讓開發人員使用應用程式資訊清單選擇加入嚴格的 Intent 解析。

我們將實施兩項重大變更：

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

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

這些變更只會在涉及多個應用程式時生效，不會影響單一應用程式內的意圖處理程序。

影響

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

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

這種選擇加入的做法可盡量避免現有應用程式中斷運作，因為這些應用程式可能依賴目前安全性較低的意圖解析行為。

雖然 Safer Intents 計畫在 Android 16 的初期影響可能有限，但我們已規劃好發展藍圖，未來將在 Android 版本中擴大影響力。我們最終會將嚴格意圖解析設為預設行為。

Safer Intents 功能可讓惡意應用程式更難以利用意圖解析機制中的漏洞，因此有助於大幅提升 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>

支援的旗標詳細資訊：

測試與偵錯

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

Logcat 篩選器：

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

GPU 系統呼叫篩選

為強化 Mali GPU 介面，我們已在正式版中封鎖已淘汰或僅供 GPU 開發使用的 Mali GPU IOCTL。此外，用於 GPU 分析的 IOCTL 已限制為僅供殼層程序或可偵錯的應用程式使用。如要進一步瞭解平台層級政策，請參閱 SAC 更新。

這項異動會影響使用 Mali GPU 的 Pixel 裝置 (Pixel 6 到 Pixel 9)。Arm 已在 Documentation/ioctl-categories.rst 的 r54p2 版本中，提供 IOCTL 的官方分類。我們會在日後發布的驅動程式版本中，持續維護這份清單。

這項異動不會影響支援的繪圖 API (包括 Vulkan 和 OpenGL)，預計也不會影響開發人員或現有應用程式。Streamline Performance Analyzer 和 Android GPU 檢查器等 GPU 剖析工具不會受到影響。

測試

如果看到類似以下的 SELinux 拒絕訊息，表示您的應用程式可能受到這項異動影響：

06-30 10:47:18.617 20360 20360 W roidJUnitRunner: type=1400 audit(0.0:85): avc:  denied  { ioctl }
for  path="/dev/mali0" dev="tmpfs" ino=1188 ioctlcmd=0x8023
scontext=u:r:untrusted_app_25:s0:c512,c768 tcontext=u:object_r:gpu_device:s0 tclass=chr_file
permissive=0 app=com.google.android.selinux.pts

如果應用程式需要使用遭封鎖的 IOCTL，請回報錯誤並指派給 android-partner-security@google.com。

常見問題

1. 這項政策異動是否適用於所有原始設備製造商？ 這項變更將採選擇加入制，但任何想使用這項強化方法的 OEM 都能選擇加入。如需實作變更的操作說明，請參閱實作說明文件。

2. 是否必須變更 OEM 程式碼集才能實作這項功能，還是預設會隨附於新的 AOSP 版本？ 根據預設，平台層級的變更會隨附於新的 Android 開放原始碼計畫版本。如要套用這項變更，供應商可以在程式碼集選擇啟用。

3. SoC 是否負責更新 IOCTL 清單？舉例來說，如果我的裝置使用 ARM Mali GPU，是否需要就任何變更與 ARM 聯絡？ 個別 SoC 必須在驅動程式發布後，依據裝置更新 IOCTL 清單。 舉例來說，ARM 會在驅動程式更新時，更新已發布的 IOCTL 清單。 不過，原始設備製造商應確保將更新納入 SEPolicy，並視需要將所選自訂 IOCTL 新增至清單。

4. 這項變更會自動套用至所有市售 Pixel 裝置嗎？還是使用者必須切換某些設定才能套用？ 這項異動適用於所有使用 Mali GPU 的 Pixel 上市裝置 (Pixel 6 至 Pixel 9)。這項異動會自動生效，您不必採取任何行動。

5. 使用這項政策會影響核心驅動程式的效能嗎？ 這項政策已在 Mali GPU 上使用 GFXBench 進行測試，結果顯示 GPU 效能沒有明顯變化。

6. IOCTL 清單是否必須與目前的使用者空間和核心驅動程式版本一致？ 是，允許的 IOCTL 清單必須與使用者空間和核心驅動程式支援的 IOCTL 同步。如果使用者空間或核心驅動程式中的 IOCTL 已更新，SEPolicy IOCTL 清單也必須更新，才能與之相符。

7. ARM 已將 IOCTL 分類為「受限」/「儀器」，但我們想在正式環境的使用案例中採用部分 IOCTL，並/或拒絕其他 IOCTL。 各個 OEM/SoC 負責根據使用者空間 Mali 程式庫的設定，決定如何分類所用的 IOCTL。ARM 的清單可協助您做出這些決定，但每個 OEM/SoC 的使用案例可能有所不同。

隱私權

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 26Q2 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.

應用程式擁有的相片

When prompted for photo and video permissions by an app targeting SDK 36 or higher on devices running Android 16 or higher, users who choose to limit access to selected media will see any photos owned by the app pre-selected in the photo picker. Users can deselect any of these pre-selected items, which will revoke the app's access to those photos and videos.