Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

動作の変更点: 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 フォント API のサポート終了と無効化

以 Android 15（API 级别 35）为目标平台的应用默认将 elegantTextHeight TextView 属性设置为 true，从而将紧凑型字体替换为可读性更高的字体。您可以通过将 elegantTextHeight 属性设置为 false 来替换此设置。

Android 16 弃用了 elegantTextHeight 属性，当您的应用以 Android 16 为目标平台后，系统会忽略该属性。由这些 API 控制的“界面字体”即将停用，因此您应调整所有布局，以确保阿拉伯语、老挝语、缅甸语、泰米尔语、古吉拉特语、卡纳达语、马拉雅拉姆语、奥里亚语、泰卢固语或泰语文本的呈现效果一致且不受未来变化的影响。

コア機能

Android 16（API レベル 36）には、Android システムのさまざまなコア機能を変更または拡張する以下の変更が含まれています。

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

Android 16 をターゲットとする前は、scheduleAtFixedRate が有効なプロセスライフサイクルの外部にあるためにタスクの実行を逃した場合、アプリが有効なライフサイクルに戻ると、逃した実行がすべて直ちに実行されました。

Android 16 をターゲットとしている場合、アプリが有効なライフサイクルに戻ると、scheduleAtFixedRate の実行が最大 1 回スキップされた場合、その実行が直ちに実行されます。この動作変更により、アプリのパフォーマンスが向上することが期待されます。アプリでこの動作をテストして、アプリが影響を受けているかどうかを確認します。アプリ互換性フレームワークを使用して STPE_SKIP_MULTIPLE_MISSED_PERIODIC_TASKS 互換性フラグを有効にしてテストすることもできます。

デバイスのフォームファクタ

Android 16（API レベル 36）では、大画面デバイスに表示されるアプリに対して次の変更が加えられています。

アダプティブレイアウト

Android アプリは、スマートフォン、タブレット、折りたたみ式デバイス、デスクトップ、自動車、テレビなど、さまざまなデバイスで動作するようになり、大画面のウィンドウモード（分割画面やデスクトップウィンドウなど）も利用できるようになりました。そのため、デベロッパーは、デバイスの向きにかかわらず、あらゆる画面サイズやウィンドウサイズに対応できる Android アプリを構築する必要があります。画面の向きやサイズ変更を制限するなどのパラダイムは、今日のマルチデバイスの世界では制限が厳しすぎます。

向き、サイズ変更の可能性、アスペクト比の制限を無視する

Android 16（API レベル 36）をターゲットとするアプリでは、最小幅が 600 dp 以上のディスプレイで、画面の向き、サイズ変更、アスペクト比の制限が適用されなくなります。アスペクト比やユーザーが指定した画面の向きにかかわらず、アプリはディスプレイウィンドウ全体に表示され、ピラーボックス表示は使用されません。

この変更により、新しい標準プラットフォームの動作が導入されます。Android は、アプリがさまざまな向き、表示サイズ、アスペクト比に対応することを想定したモデルに移行しています。画面の向きの固定やサイズ変更の制限などの制約は、アプリの適応性を妨げます。アプリをアダプティブにすることで、最高のユーザーエクスペリエンスを提供します。

この動作は、アプリ互換性フレームワークを使用して UNIVERSAL_RESIZABLE_BY_DEFAULT 互換性フラグを有効にすることでもテストできます。

一般的な互換性を破る変更

向き、サイズ変更、アスペクト比の制限を無視すると、一部のデバイスでアプリの UI に影響する可能性があります。特に、縦向きに固定された小さなレイアウト用に設計された要素では、レイアウトの引き伸ばしや画面外のアニメーションやコンポーネントなどの問題が発生する可能性があります。アスペクト比や画面の向きに関する想定は、アプリの視覚的な問題を引き起こす可能性があります。詳細をご確認のうえ、問題を回避し、アプリの適応動作を改善してください。

デバイスの回転を許可すると、アクティビティの再作成が増え、適切に保存されていない場合はユーザーの状態が失われる可能性があります。UI の状態を正しく保存する方法については、UI の状態を保存するをご覧ください。

実装の詳細

