このページは 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 Beta 版 3 中进行测试，请确保您的应用支持无边框设计，并移除对 R.attr#windowOptOutEdgeToEdgeEnforcement 的所有使用，以便您的应用在 Android 15 设备上也支持无边框设计。如需支持边到边，请参阅 Compose 和 Views 指南。

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

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

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

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

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

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

Elegant フォント API の非推奨と無効化

Android 15（API レベル 35）をターゲットとするアプリでは、elegantTextHeight TextView 属性がデフォルトで true に設定されているため、コンパクトフォントが読みやすくなっています。elegantTextHeight 属性を false に設定すると、これをオーバーライドできます。

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

Android 16 をターゲットとするアプリ、または `elegantTextHeight` 属性を `false` に設定してデフォルトをオーバーライドしなかった Android 15（API レベル 35）をターゲットとするアプリの `elegantTextHeight` の動作。

コア機能

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）をターゲットとするアプリの場合、Android 16 では、システムが画面の向き、サイズ変更、アスペクト比の制限を管理する方法が変更されています。最小幅が 600dp 以上のディスプレイでは、この制限は適用されなくなります。また、アプリは、アスペクト比やユーザーが選択した画面の向きに関係なく、ディスプレイウィンドウ全体に表示されます。ピラーボックス表示は使用されません。

この変更により、新しい標準のプラットフォーム動作が導入されます。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 権限は、ヘルスコネクトでも使用される 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 を使用する場合は、それぞれ詳細な権限をリクエストする必要があります。

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

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:")

プライバシー

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

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

具有 INTERNET 权限的任何应用都可以访问 LAN 上的设备。这样一来，应用便可以轻松连接到本地设备，但也存在隐私问题，例如形成用户的指纹，以及充当位置信息的代理。

本地网络保护项目旨在通过将对本地网络的访问权限置于新的运行时权限后面来保护用户的隐私。

发布计划

这项更改将在两个版本（分别为 25Q2 和 TBD）之间部署。开发者必须遵循 25Q2 的相关指南并分享反馈，因为这些保护措施将在较新的 Android 版本中强制执行。此外，他们需要按照以下指南更新依赖于隐式本地网络访问权限的场景，并为用户拒绝和撤消新权限做好准备。

影响

目前，LNP 是一项用户可选择启用的功能，这意味着只有选择启用该功能的应用会受到影响。选择启用阶段的目标是让应用开发者了解其应用的哪些部分依赖于隐式本地网络访问权限，以便他们为下一个版本做好权限保护准备。

如果应用使用以下方式访问用户的本地网络，则会受到影响：

在本地网络地址上直接或通过库使用原始套接字（例如 mDNS 或 SSDP 服务发现协议）
使用访问本地网络的框架级类（例如 NsdManager）

到和从本地网络地址发送的流量需要本地网络访问权限。下表列出了一些常见用例：

应用低级网络操作	需要本地网络权限
建立出站 TCP 连接	是
接受传入的 TCP 连接	是
发送 UDP 单播、多播、广播	是
接收传入的 UDP 单播、多播、广播	是

这些限制在网络堆栈深处实现，因此适用于所有网络 API。这包括在原生代码或受管理代码中创建的套接字、Cronet 和 OkHttp 等网络库，以及在这些库之上实现的任何 API。尝试解析本地网络上的服务（即带有 .local 后缀的服务）需要本地网络权限。

上述规则的例外情况：

如果设备的 DNS 服务器位于本地网络中，则向其发送或从其接收的流量（在端口 53 上）不需要本地网络访问权限。
使用输出切换器作为应用内选择器的应用无需本地网络权限（更多指南将于 2025 年第 4 季度发布）。

开发者指南（用户选择启用）

如需选择启用本地网络限制，请执行以下操作：

将设备刷写为搭载 25Q2 Beta 版 3 或更高版本的 build。
安装要测试的应用。

在 adb 中切换 Appcompat 标志：

adb shell am compat enable RESTRICT_LOCAL_NETWORK <package_name>

重启设备

现在，您的应用对本地网络的访问权限受到限制，任何尝试访问本地网络的操作都会导致套接字错误。如果您使用的 API 在应用进程之外执行本地网络操作（例如 NsdManager），则在用户选择启用该功能期间，这些 API 不会受到影响。

如需恢复访问权限，您必须向应用授予 NEARBY_WIFI_DEVICES 权限。

确保应用在其清单中声明了 NEARBY_WIFI_DEVICES 权限。
依次前往设置 > 应用 > [应用名称] > 权限 > 附近的设备 > 允许。

现在，您的应用对本地网络的访问权限应该已恢复，并且所有场景都应像在应用选择启用之前一样正常运行。

本地网络保护功能开始强制执行后，应用网络流量将受到以下影响。

权限	出站 LAN 请求	出站/入站互联网请求	入站 LAN 请求
已授予	Works	Works	Works
未授予	最差排行榜	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) 都被归类为本地网络地址。

アプリ所有の写真

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