このページは Cloud Translation API によって翻訳されました。

動作の変更点: 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 或更高版本的设备上运行的应用，预测性返回系统动画（返回主屏幕、跨任务和跨 activity）默认处于启用状态。此外，系统不再调用 onBackPressed，也不再调度 KeyEvent.KEYCODE_BACK。

如果您的应用会拦截返回事件，但您尚未迁移到预测性返回，请更新应用以使用受支持的返回导航 API，或者通过在应用的 AndroidManifest.xml 文件的 <application> 或 <activity> 标记中将 android:enableOnBackInvokedCallback 属性设置为 false 来暂时选择停用。

预测性返回首页动画。

预测性跨 activity 动画。

预测性跨任务动画。

Elegant font 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 为目标平台时，当应用返回到有效的生命周期时，系统会立即执行最多 1 次未执行的 scheduleAtFixedRate 执行。此行为变更预计会提升应用性能。在您的应用中测试此行为，检查您的应用是否受到影响。您还可以使用应用兼容性框架并启用 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）では、健康とフィットネスに関するデータに関連して、以下の変更が加えられています。

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

For apps targeting Android 16 (API level 36) or higher, BODY_SENSORS permissions use more granular permissions under android.permissions.health, which Health Connect also uses. As of Android 16, any API previously requiring BODY_SENSORS or BODY_SENSORS_BACKGROUND requires the corresponding android.permissions.health permission instead. This affects the following data types, APIs, and foreground service types:

HEART_RATE_BPM from Health Services on Wear OS
Sensor.TYPE_HEART_RATE from Android Sensor Manager
heartRateAccuracy and heartRateBpm from ProtoLayout on Wear OS
FOREGROUND_SERVICE_TYPE_HEALTH where the respective android.permission.health permission is needed in place of BODY_SENSORS

If your app uses these APIs, it should request the respective granular permissions:

For while-in-use monitoring of Heart Rate, SpO2, or Skin Temperature: request the granular permission under android.permissions.health, such as READ_HEART_RATE instead of BODY_SENSORS.
For background sensor access: request READ_HEALTH_DATA_IN_BACKGROUND instead of BODY_SENSORS_BACKGROUND.

These permissions are the same as those that guard access to reading data from Health Connect, the Android datastore for health, fitness, and wellness data.

Mobile apps

Mobile apps migrating to use the READ_HEART_RATE and other granular permissions must also declare an activity to display the app's privacy policy. This is the same requirement as Health Connect.

接続

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

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

作为改进了对键值对丢失的处理的一部分，Android 16 还引入了 2 个新 intent，以便应用更好地了解键值对丢失和加密更改。

以 Android 16 为目标平台的应用现在可以：

在检测到远程键盘连接丢失时接收 ACTION_KEY_MISSING intent，以便提供更具信息量的用户反馈并采取适当的措施。
每当链接的加密状态发生变化时，都会收到 ACTION_ENCRYPTION_CHANGE intent。这包括加密状态更改、加密算法更改和加密密钥大小更改。如果应用在稍后收到 ACTION_ENCRYPTION_CHANGE intent 时成功加密了链接，则必须将该绑定视为已恢复。

适应不同的 OEM 实现

虽然 Android 16 引入了这些新 intent，但其实现和广播可能会因不同的设备制造商 (OEM) 而异。为了确保您的应用在所有设备上都能提供一致且可靠的体验，开发者应设计其绑定丢失处理机制，以妥善适应这些潜在的变化。

我们建议您采用以下应用行为：

如果广播 ACTION_KEY_MISSING intent：

系统会断开 ACL（异步无连接）链接，但会保留设备的配对信息（如此处所述）。

您的应用应将此 intent 用作检测配对丢失的主要信号，并在发起设备忘记或重新配对之前引导用户确认远程设备是否在范围内。

如果设备在收到 ACTION_KEY_MISSING 后断开连接，您的应用应谨慎重新连接，因为设备可能已不再与系统绑定。
如果未广播 ACTION_KEY_MISSING intent：

ACL 链接将保持连接状态，系统会移除设备的配对信息，与 Android 15 中的行为相同。

在这种情况下，您的应用应继续使用与之前的 Android 版本相同的现有配对丢失处理机制，以检测和管理配对丢失事件。

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

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 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 リクエスト
許可	Works	Works	Works
Not Granted（未許可）	ハプニング集	Works	ハプニング集

次のコマンドを使用して、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 などのスタブネットワーク
複数サブネット（未定）

また、マルチキャストアドレス（224.0.0.0/4、ff00::/8）と IPv4 ブロードキャストアドレス（255.255.255.255）の両方がローカルネットワークアドレスとして分類されます。

アプリ所有の写真

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