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 とビューのガイダンスをご覧ください。

予測型「戻る」には移行またはオプトアウトが必要

Android 16（API レベル 36）以降をターゲットとし、Android 16 以降のデバイスで動作するアプリの場合、予測型「戻る」システムアニメーション（ホームに戻る、タスク間、アクティビティ間）がデフォルトで有効になります。また、onBackPressed は呼び出されず、KeyEvent.KEYCODE_BACK はディスパッチされなくなります。

アプリが「戻る」イベントをインターセプトし、予測型「戻る」にまだ移行していない場合は、サポートされている「戻る」ナビゲーション API を使用するようにアプリを更新するか、アプリの AndroidManifest.xml ファイルの <application> タグまたは <activity> タグで android:enableOnBackInvokedCallback 属性を false に設定して一時的にオプトアウトします。

予測型「戻る」アニメーション。

予測型クロスアクティビティアニメーション。

予測型クロスタスクアニメーション。

エレガントフォント API のサポート終了と無効化

Android 15（API レベル 35）をターゲットとするアプリでは、elegantTextHeight TextView 属性がデフォルトで true に設定され、コンパクトなフォントが可読性の高いフォントに置き換えられます。elegantTextHeight 属性を false に設定することで、この動作をオーバーライドできます。

Android 16 では elegantTextHeight 属性が非推奨となり、アプリのターゲットが Android 16 になると、この属性は無視されます。これらの API で制御される「UI フォント」は廃止されるため、アラビア語、ラオス語、ミャンマー語、タミル語、グジャラート語、カンナダ語、マラヤーラム語、オディア語、テルグ語、タイ語でテキストが常に正しくレンダリングされるように、レイアウトを調整する必要があります。

コア機能

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

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

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

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

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. 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、フォアグラウンドサービスタイプに影響します。

Wear OS のヘルスサービスの HEART_RATE_BPM
Android センサーマネージャーの Sensor.TYPE_HEART_RATE
Wear OS の ProtoLayout の heartRateAccuracy と heartRateBpm
FOREGROUND_SERVICE_TYPE_HEALTH。BODY_SENSORS の代わりに、それぞれの android.permission.health 権限が必要です。

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

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

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

モバイルアプリ

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

接続

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

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

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.

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

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

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

より安全なインテント

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	受信インテントに対してより厳格なマッチングを適用する
なし	受信インテントのすべての特別な一致ルールを無効にします。複数のフラグを指定する場合、競合する値は「none」フラグを優先することで解決されます
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 市販デバイス（Google Pixel 6 ～ 9）に適用されます。この変更を適用するために、ユーザー側での対応は必要ありません。
このポリシーを使用すると、カーネルドライバのパフォーマンスに影響しますか？ このポリシーは、GFXBench を使用して Mali GPU でテストされましたが、GPU のパフォーマンスに測定可能な変化は見られませんでした。
IOCTL リストを現在のユーザースペースとカーネルドライバのバージョンに合わせる必要はありますか？ はい。許可される IOCTL のリストは、ユーザー空間ドライバとカーネルドライバの両方でサポートされている IOCTL と同期する必要があります。ユーザー空間またはカーネルドライバの IOCTL が更新された場合は、SEPolicy IOCTL リストを更新して一致させる必要があります。
ARM は IOCTL を「制限付き」/「インストルメンテーション」に分類していますが、本番環境のユースケースで一部を使用したり、他の IOCTL を拒否したりしたいと考えています。個々の OEM/SoC は、ユーザースペースの Mali ライブラリの構成に基づいて、使用する IOCTL の分類方法を決定する責任があります。ARM のリストは、これらの決定に役立ちますが、各 OEM/SoC のユースケースは異なる場合があります。

プライバシー

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

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

LAN 上のデバイスには、INTERNET 権限を持つすべてのアプリがアクセスできます。これにより、アプリはローカルデバイスに簡単に接続できるようになりますが、ユーザーのフィンガープリントが作成されたり、位置情報が推測されたりするなど、プライバシー上の懸念も生じます。

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

リリース計画

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

影響

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

以下を使用してユーザーのローカルネットワークにアクセスするアプリが影響を受けます。

ローカルネットワークアドレスでの raw ソケットの直接使用またはライブラリ使用（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>

エラー

これらの制限に起因するエラーは、ローカルネットワークアドレスへの send または send バリアントを呼び出すたびに、呼び出し元のソケットに返されます。

エラーの例:

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 などのスタブネットワーク
マルチサブネット（TBD）

また、マルチキャストアドレス（224.0.0.0/4、ff00::/8）と IPv4 ブロードキャストアドレス（255.255.255.255）は、どちらもローカルネットワークアドレスに分類されます。

アプリが所有する写真

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