動作の変更点: すべてのアプリ

Android 17 プラットフォームには、アプリに影響を与える可能性のある動作変更が含まれています。 下記の動作変更は、Android 17 上で稼働する すべてのアプリ に適用されます。 targetSdkVersion に関係ありません。該当する場合は、アプリをテストし、必要に応じて修正して、これらの変更に対応する必要があります。

Android 17 をターゲットとするアプリにのみ影響する動作変更のリストも必ずご確認ください 。

コア機能

Android 17（API レベル 37）には、Android システムのさまざまなコア機能を変更または拡張する以下の変更が含まれています。

アプリのメモリ制限

Android 17 では、デバイスの総 RAM に基づいてアプリのメモリ上限が導入され、アプリと Android ユーザーにとってより安定した決定論的な環境が実現します。Android 17 では、システム全体のベースラインを確立するために上限が控えめに設定されています。これにより、極端なメモリリークやその他の外れ値が、UI のスタッター、バッテリーの消耗、アプリの強制終了につながるシステム全体の不安定さを引き起こす前に、それらをターゲットにすることができます。ほとんどのアプリセッションへの影響は最小限に抑えられると予想されますが、 メモリのベースラインの確立など、次のメモリに関するベストプラクティス をおすすめします。

アプリセッションが影響を受けたかどうかは、ApplicationExitInfo で getDescription を呼び出すことで確認できます。アプリが 影響を受けた場合、終了理由は REASON_OTHER になり、 説明には他の情報とともに文字列"MemoryLimiter:AnonSwap" が含まれます。トリガーベースのプロファイリングを TRIGGER_TYPE_ANOMALYと組み合わせて使用​​すると、 メモリ上限に達したときに収集されるヒープダンプを取得することもできます。

Android Studio Profiler の LeakCanary タスク。

メモリリークを見つけやすくするため、Android Studio Panda では、Android Studio Profiler に LeakCanary 統合が専用タスクとして直接追加され、IDE 内でコンテキスト化され、ソースコードと完全に統合されています。

セキュリティ

Android 17 では、デバイスとアプリのセキュリティが次のように改善されています。

usesClearTraffic の非推奨プラン

今後のリリースで、usesCleartextTraffic 要素は非推奨になる予定です。暗号化されていない（HTTP）接続を行う必要があるアプリは、ネットワーク セキュリティ構成ファイルを使用するように移行する必要があります。このファイルを使用すると、アプリがクリアテキスト接続を行う必要があるドメインを指定できます。

ネットワーク セキュリティ構成ファイルは API レベル 24 以上でのみサポートされます。アプリの最小 API レベルが 24 未満の場合は、次の両方を行う必要があります。

  • usesCleartextTraffic 属性を true に設定します。
  • ネットワーク構成ファイルを使用する

アプリの最小 API レベルが 24 以上の場合、ネットワーク構成ファイルを使用できるため、usesCleartextTraffic を設定する必要はありません。

暗黙的な URI 権限付与の制限

Currently, if an app launches an intent with a URI that has the action Send, SendMultiple, or ImageCapture, the system automatically grants the read and write URI permissions to the target app. We plan to change this behavior in Android 18. For this reason, we recommend that apps explicitly grant the relevant URI permissions instead of relying on the system to grant them.

アプリごとのキーストアの上限

Android Keystore はデバイス上のすべてのアプリで共有されるリソースであるため、アプリは Android Keystore で過剰な数の鍵を作成しないようにする必要があります。Android 17 以降では、アプリが所有できる鍵の数に上限が設けられています。Android 17（API レベル 37）以上をターゲットとするシステムアプリ以外のアプリの場合、上限は 50,000 個の鍵です。その他のすべてのアプリの場合、上限は 200,000 個の鍵です。システムアプリのキーの上限は、対象とする API レベルに関係なく 200,000 個です。

