行為變更：指定 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 和视图指南。

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

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.

The predictive back-to-home animation.

The predictive cross-activity animation.

The predictive cross-task animation.

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，藉此覆寫預設行為的應用程式，

elegantTextHeight 行為如下：

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

elegantTextHeight 行為。

核心功能

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) 包含下列變更，適用於在大螢幕裝置上顯示的應用程式。

自動調整式版面配置

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

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

如果應用程式指定 Android 16 (API 級別 36)，則在最小寬度 >= 600dp 的螢幕上，不再適用螢幕方向、大小調整和顯示比例限制。無論顯示比例或使用者偏好的螢幕方向為何，應用程式都會填滿整個顯示視窗，且不會使用左右黑邊。

這項異動會導入新的標準平台行為。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 發布版本中指定目標 API 級別 37 時，這項設定將不適用。也就是說，如果應用程式指定目標 API 級別 37，系統會在至少 sw600dp 的螢幕上忽略螢幕方向、大小調整和顯示比例限制。

健康與健身

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 和前景服務類型：

• Wear OS 健康照護服務的 HEART_RATE_BPM
• Android Sensor Manager 的 Sensor.TYPE_HEART_RATE
• 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。

這些權限與保護 Health Connect (Android 健康、健身和保健資料儲存庫) 資料讀取權限的權限相同。

行動應用程式

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

重要事項： 如果未提供行動應用程式的理由，系統會撤銷權限。

連線能力

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

處理繫結遺失和加密變更的新意圖

As part of the Improved bond loss handling, Android 16 also introduces 2 new intents to provide apps with greater awareness of bond loss and encryption changes.

Apps targeting Android 16 can now:

• Receive an ACTION_KEY_MISSING intent when remote bond loss is detected, allowing them to provide more informative user feedback and take appropriate actions.
• Receive an ACTION_ENCRYPTION_CHANGE intent whenever encryption status of the link changes. This includes encryption status change, encryption algorithm change, and encryption key size change. Apps must consider the bond restored if the link is successfully encrypted upon receiving ACTION_ENCRYPTION_CHANGE intent later.

Adapting to varying OEM implementations

While Android 16 introduces these new intents, their implementation and broadcasting can vary across different device manufacturers (OEMs). To ensure your app provides a consistent and reliable experience across all devices, developers should design their bond loss handling to gracefully adapt to these potential variations.

We recommend the following app behaviors:

• If the ACTION_KEY_MISSING intent is broadcast:

  The ACL (Asynchronous Connection-Less) link will be disconnected by the system, but the bond information for the device will be retained (as described here).

  Your app should use this intent as the primary signal for bond loss detection and guiding the user to confirm the remote device is in range before initiating device forgetting or re-pairing.

  If a device disconnects after ACTION_KEY_MISSING is received, your app should be cautious about reconnecting, as the device may no longer be bonded with the system.

• If the ACTION_KEY_MISSING intent is NOT broadcast:

  The ACL link will remain connected, and the bond information for the device will be removed by the system, same to behavior in Android 15.

  In this scenario, your app should continue its existing bond loss handling mechanisms as in previous Android releases, to detect and manage bond loss events.

移除藍牙繫結的新方法

All apps targeting Android 16 are now able to unpair bluetooth devices using a public API in CompanionDeviceManager. If a companion device is being managed as a CDM association, then the app can trigger bluetooth bond removal by using the new removeBond(int) API on the associated device. The app can monitor the bond state changes by listening to the bluetooth device broadcast event ACTION_BOND_STATE_CHANGED.

安全性

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.

更安全的意圖

The Safer Intents feature is a multi-phase security initiative designed to improve the security of Android's intent resolution mechanism. The goal is to protect apps from malicious actions by adding checks during intent processing and filtering intents that don't meet specific criteria.

In Android 15 the feature focused on the sending app. Now with Android 16, control shifts to the receiving app, allowing developers to opt-in to strict intent resolution using their app manifest.

Two key changes are being implemented:

1. Explicit Intents Must Match the Target Component's Intent Filter: If an intent explicitly targets a component, it should match that component's intent filter.

