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

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

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

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

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

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

Android 15 enforced edge-to-edge for apps targeting Android 15 (API level 35), but your app could opt-out by setting R.attr#windowOptOutEdgeToEdgeEnforcement to true. For apps targeting Android 16 (API level 36), R.attr#windowOptOutEdgeToEdgeEnforcement is deprecated and disabled, and your app can't opt-out of going edge-to-edge.

• If your app targets Android 16 (API level 36) and is running on an Android 15 device, R.attr#windowOptOutEdgeToEdgeEnforcement continues to work.
• If your app targets Android 16 (API level 36) and is running on an Android 16 device, R.attr#windowOptOutEdgeToEdgeEnforcement is disabled.

For testing in Android 16, ensure your app supports edge-to-edge and remove any use of R.attr#windowOptOutEdgeToEdgeEnforcement so that your app also supports edge-to-edge on an Android 15 device. To support edge-to-edge, see the Compose and Views guidance.

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

对于以 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 14（API レベル 34）以下をターゲットとするアプリ、または elegantTextHeight 属性を false に設定してデフォルトをオーバーライドした Android 15（API レベル 35）をターゲットとするアプリの

elegantTextHeight の動作。

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

elegantTextHeight の動作。

コア機能

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

この変更により、新しい標準プラットフォームの動作が導入されます。Android は、アプリがさまざまな向き、表示サイズ、アスペクト比に対応することを想定したモデルに移行しています。固定された向きやサイズ変更の制限などの制約はアプリの適応性を妨げるため、アプリをアダプティブにすることで、可能な限り最高のユーザー エクスペリエンスを提供することをおすすめします。

アプリ互換性フレームワークを使用して UNIVERSAL_RESIZABLE_BY_DEFAULT 互換性フラグを有効にすることで、この動作をテストすることもできます。

一般的な互換性を破る変更

向き、サイズ変更、アスペクト比の制限を無視すると、一部のデバイスでアプリの UI に影響する可能性があります。特に、縦向きに固定された小さなレイアウト用に設計された要素では、レイアウトの引き伸ばしや画面外のアニメーションやコンポーネントなどの問題が発生する可能性があります。アスペクト比や向きに関する想定は、アプリの視覚的な問題を引き起こす可能性があります。詳細

デバイスの回転を許可すると、アクティビティの再作成が増え、適切に保存されていない場合はユーザーの状態が失われる可能性があります。UI の状態を正しく保存する方法については、UI の状態を保存するをご覧ください。

実装の詳細

次のマニフェスト属性とランタイム API は、大画面デバイスの全画面モードとマルチウィンドウ モードで無視されます。

• screenOrientation
• resizableActivity
• minAspectRatio
• maxAspectRatio
• setRequestedOrientation()
• getRequestedOrientation()

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 リリースで API レベル 37 をターゲットとする場合には適用されません。つまり、API レベル 37 をターゲットとするアプリの場合、sw600dp 以上のディスプレイでは、画面の向き、サイズ変更、アスペクト比の制限は無視されます。

健康＆フィットネス

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 を使用する場合は、それぞれの詳細な権限をリクエストする必要があります。

• 心拍数、血中酸素ウェルネス、皮膚温の使用中のモニタリングの場合: BODY_SENSORS ではなく、READ_HEART_RATE など、android.permissions.health の下で詳細な権限をリクエストします。
• バックグラウンド センサー アクセスの場合: 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 のペア設定を削除する新しい方法

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

The Safer Intents feature is a multi-phase security initiative designed to improve the security of Android's intent resolution mechanism. The goal is to protect apps from malicious actions by adding checks during intent processing and filtering intents that don't meet specific criteria.

In Android 15 the feature focused on the sending app, now with Android 16, shifts control to the receiving app, allowing developers to opt-in to strict intent resolution using their app manifest.

Two key changes are being implemented:

1. Explicit Intents Must Match the Target Component's Intent Filter: If an intent explicitly targets a component, it should match that component's intent filter.

2. Intents Without an Action Cannot Match any Intent Filter: Intents that don't have an action specified shouldn't be resolved to any intent filter.

These changes only apply when multiple apps are involved and don't affect intent handling within a single app.

Impact

The opt-in nature means that developers must explicitly enable it in their app manifest for it to take effect. As a result, the feature's impact will be limited to apps whose developers:

• Are aware of the Safer Intents feature and its benefits.
• Actively choose to incorporate stricter intent handling practices into their apps.

This opt-in approach minimizes the risk of breaking existing apps that may rely on the current less-secure intent resolution behavior.

While the initial impact in Android 16 may be limited, the Safer Intents initiative has a roadmap for broader impact in future Android releases. The plan is to eventually make strict intent resolution the default behavior.

The Safer Intents feature has the potential to significantly enhance the security of the Android ecosystem by making it more difficult for malicious apps to exploit vulnerabilities in the intent resolution mechanism.

However, the transition to opt-out and mandatory enforcement must be carefully managed to address potential compatibility issues with existing apps.

Implementation

Developers need to explicitly enable stricter intent matching using the intentMatchingFlags attribute in their app manifest. Here is an example where the feature is opt-in for the entire app, but disabled/opt-out on a receiver:

<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>

