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

動作の変更点: Android 16 以上をターゲットとするアプリ

これまでのリリースと同様、Android 16 には、アプリに影響する可能性がある動作変更が含まれています。下記の動作変更は、Android 16 以上をターゲットとするアプリにのみ適用されます。アプリが Android 16 以上をターゲットとする場合は、必要に応じてアプリを変更し、下記の動作に適切に対応できるようにしてください。

アプリの targetSdkVersion に関係なく、Android 16 で実行されるすべてのアプリに影響する動作変更のリストも必ずご確認ください。

ユーザーエクスペリエンスとシステム UI

Android 16（API レベル 36）には、より一貫性のある直感的なユーザーエクスペリエンスを実現するための以下の変更が含まれています。

エッジツーエッジのオプトアウトの廃止

Android 15 强制实行全屏显示，但您的应用可以通过将 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 为目标平台时，当应用返回到有效的生命周期时，系统会立即执行最多 1 次未执行的 scheduleAtFixedRate 执行。此行为变更预计会提升应用性能。在您的应用中测试此行为，检查您的应用是否受到影响。您还可以使用应用兼容性框架并启用 STPE_SKIP_MULTIPLE_MISSED_PERIODIC_TASKS 兼容性标志进行测试。

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

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

アダプティブレイアウト

现在，Android 应用可在各种设备（例如手机、平板电脑、可折叠设备、桌面设备、汽车和电视）上运行，并且在大屏设备上支持多种窗口模式（例如分屏和桌面窗口化模式），因此开发者应构建能够适应任何屏幕和窗口尺寸的 Android 应用，无论设备屏幕方向如何。在当今多设备的世界中，限制屏幕方向和尺寸可调整性等范式过于严格。

忽略屏幕方向、尺寸可调整性和宽高比限制

对于以 Android 16（API 级别 36）为目标平台的应用，在最小宽度 >= 600dp 的显示屏上，屏幕方向、尺寸调整能力和宽高比限制不再适用。应用会填满整个显示窗口，无论宽高比或用户偏好的屏幕方向如何，都不会使用竖屏黑边模式。

此变更引入了新的标准平台行为。Android 正在向一种模型转变，在该模型中，应用需要适应各种屏幕方向、显示大小和宽高比。固定屏幕方向或有限的尺寸调整等限制会阻碍应用的适应性。使应用具有自适应性，以提供尽可能最佳的用户体验。

您还可以使用应用兼容性框架并启用 UNIVERSAL_RESIZABLE_BY_DEFAULT 兼容性标志来测试此行为。

常见的重大更改

忽略屏幕方向、可调整大小性和宽高比限制可能会影响应用在某些设备上的界面，尤其是那些专为锁定为纵向的小布局设计的元素：例如，布局拉伸、动画和组件超出屏幕等问题。任何关于宽高比或屏幕方向的假设都可能导致应用出现视觉问题。详细了解如何避免这些问题并改进应用的自适应行为。

允许设备旋转会导致更多 activity 重新创建，如果未正确保留用户状态，可能会导致用户状态丢失。如需了解如何正确保存界面状态，请参阅保存界面状态。

实现细节

在全屏模式和多窗口模式下，以下清单属性和运行时 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 的屏幕

暂时选择不接收

如需选择停用特定 activity，请声明 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 解除蓝牙设备配对。如果配套设备作为 CDM 关联进行管理，则应用可以在关联的设备上使用新的 removeBond(int) API 触发蓝牙配对的移除。该应用可以通过监听蓝牙设备广播事件 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）はどちらもローカルネットワークアドレスとして分類されます。

アプリ所有の写真

当面向 SDK 36 或更高版本的应用在搭载 Android 16 或更高版本的设备上提示用户授予照片和视频权限时，如果用户选择限制对所选媒体的访问权限，则会在照片选择器中看到该应用拥有的所有照片。用户可以取消选择任何这些预选项，这会撤消该应用对这些照片和视频的访问权限。