アプリが上限を超えるキーを作成しようとすると、KeyStoreException で作成が失敗します。例外のメッセージ文字列には、キーの上限に関する情報が含まれています。アプリが例外で getNumericErrorCode() を呼び出す場合、戻り値はアプリのターゲット API レベルによって異なります。

  • Android 17（API レベル 37）以上をターゲットとするアプリの場合: getNumericErrorCode() は新しい ERROR_TOO_MANY_KEYS 値を返します。
  • その他のすべてのアプリ: getNumericErrorCode() は ERROR_INCORRECT_USAGE を返します。

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

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

回転後の IME の可視性に関するデフォルトを復元

Android 17 以降では、デバイスの構成が変更されたとき（回転など）に、アプリ自体で処理されない場合、以前の IME の可視性は復元されません。

アプリが処理しない構成変更が行われ、変更後にキーボードを表示する必要がある場合は、明示的にリクエストする必要があります。このリクエストは、次のいずれかの方法で行うことができます。

  • android:windowSoftInputMode 属性を stateAlwaysVisible に設定します。
  • アクティビティの onCreate() メソッドでソフト キーボードをプログラムでリクエストするか、onConfigurationChanged() メソッドを追加します。

手入力

Android 17 には、アプリがキーボードやタッチパッドなどの手入力デバイスとやり取りする方法に影響する以下の変更が含まれています。

ポインタ キャプチャ中、タッチパッドはデフォルトで相対イベントを配信する

Beginning with Android 17, if an app requests pointer capture using View.requestPointerCapture() and the user uses a touchpad, the system recognizes pointer movement and scrolling gestures from the user's touches and reports them to the app in the same way as pointer and scroll wheel movements from a captured mouse. In most cases, this removes the need for apps that support captured mice to add special handling logic for touchpads. For more details, see the documentation for View.POINTER_CAPTURE_MODE_RELATIVE.

Previously, the system did not attempt to recognize gestures from the touchpad, and instead delivered the raw, absolute finger locations to the app in a similar format to touchscreen touches. If an app still requires this absolute data, it should call the new View.requestPointerCapture(int) method with View.POINTER_CAPTURE_MODE_ABSOLUTE instead.

メディア

Android 17 には、メディアの動作に関する以下の変更が含まれています。

バックグラウンド オーディオの強化

Beginning with Android 17, the audio framework enforces restrictions on background audio interactions including audio playback, audio focus requests, and volume change APIs to ensure that these changes are started intentionally by the user.

If the app tries to call audio APIs while the app is not in a valid lifecycle, the audio playback and volume change APIs fail silently without throwing an exception or providing a failure message. The audio focus API fails with the result code AUDIOFOCUS_REQUEST_FAILED.

For more information, including mitigation strategies, see Background audio hardening.

接続

Android 17 には、デバイスの接続を強化するための以下の変更が含まれています。

Bluetooth ペアリングの損失に対する自律的な再ペア設定

Android 17 introduces autonomous re-pairing, a system-level enhancement designed to automatically resolve Bluetooth bond loss.

Previously, if a bond was lost, users had to manually navigate to Settings to unpair and then re-pair the peripheral. This feature builds upon the security improvement of Android 16 by allowing the system to re-establish bonds in the background without requiring users to manually navigate to Settings to unpair and re-pair peripherals.

While most apps will not require code changes, developers should be aware of the following behavior changes in Bluetooth stack:

  • New pairing context: The ACTION_PAIRING_REQUEST now includes the EXTRA_PAIRING_CONTEXT extra which allows apps to distinguish between a standard pairing request and an autonomous system-initiated re-pairing attempt.
  • Conditional key updates: Existing security keys will only be replaced if the re-pairing is successful and new connection meets or exceeds the security level of the previous bond.
  • Modified intent timing: The ACTION_KEY_MISSING intent is now broadcast only if the autonomous re-pairing attempt fails. This reduces unnecessary error handling in the app if the system successfully recovers the bond in the background.
  • User notification: The system manages re-pairing via new UI notifications and dialogs. Users will be prompted to confirm the re-pairing attempt to ensure they are aware of the reconnection.

Peripheral device manufacturers and companion app developers should verify that hardware and app gracefully handle bond transitions. To test this behavior, simulate a remote bond loss using either of the following methods:

  • Manually remove the bond information from the peripheral device
  • Manually unpair the device in: Settings > Connected devices