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

動作の変更点: Android 16 以上をターゲットとするアプリ
コレクションでコンテンツを整理必要に応じて、コンテンツの保存と分類を行います。

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

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

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

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

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

Android 15（API レベル 35）をターゲットとするアプリに対して、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 ベータ版 3 でテストするには、アプリがエッジツーエッジに対応していることを確認し、R.attr#windowOptOutEdgeToEdgeEnforcement の使用をすべて削除して、Android 15 デバイスでもアプリがエッジツーエッジに対応するようにします。エッジツーエッジをサポートするには、Compose とビューのガイダンスをご覧ください。

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

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）では、大画面デバイスに表示されるアプリについて、次のように変更されています。

アダプティブレイアウト

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), Android 16 includes changes to how the system manages orientation, resizability, and aspect ratio restrictions. On displays with smallest width >= 600dp, the restrictions no longer apply. Apps also 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, so we recommend making 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, but 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）では、健康とフィットネスのデータに関連する次の変更が加えられました。

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

For apps targeting Android 16 (API level 36) or higher, BODY_SENSORS permissions are transitioning to the granular permissions under android.permissions.health also used by Health Connect. Any API previously requiring BODY_SENSORS or BODY_SENSORS_BACKGROUND now requires the corresponding android.permissions.health permission. This affects the following data types, APIs, and foreground service types:

HEART_RATE_BPM from Wear Health Services
Sensor.TYPE_HEART_RATE from Android Sensor Manager
heartRateAccuracy and heartRateBpm from Wear ProtoLayout
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 now 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 つの新しいインテントを導入しました。

Android 16 をターゲットとするアプリは、次のことができます。

リモートボンドの損失が検出されたときに ACTION_KEY_MISSING インテントを受け取り、より有益なユーザーフィードバックを提供するとともに、適切なアクションを実行できます。
リンクの暗号化ステータスが変更されるたびに ACTION_ENCRYPTION_CHANGE インテントを受け取ります。これには、暗号化ステータスの変更、暗号化アルゴリズムの変更、暗号鍵サイズの変更が含まれます。後で ACTION_ENCRYPTION_CHANGE インテントを受け取った際にリンクが正常に暗号化された場合、アプリはボンディングが復元されたと見なす必要があります。

アプリで現在、接続切れの処理にカスタムメカニズムを使用している場合は、新しいインテント ACTION_KEY_MISSING に移行して、接続切れイベントを検出して管理してください。デバイスの消去と再ペア設定を開始する前に、リモートデバイスが範囲内にあることを確認するよう、アプリでユーザーに案内することをおすすめします。

また、ACTION_KEY_MISSING インテントを受け取った後にデバイスが切断された場合、そのデバイスがシステムとボンディングされていない可能性があるため、アプリはデバイスへの再接続に注意する必要があります。

セキュリティ

Android 16（API レベル 36）では、セキュリティが次のように変更されています。

MediaStore バージョンのロックダウン

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

プライバシー

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

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

LAN 上のデバイスには、INTERNET 権限を持つすべてのアプリからアクセスできます。これにより、アプリはローカルデバイスに簡単に接続できますが、ユーザーの指紋の形成や位置情報のプロキシとしての使用など、プライバシーに関連する問題もあります。

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

リリース計画

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

影響

現段階では、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
未許可	ハプニング集	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）は、ローカルネットワークアドレスとして分類されます。