2. Intents Without an Action Cannot Match any Intent Filter: Intents that don't have an action specified shouldn't be resolved to any intent filter.

These changes only apply when multiple apps are involved and don't affect intent handling within a single app.

Impact

The opt-in nature means that developers must explicitly enable it in their app manifest for it to take effect. As a result, the feature's impact will be limited to apps whose developers:

• Are aware of the Safer Intents feature and its benefits.
• Actively choose to incorporate stricter intent handling practices into their apps.

This opt-in approach minimizes the risk of breaking existing apps that may rely on the current less-secure intent resolution behavior.

While the initial impact in Android 16 may be limited, the Safer Intents initiative has a roadmap for broader impact in future Android releases. The plan is to eventually make strict intent resolution the default behavior.

The Safer Intents feature has the potential to significantly enhance the security of the Android ecosystem by making it more difficult for malicious apps to exploit vulnerabilities in the intent resolution mechanism.

However, the transition to opt-out and mandatory enforcement must be carefully managed to address potential compatibility issues with existing apps.

Implementation

Developers need to explicitly enable stricter intent matching using the intentMatchingFlags attribute in their app manifest. Here is an example where the feature is opt-in for the entire app, but disabled/opt-out on a receiver:

<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>

Note: The attribute can be specified on the <application> tag as well as at the component tags such as <activity>, <activity-alias>, <receiver>, <service>, <provider> and the attribute on the component can be used to override what's on the <application> tag

More on the supported flags:

Flag Name	Description
enforceIntentFilter	Enforces stricter matching for incoming intents
none	Disables all special matching rules for incoming intents. When specifying multiple flags, conflicting values are resolved by giving precedence to the "none" flag
allowNullAction	Relaxes the matching rules to allow intents without an action to match. This flag to be used in conjunction with "enforceIntentFilter" to achieve a specific behavior

Testing and Debugging

When the enforcement is active, apps should function correctly if the intent caller has properly populated the intent. However, blocked intents will trigger warning log messages like "Intent does not match component's intent filter:" and "Access blocked:" with the tag "PackageManager." This indicates a potential issue that could impact the app and requires attention.

Logcat filter:

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-9)。Arm 已在 r54p2 版本的 Documentation/ioctl-categories.rst 中提供 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，請回報錯誤，並指派給 [e-mail]。

常見問題

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

2. 是否必須變更原始設備製造商 (OEM) 程式碼集才能實作這項功能，還是新版 AOSP 預設會提供這項功能？根據預設，平台層級的變更會隨新的 AOSP 版本推出。如果供應商想套用這項變更，可以選擇在程式碼集中加入。

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

4. 這項異動會自動套用至所有市售 Pixel 裝置嗎？還是使用者需要手動切換設定才能套用？ 這項異動適用於所有使用 Mali GPU 的 Pixel 市售裝置 (Pixel 6-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) 包含下列隱私權異動。

區域網路權限

凡具備 INTERNET 權限的應用程式，都能存取 LAN 上的裝置。雖然應用程式可因此輕鬆連線到本機裝置，但也帶來隱私疑慮，例如建立使用者數位指紋，或成為推算位置資訊的依據。

區域網路保護措施專案旨在保護使用者隱私，因此會透過新的執行階段權限，限制對區域網路的存取。

發布計畫

這項異動將分兩階段實施，分別在 25Q2 和 26Q2。開發人員務必遵循 25Q2 的指引並提供意見回饋，因為這些保護措施將在日後的 Android 版本中強制執行。此外，他們需要按照下列指南，更新依賴隱含區域網路存取權的情境，並做好使用者拒絕和撤銷新權限的準備。

影響

目前，LNP 是選擇性功能，也就是說，只有選擇加入的應用程式會受到影響。選擇加入階段的目標是讓應用程式開發人員瞭解應用程式的哪些部分依賴隱含的區域網路存取權，以便為下一個版本做好權限防護準備。

如果應用程式使用下列項目存取使用者的區域網路，就會受到影響：

