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

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

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

使用者體驗和系統 UI

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 中進行測試，請確保應用程式支援無邊框設計，並移除所有 R.attr#windowOptOutEdgeToEdgeEnforcement 的使用情形，讓應用程式在 Android 15 裝置上也能支援無邊框設計。如要支援無邊框設計，請參閱 Compose 和 Views 指南。

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

如果應用程式指定 Android 16 (API 級別 36) 以上版本，且在搭載 Android 16 以上版本的裝置上執行，系統會預設啟用預測返回系統動畫 (返回首頁、跨工作和跨活動)。此外，系統不會再呼叫 onBackPressed，也不會再分派 KeyEvent.KEYCODE_BACK。

如果應用程式會攔截返回事件，且您尚未遷移至預測返回手勢，請更新應用程式以使用支援的返回導覽 API，或在應用程式 AndroidManifest.xml 檔案的 <application> 或 <activity> 標記中，將 android:enableOnBackInvokedCallback 屬性設為 false，暫時停用這項功能。

已淘汰並停用 Elegant 字型 API

指定 Android 15 (API 級別 35) 的應用程式會預設將 elegantTextHeight TextView 屬性設為 true，以更易於閱讀的字型取代精簡字型。您可以將 elegantTextHeight 屬性設為 false，藉此覆寫這項設定。

Android 16 會淘汰 elegantTextHeight 屬性，應用程式指定 Android 16 後，系統就會忽略該屬性。這些 API 控制的「UI 字型」即將停用，因此請調整所有版面配置，確保阿拉伯文、寮文、緬甸文、泰米爾文、古吉拉特文、卡納達文、馬拉雅拉姆文、奧里亞文、泰盧固文或泰文的文字顯示方式一致，且日後不會出錯。

針對指定 Android 14 (API 級別 34) 以下版本的應用程式，或指定 Android 15 (API 級別 35) 但將 elegantTextHeight 屬性設為 false，藉此覆寫預設行為的應用程式，

如果應用程式指定 Android 16 (API 級別 36)，或指定 Android 15 (API 級別 35) 但未將 elegantTextHeight 屬性設為 false 來覆寫預設值，則會採用

核心功能

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

固定費率工作排程最佳化

Prior to targeting Android 16, when scheduleAtFixedRate missed a task execution due to being outside a valid process lifecycle, all missed executions immediately execute when the app returns to a valid lifecycle.

When targeting Android 16, at most one missed execution of scheduleAtFixedRate is immediately executed when the app returns to a valid lifecycle. This behavior change is expected to improve app performance. Test this behavior in your app to check if your app is impacted. You can also test by using the app compatibility framework and enabling the STPE_SKIP_MULTIPLE_MISSED_PERIODIC_TASKS compat flag.

裝置板型規格

在大型螢幕裝置上顯示時，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) 包含下列與健康和健身資料相關的變更。

健康與健身權限

如果應用程式是以 Android 16 (API 級別 36) 以上版本為目標，BODY_SENSORS 權限會使用 android.permissions.health 底下更精細的權限，健康資料同步也會使用這些權限。自 Android 16 起，凡是先前需要 BODY_SENSORS 或 BODY_SENSORS_BACKGROUND 的 API，現在都需要對應的 android.permissions.health 權限。這會影響下列資料類型、API 和前景服務類型：

• HEART_RATE_BPM 從 Wear OS 上的健康照護服務
• Sensor.TYPE_HEART_RATE (來自 Android 感應器管理員)
• heartRateAccuracy 和 heartRateBpm 從 Wear OS 上的 ProtoLayout 移除
• FOREGROUND_SERVICE_TYPE_HEALTH，必須使用相應的 android.permission.health 權限，而非 BODY_SENSORS

如果應用程式使用這些 API，就應要求對應的精細權限：

• 如要監控使用中的心率、血氧濃度或皮膚溫度： 請要求 android.permissions.health 下的精細權限，例如 READ_HEART_RATE，而非 BODY_SENSORS。
• 如要存取背景感應器，請要求 READ_HEALTH_DATA_IN_BACKGROUND，而非 BODY_SENSORS_BACKGROUND。

這些權限與保護「健康資料同步」資料讀取權限相同，後者是 Android 的健康、健身和保健資料儲存空間。

行動應用程式

如果行動應用程式改用 READ_HEART_RATE 和其他細部權限，也必須宣告活動，才能顯示應用程式的隱私權政策。這與健康資料同步的規定相同。

連線能力

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 系統呼叫篩選

To harden the Mali GPU surface, Mali GPU IOCTLs that have been deprecated or are intended solely for GPU development have been blocked in production builds. Additionally, IOCTLs used for GPU profiling have been restricted to the shell process or debuggable applications. Refer to the SAC update for more details on the platform-level policy.

This change takes place on Pixel devices using the Mali GPU (Pixel 6-9). Arm has provided official categorization of their IOCTLs in Documentation/ioctl-categories.rst of their r54p2 release. This list will continue to be maintained in future driver releases.

This change does not impact supported graphics APIs (including Vulkan and OpenGL), and is not expected to impact developers or existing applications. GPU profiling tools such as the Streamline Performance Analyzer and the Android GPU Inspector won't be affected.

Testing

If you see a SELinux denial similar to the following, it is likely your application has been impacted by this change:

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

If your application needs to use blocked IOCTLs, please file a bug and assign it to android-partner-security@google.com.

FAQ

1. Does this policy change apply to all OEMs? This change will be opt-in, but available to any OEMs who would like to use this hardening method. Instructions for implementing the change can be found in the implementation documentation.

2. Is it mandatory to make changes in the OEM codebase to implement this, or does it come with a new AOSP release by default? The platform-level change will come with a new AOSP release by default. Vendors may opt-in to this change in their codebase if they would like to apply it.

3. Are SoCs responsible for keeping the IOCTL list up to date? For example, if my device uses an ARM Mali GPU, would I need to reach out to ARM for any of the changes? Individual SoCs must update their IOCTL lists per device upon driver release. For example, ARM will update their published IOCTL list upon driver updates. However, OEMs should make sure that they incorporate the updates in their SEPolicy, and add any selected custom IOCTLs to the lists as needed.

4. Does this change apply to all Pixel in-market devices automatically, or is a user action required to toggle something to apply this change? This change applies to all Pixel in-market devices using the Mali GPU (Pixel 6-9). No user action is required to apply this change.

5. Will use of this policy impact the performance of the kernel driver? This policy was tested on the Mali GPU using GFXBench, and no measurable change to GPU performance was observed.

6. Is it necessary for the IOCTL list to align with the current userspace and kernel driver versions? Yes, the list of allowed IOCTLs must be synchronized with the IOCTLs supported by both the userspace and kernel drivers. If the IOCTLs in the user space or kernel driver are updated, the SEPolicy IOCTL list must be updated to match.

7. ARM has categorized IOCTLs as 'restricted' / 'instrumentation', but we want to use some of them in production use-cases, and/or deny others. Individual OEMs/SoCs are responsible for deciding on how to categorize the IOCTLs they use, based on the configuration of their userspace Mali libraries. ARM's list can be used to help decide on these, but each OEM/SoC's use-case may be different.

隱私權

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.