次のマニフェスト属性とランタイム API は、大画面デバイスの全画面モードとマルチウィンドウモードでは無視されます。

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 权限使用更精细的权限 under android.permissions.health，which Health Connect also uses。从 Android 16 开始，凡是以前需要具有 BODY_SENSORS 或 BODY_SENSORS_BACKGROUND 权限的 API，现在都需要获取相应的 android.permissions.health 权限。这会影响以下数据类型、API 和前台服务类型：

HEART_RATE_BPM Wear OS 上的健康服务
Sensor.TYPE_HEART_RATE 来自 Android Sensor Manager
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 和其他精细权限的移动应用还必须声明一项 activity 以显示应用的隐私权政策。这与健康数据共享的要求相同。

接続

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 バージョンのロックダウン

Android 16 以降をターゲットとするアプリの場合、MediaStore#getVersion() はアプリごとに一意になります。これにより、バージョン文字列から識別プロパティが削除され、フィンガープリント手法の不正使用と使用が防止されます。アプリでは、このバージョンの形式について前提条件を設定しないでください。アプリは、この API を使用する際にバージョンの変更をすでに処理している必要があります。ほとんどの場合、デベロッパーがこの API の対象範囲を超える追加情報を推測しようとしない限り、現在の動作を変更する必要はありません。

Safer Intents

Safer Intents 機能は、Android のインテント解決メカニズムのセキュリティを強化するために設計された多段階のセキュリティイニシアチブです。この目的は、インテント処理中にチェックを追加し、特定の条件を満たさないインテントをフィルタすることで、アプリを悪意のあるアクションから保護することです。

Android 15 では、この機能は送信側アプリに重点を置いていました。Android 16 では、制御が受信側アプリに移行し、デベロッパーはアプリマニフェストを使用して厳格なインテント解決を有効にできるようになりました。

主な変更点は次の 2 つです。

明示的インテントはターゲットコンポーネントのインテントフィルタと一致する必要がある: インテントがコンポーネントを明示的にターゲットにしている場合、そのコンポーネントのインテントフィルタと一致する必要があります。
アクションのないインテントはインテントフィルタに一致しない: アクションが指定されていないインテントは、インテントフィルタに解決されるべきではありません。

これらの変更は、複数のアプリが関与している場合にのみ適用され、単一のアプリ内のインテント処理には影響しません。

影響

オプトイン方式であるため、デベロッパーはアプリマニフェストで明示的に有効にしないと、この機能は有効になりません。そのため、この機能の影響は、デベロッパーが以下の条件を満たすアプリに限定されます。

Safer Intents 機能とそのメリットを理解している。
より厳格なインテント処理方法をアプリに組み込むことを積極的に選択する。

このオプトインアプローチにより、現在の安全性の低いインテント解決動作に依存している可能性のある既存のアプリが破損するリスクを最小限に抑えることができます。

Android 16 での初期の影響は限定的かもしれませんが、Safer Intents イニシアチブには、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>

サポートされているフラグの詳細:

フラグ名	説明
enforceIntentFilter	受信インテントの厳密な照合を適用する
なし	着信インテントの特別な照合ルールをすべて無効にします。複数のフラグを指定した場合、競合する値は「なし」フラグを優先することで解決されます
allowNullAction	アクションのないインテントを一致させるために、一致ルールの制約を緩和します。特定の動作を実現するために「enforceIntentFilter」と組み合わせて使用されるフラグ

テストとデバッグ

適用が有効になっている場合、インテント呼び出し元がインテントを適切に設定していれば、アプリは正しく機能します。ただし、ブロックされたインテントは、タグ "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:")

GPU システムコールフィルタリング

Mali GPU サーフェスを強化するため、非推奨となった Mali GPU IOCTL や GPU 開発専用の Mali GPU IOCTL は、本番環境ビルドでブロックされています。また、GPU プロファイリングに使用される IOCTL がシェルプロセスまたはデバッグ可能なアプリに制限されました。プラットフォームレベルのポリシーについて詳しくは、SAC の更新を参照してください。

この変更は、Mali GPU を搭載した Google Pixel デバイス（Google Pixel 6 ～ 9）で実施されます。Arm は、r54p2 リリースの Documentation/ioctl-categories.rst で IOCTL の公式な分類を提供しています。このリストは、今後のドライバリリースでも引き続き維持されます。