• 直接或透過程式庫使用區域網路位址上的原始通訊端 (例如 mDNS 或 SSDP 服務探索通訊協定)
• 使用存取區域網路的架構層級類別 (例如 NsdManager)

傳送至和來自區域網路位址的流量，需要區域網路存取權限。下表列出一些常見情況：

應用程式低層級網路作業	必須授予區域網路權限
建立傳出 TCP 連線	是
接受傳入的 TCP 連線	是
傳送 UDP 單點傳播、多點傳播、廣播	是
接收傳入的 UDP 單點傳播、多點傳播、廣播	是

這些限制是在網路堆疊深處實施，因此適用於「所有網路 API」。這包括在原生或代管程式碼中建立的通訊端、Cronet 和 OkHttp 等網路程式庫，以及在這些程式庫上實作的任何 API。如要解析區域網路上的服務 (即後置字串為 .local 的服務)，則需要區域網路權限。

注意： 如果流量來自需要區域網路存取權的 Android Webview，則會沿用主機應用程式的權限狀態

上述規則的例外狀況：

• 如果裝置的 DNS 伺服器位於區域網路，則往返該伺服器的流量 (通訊埠 53) 不需要區域網路存取權限。
• 如果應用程式使用輸出切換器做為應用程式內選擇器，就不需要區域網路權限 (2025 年第 4 季會提供更多指引)。

注意： 許多媒體投放情境都必須存取區域網路，因此會受到這項異動影響。不過，並非所有提供投放功能的應用程式都需要要求新權限。我們將在 25Q4 提供未來 API 和處理投放情境的指南。

開發人員指南 (選擇加入)

如要啟用區域網路限制，請按照下列步驟操作：

1. 將裝置刷寫至 25Q2 Beta 3 以上版本。
2. 安裝要測試的應用程式。

3. 在 ADB 中切換 Appcompat 旗標：

   adb shell am compat enable RESTRICT_LOCAL_NETWORK <package_name>
   

4. 重新啟動裝置

現在，應用程式對區域網路的存取權已受限，任何嘗試存取區域網路的行為都會導致通訊端錯誤。如果您使用的 API 會在應用程式程序外執行區域網路作業 (例如 NsdManager)，在選擇加入階段不會受到影響。

如要恢復存取權，請授予應用程式NEARBY_WIFI_DEVICES權限。

1. 確認應用程式在資訊清單中宣告 NEARBY_WIFI_DEVICES 權限。
2. 依序前往「設定」>「應用程式」> [應用程式名稱] >「權限」>「鄰近裝置」>「允許」。

注意： 在日後的 Android 版本中，這項功能將由「鄰近裝置」權限群組中的新權限保護

現在，應用程式應可重新存取區域網路，且所有情境都應能正常運作，就像在應用程式啟用這項功能之前一樣。

區域網路保護措施開始強制執行後，應用程式網路流量會受到以下影響。

權限	傳出 LAN 要求	傳出/傳入網際網路要求	傳入 LAN 要求
已授予	Works	Works	Works
未授予	凸槌影片	Works	凸槌影片

使用下列指令關閉 App-Compat 旗標

adb shell am compat disable RESTRICT_LOCAL_NETWORK <package_name>

錯誤

每當呼叫通訊端叫用傳送或傳送變體至區域網路位址時，系統會將這些限制引起的錯誤傳回給呼叫通訊端。

錯誤示例：

sendto failed: EPERM (Operation not permitted)

sendto failed: ECONNABORTED (Operation not permitted)

區域網路定義

這項專案中的區域網路是指使用具備廣播功能網路介面 (例如 Wi-Fi 或乙太網路) 的 IP 網路，但不包括行動網路 (WWAN) 或 VPN 連線。

下列網路視為區域網路：

IPv4：

• 169.254.0.0/16 // 連結本機
• 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：

• 連結至本機
• 直接連結的路徑
• Thread 等虛設常式網路
• 多子網路 (待定)

此外，多點傳播位址 (224.0.0.0/4、ff00::/8) 和 IPv4 廣播地址 (255.255.255.255) 都歸類為區域網路位址。

應用程式擁有的相片

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