Note: The attribute can be specified on the <application> tag as well as at the component tags such as <activity>, <activity-alias>, <receiver>, <service>, <provider> and the attribute on the component can be used to override what's on the <application> tag

More on the supported flags:

Flag Name	Description
enforceIntentFilter	Enforces stricter matching for incoming intents
none	Disables all special matching rules for incoming intents. When specifying multiple flags, conflicting values are resolved by giving precedence to the "none" flag
allowNullAction	Relaxes the matching rules to allow intents without an action to match. This flag to be used in conjunction with "enforceIntentFilter" to achieve a specific behavior

Testing and Debugging

When the enforcement is active, apps should function correctly if the intent caller has properly populated the intent. However, blocked intents will trigger warning log messages like "Intent does not match component's intent filter:" and "Access blocked:" with the tag "PackageManager." This indicates a potential issue that could impact the app and requires attention.

Logcat filter:

tag=:PackageManager & (message:"Intent does not match component's intent filter:" | message: "Access blocked:")

プライバシー

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

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

LAN 上のデバイスには、INTERNET 権限を持つアプリからアクセスできます。これにより、アプリがローカル デバイスに簡単に接続できるようになりますが、ユーザーのフィンガープリントの作成や位置情報のプロキシなど、プライバシーに関する影響もあります。

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

リリース計画

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

影響

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

アプリが次の方法でユーザーのローカル ネットワークにアクセスする場合、アプリは影響を受けます。

• ローカル ネットワーク アドレスでのロー ソケットの直接使用またはライブラリ使用（mDNS や SSDP サービス ディスカバリ プロトコルなど）
• ローカル ネットワークにアクセスするフレームワーク レベルのクラス（NsdManager など）の使用

ローカル ネットワーク アドレスとの間のトラフィックには、ローカル ネットワーク アクセス権限が必要です。次の表に、一般的なケースを示します。

アプリの低レベル ネットワーク オペレーション	ローカル ネットワークへのアクセス権が必要です
アウトバウンド TCP 接続を行う	はい
受信 TCP 接続を受け入れる	はい
UDP ユニキャスト、マルチキャスト、ブロードキャストの送信	はい
受信 UDP ユニキャスト、マルチキャスト、ブロードキャスト	はい

これらの制限はネットワーク スタックの奥深くに実装されているため、すべてのネットワーク API に適用されます。これには、ネイティブ コードまたはマネージド コードで作成されたソケット、Cronet や OkHttp などのネットワーキング ライブラリ、それらの上に実装された API が含まれます。ローカル ネットワーク上のサービス（.local サフィックスが付いているものなど）を解決しようとするには、ローカル ネットワークの権限が必要です。

注: ローカル ネットワーク アクセスを必要とする Android WebView から発信されるトラフィックは、ホストアプリから権限の状態を継承します。

上記のルールの例外:

• デバイスの DNS サーバーがローカル ネットワーク上にある場合、そのサーバーとの間のトラフィック（ポート 53）にはローカル ネットワーク アクセス権限は必要ありません。
• アプリ内ピッカーとして出力スイッチャーを使用するアプリは、ローカル ネットワークの権限を必要としません（2025 年第 4 四半期に詳細なガイダンスが提供される予定です）。

注: メディア キャストのシナリオの多くはローカル ネットワークへのアクセスに依存しており、この変更の影響を受けます。ただし、キャスト機能を提供するすべてのアプリが新しい権限をリクエストする必要があるわけではありません。キャスト シナリオに対処するための今後の API とガイダンスは 25Q4 に提供される予定です。

デベロッパー ガイド（オプトイン）

ローカル ネットワークの制限を有効にする手順は次のとおりです。

1. デバイスを 25Q2 ベータ版 3 以降のビルドに書き込みます。
2. テストするアプリをインストールします。

3. adb で Appcompat フラグを切り替えます。

   adb shell am compat enable RESTRICT_LOCAL_NETWORK <package_name>
   

4. デバイスを再起動する

これで、アプリのローカル ネットワークへのアクセスが制限され、ローカル ネットワークにアクセスしようとするとソケット エラーが発生します。アプリのプロセス外でローカル ネットワーク オペレーションを実行する API（NsdManager など）を使用している場合、オプトイン フェーズでは影響を受けません。

アクセス権を復元するには、アプリに NEARBY_WIFI_DEVICES 権限を付与する必要があります。

1. アプリがマニフェストで NEARBY_WIFI_DEVICES 権限を宣言していることを確認します。
2. [設定] > [アプリ] > [アプリ名] > [権限] > [付近のデバイス] > [許可] に移動します。

注: Android の今後のリリースでは、この機能は、付近のデバイス権限グループの新しい権限

によって保護されます。

これで、アプリのローカル ネットワークへのアクセスが復元され、アプリを有効にする前と同じようにすべてのシナリオが動作するはずです。

ローカル ネットワーク保護の適用が開始されると、アプリのネットワーク トラフィックは次のように影響を受けます。

権限	アウトバウンド 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 或更高版本的设备上提示用户授予照片和视频权限时，如果用户选择限制对所选媒体的访问权限，则会在照片选择器中看到该应用拥有的所有照片。用户可以取消选择任何这些预选项，这会撤消该应用对这些照片和视频的访问权限。