この変更は、サポートされているグラフィック API（Vulkan や OpenGL など）には影響しません。また、デベロッパーや既存のアプリケーションにも影響しないと見込まれます。Streamline Performance Analyzer や Android GPU Inspector などの 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 に割り当ててください。

よくある質問

このポリシーの変更はすべての OEM に適用されますか？ この変更はオプトインですが、この強化方法を使用したい OEM は誰でも利用できます。変更を実装する手順については、実装に関するドキュメントをご覧ください。
これを実装するには OEM コードベースを変更する必要がありますか？それとも、新しい AOSP リリースにデフォルトで含まれていますか？プラットフォームレベルの変更は、デフォルトで新しい AOSP リリースに含まれます。ベンダーは、この変更を適用したい場合は、コードベースでこの変更を有効にできます。
SoC は IOCTL リストを最新の状態に保つ責任がありますか？たとえば、デバイスが ARM Mali GPU を使用している場合、変更について ARM に問い合わせる必要はありますか？個々の SoC は、ドライバのリリース時にデバイスごとに IOCTL リストを更新する必要があります。たとえば、ARM はドライバの更新時に公開済みの IOCTL リストを更新します。ただし、OEM は、SEPolicy に更新を組み込み、必要に応じて選択したカスタム IOCTL をリストに追加する必要があります。
この変更は、販売中のすべての Google Pixel に自動的に適用されますか？それとも、この変更を適用するためにユーザーが何かを切り替える必要がありますか？この変更は、Mali GPU（Google Pixel 6 ～ 9）を使用するすべての Google Pixel 販売中デバイスに適用されます。この変更を適用するためにユーザー側で必要な操作はありません。
このポリシーを使用すると、カーネルドライバのパフォーマンスに影響しますか？このポリシーは GFXBench を使用して Mali GPU でテストされましたが、GPU パフォーマンスに測定可能な変化は見られませんでした。
IOCTL リストを現在のユーザースペースとカーネルドライバのバージョンに合わせる必要がありますか？はい。許可される IOCTL のリストは、ユーザー空間とカーネルドライバの両方でサポートされる IOCTL と同期する必要があります。ユーザー空間またはカーネルドライバの IOCTL が更新された場合は、SEPolicy IOCTL リストも一致するように更新する必要があります。
ARM は IOCTL を「制限付き」 / 「計測」に分類していますが、一部を本番環境のユースケースで使用したり、一部を拒否したりしたいと考えています。個々の OEM/SoC は、ユーザー空間 Mali ライブラリの構成に基づいて、使用する IOCTL を分類する方法を決定する責任があります。ARM のリストは、これらの決定に役立ちますが、OEM/SoC のユースケースはそれぞれ異なる場合があります。

プライバシー

Android 16（API レベル 36）では、プライバシーが次のように変更されています。

ローカルネットワークの権限

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

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

リリース計画

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

影響

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

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

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

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

アプリの低レベルネットワークオペレーション	必要なローカルネットワーク権限
送信 TCP 接続の確立	はい
受信 TCP 接続の受け入れ	はい
UDP ユニキャスト、マルチキャスト、ブロードキャストの送信	はい
受信 UDP ユニキャスト、マルチキャスト、ブロードキャストの受信	はい

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

上記のルールの例外:

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

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

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

デバイスを 25Q2 ベータ版 3 以降のビルドに書き込みます。
テストするアプリをインストールします。

adb で Appcompat フラグを切り替えます。

adb shell am compat enable RESTRICT_LOCAL_NETWORK <package_name>

デバイスを再起動します

これで、アプリのローカルネットワークへのアクセスが制限され、ローカルネットワークにアクセスしようとするとソケットエラーが発生します。アプリプロセス外でローカルネットワークオペレーションを実行する API（NsdManager など）を使用している場合、 オプトインフェーズでは影響を受けません。

アクセスを復元するには、アプリに NEARBY_WIFI_DEVICES 権限を付与する必要があります。

アプリのマニフェストで NEARBY_WIFI_DEVICES 権限が宣言されていることを確認します。
[設定] > [アプリ] > [アプリ名] > [権限] > [付近のデバイス] > [許可] に移動します。

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

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

権限	送信 LAN リクエスト	送信/受信インターネットリクエスト	受信 LAN リクエスト
許可	機能する	機能する	機能する
未許可	失敗する	機能する	失敗する

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