動作の変更点: 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 を使用するようにアプリを更新するか、または アプリの <application> タグまたは <activity> タグで android:enableOnBackInvokedCallback 属性を false に設定して、一時的にオプトアウトします。AndroidManifest.xml ファイル。

Elegant font 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 システムのさまざまなコア機能を変更または拡張する以下の変更が含まれています。

固定レートの作業スケジュールの最適化

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）をターゲットとするアプリでは、最小幅が 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）では、健康とフィットネスに関するデータについて以下の変更が加えられています。

健康とフィットネスの権限

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
• Wear OS の ProtoLayout から heartRateAccuracy と heartRateBpm
• FOREGROUND_SERVICE_TYPE_HEALTH: BODY_SENSORS の代わりにそれぞれの android.permission.health 権限が必要な場合

アプリでこれらの API を使用する場合は、それぞれの粒度の細かい権限をリクエストする必要があります。

• 心拍数、血中酸素ウェルネス、皮膚温の使用中のモニタリングの場合: BODY_SENSORS ではなく、READ_HEART_RATE など、android.permissions.health の下で詳細な権限をリクエストします。
• バックグラウンド センサー アクセスの場合: BODY_SENSORS_BACKGROUND ではなく READ_HEALTH_DATA_IN_BACKGROUND をリクエストします。

これらの権限は、健康、フィットネス、ウェルネスのデータ用の Android データストアである ヘルスコネクト からのデータ読み取りへのアクセスを保護する権限と同じです。

モバイルアプリ

READ_HEART_RATE やその他のきめ細かい権限を使用するように移行するモバイルアプリは、アプリのプライバシー ポリシーを表示するためにアクティビティを宣言する必要もあります。これはヘルスコネクトと同じ要件です。

接続

Android 16（API レベル 36）では、周辺機器との接続性を改善するために、Bluetooth スタックに次の変更が加えられています。

ボンドの損失と暗号化の変更を処理する新しいインテント

ボンドの損失処理の改善の一環として、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 リリースと同様に既存のボンディング損失処理メカニズムを継続して、ボンディング損失イベントを検出して管理する必要があります。

Bluetooth のペア設定を削除する新しい方法

Android 16 をターゲットとするすべてのアプリで、CompanionDeviceManager の公開 API を使用して Bluetooth デバイスのペア設定を解除できるようになりました。コンパニオン デバイスが CDM の関連付けとして管理されている場合、アプリは、関連付けられたデバイスで新しい removeBond(int) API を使用して、Bluetooth の接続解除をトリガーできます。アプリは、Bluetooth デバイスのブロードキャスト イベント 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.

Safer Intents

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, shifts control 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>

More on the supported flags:

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 システムコール フィルタリング

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）では、プライバシーが次のように変更されています。

ローカル ネットワークへのアクセス権

LAN 上のデバイスには、INTERNET 権限を持つすべてのアプリからアクセスできます。 これにより、アプリはローカル デバイスに簡単に接続できますが、ユーザーのフィンガープリントの作成や位置情報のプロキシなど、プライバシーへの影響もあります。

ローカル ネットワーク保護プロジェクトは、新しい実行時の権限の背後でローカル ネットワークへのアクセスをゲートすることで、ユーザーのプライバシーを保護することを目的としています。

リリース計画

この変更は、25Q2 と 26Q2 の 2 つのリリースに分けてデプロイされます。 デベロッパーは、25Q2 のガイダンスに沿ってフィードバックを共有する必要があります。これらの保護は今後の Android リリースで適用される ためです。 また、以下のガイダンスに沿って、暗黙的なローカル ネットワーク アクセスに依存するシナリオを更新し、新しい権限のユーザーによる拒否と取り消しに備える必要があります。

影響

現時点では、LNP はオプトイン機能であるため、オプトインしたアプリのみが影響を受けます。オプトイン フェーズの目的は、アプリ デベロッパーがアプリのどの部分が暗黙的なローカル ネットワーク アクセスに依存しているかを把握し、次のリリースで権限を保護できるようにすることです。

アプリが次の方法でユーザーのローカル ネットワークにアクセスする場合、アプリは影響を受けます。

• ローカル ネットワーク アドレスでのローソケットの直接使用またはライブラリの使用（mDNS や SSDP サービス ディスカバリ プロトコルなど）
• ローカル ネットワークにアクセスするフレームワーク レベルのクラスの使用（NsdManager など）

ローカル ネットワーク アドレスとの間のトラフィックには、ローカル ネットワーク アクセス権限が必要です。次の表に、一般的なケースを示します。

これらの制限はネットワーク スタックの奥深くに実装されているため、すべてのネットワーク API に適用されます。これには、ネイティブ コードまたはマネージド コードで作成されたソケット、Cronet や OkHttp などのネットワーク ライブラリ、それらの上に実装された API が含まれます。ローカル ネットワーク上のサービス（.local サフィックスが付いたサービス）を解決するには、ローカル ネットワーク権限が必要です。

上記のルールの例外:

• デバイスの DNS サーバーがローカル ネットワーク上にある場合、そのサーバーとの間のトラフィック（ポート 53）にはローカル ネットワーク アクセス権限は必要ありません。
• アプリ内ピッカーとして出力スイッチャーを使用するアプリには、ローカル ネットワーク権限は必要ありません（詳細なガイダンスは 2025 年第 4 四半期に提供されます）。

デベロッパー向けガイダンス（オプトイン）

ローカル ネットワーク制限をオプトインする手順は次のとおりです。

1. デバイスを 25Q2 ベータ版 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. [設定] > [アプリ] > [アプリ名] > [権限] > [付近のデバイス] > [許可] に移動します。

これで、アプリのローカル ネットワークへのアクセスが復元され、アプリをオプトインする前と同じようにすべてのシナリオが機能するようになります。

ローカル ネットワーク保護の適用が開始されると、アプリのネットワーク トラフィックは次のように影響を受けます。

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）はどちらもローカル ネットワーク アドレスとして分類されます。

アプリ所有の写真

Android 16 以降を搭載したデバイスで、SDK 36 以降をターゲットとするアプリから写真と動画の権限を求めるメッセージが表示された場合、選択したメディアへのアクセスを制限することを選択したユーザーには、アプリが所有する写真が写真選択ツールで事前選択された状態で表示されます。ユーザーは、これらの事前選択された項目の選択を解除できます。これにより、それらの写真と動画へのアプリのアクセス権が取り消されます。