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

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

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

コア機能

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

アプリのメモリ制限

Android 17 introduces app memory limits based on the device's total RAM to create a more stable and deterministic environment for your applications and Android users. In Android 17, limits are set conservatively to establish system baselines, targeting extreme memory leaks and other outliers before they trigger system-wide instability resulting in UI stuttering, higher battery drain, and apps being killed. While we anticipate minimal impact on the vast majority of app sessions, we recommend the following memory best practices, including establishing a baseline for memory.

You can determine if your app session was impacted by calling getDescription in ApplicationExitInfo; if your app was affected, the exit reason will be REASON_OTHER and the description will contain the string "MemoryLimiter:AnonSwap" along with other information. You can also use trigger-based profiling with TRIGGER_TYPE_ANOMALY to get heap dumps that are collected when the memory limit is hit.

The Manage your app's memory documentation gives information to help you diagnose your app's memory issues and optimize its resource consumption.

Test your app's behavior under the memory constraints

You can use Android Debug Bridge (adb) to adjust or disable the memory limits on any device that imposes them. The shell command am provides three subcommands to adjust the memory limits. (These commands have no effect on a device which does not impose memory limits.)

  • am memory-limiter ignore <uid>|none|all
  • am memory-limiter manual <pid> <limit>|max|none
  • am memory-limiter status
ignore

Instructs the memory limiter to ignore some or all processes. Passing a UID instructs the memory limiter to ignore all processes associated with that UID. You can also pass all (ignore all processes) or none (do not ignore any processes). Passing none overrides any previous calls to am memory-limiter ignore.

If you instruct the memory limiter to ignore a process, you can still apply a manual memory limit to the process by calling am memory-limiter manual.

manual

Instructs the system to impose a memory constraint on the process with the specified PID. The memory constraint is specified as an integer number of MB; for example, passing 30 specifies that the process is limited to 30 MB of memory. Passing max removes all memory limits on that process. Passing none removes any manual limits set on the process, restoring the system's default limit (if any).

status

Reports the current status of the memory limiter. The status includes the memory limits imposed on visible and non-visible processes.

プライバシー

Android 17 には、ユーザーのプライバシーを強化するための以下の変更が含まれています。

SMS OTP 保護

Android 17 以降、Android ではワンタイム パスワード（OTP）を含む SMS メッセージの保護が強化されています。

以前のバージョンの Android では、この保護は主に SMS Retriever 形式を対象としていました。SMS Retriever ハッシュを含むメッセージの配信は、ほとんどのアプリで 3 時間遅延しました。ただし、特定のアプリ（デフォルトの SMS ハンドラなど）は遅延の対象外であり、ハッシュを所有するアプリも対象外でした。

Android 17 以降では、WebOTP 形式のメッセージにも保護が適用されます。アプリが SMS メッセージを読み取る権限を持っていても、WebOTP メッセージの対象受信者でない場合（ドメイン検証で判断）、メッセージは受信から 3 時間後までアプリからアクセスできません。この変更は、メッセージに記載されているドメインに関連付けられたアプリのみがプログラムで確認コードを読み取れるようにすることで、ユーザーのセキュリティを強化することを目的としています。

この 3 時間の遅延の間、SMS_RECEIVED_ACTION ブロードキャストは保留され、SMS プロバイダのデータベース クエリはフィルタされます。SMS メッセージは、遅延後にこれらのアプリで利用できるようになります。この変更は、対象 API レベルに関係なく、すべてのアプリに適用されます。

デフォルトの SMS アシスタント アプリや接続済みデバイス コンパニオン アプリなど、一部のアプリはこの遅延の対象外です。OTP の抽出のために SMS メッセージの読み取りに依存しているすべてのアプリは、機能を継続して利用できるように、SMS Retriever API または SMS User Consent API を使用するように移行する必要があります。

セキュリティ

Android 17 には、デバイスとアプリのセキュリティを強化するための以下の改善が含まれています。

usesClearTraffic の非推奨プラン

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

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

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

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

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

現在、アプリがアクション ACTION_SEND、ACTION_SEND_MULTIPLE、または ACTION_IMAGE_CAPTUREを含む URI でインテントを起動すると、システムはターゲットアプリに読み取りと 書き込みの URI 権限を自動的に付与します。Android 18 以降では、システムは これらの権限を自動的に付与しなくなります。そのため、アプリはシステムに権限を付与させるのではなく、関連する URI 権限を明示的に付与することをおすすめします。

アプリでこれらのインテントが使用されていることを検出するには、StrictMode と detectImplicitUriPermissionGrant() を使用して違反をトリガーします。

Kotlin

val policy = StrictMode.VmPolicy.Builder()
    .detectImplicitUriPermissionGrant()
    .penaltyLog()
    .build()
StrictMode.setVmPolicy(policy)

Java

StrictMode.VmPolicy policy = new StrictMode.VmPolicy.Builder()
    .detectImplicitUriPermissionGrant()
    .penaltyLog()
    .build();
StrictMode.setVmPolicy(policy);

または、システムが暗黙的に付与を設定したときに表示されるメッセージ Please set the grant explicitly in the app を含む、記録された例外をモニタリングすることもできます。これらのログは、次の adb コマンドを使用してモニタリングできます。

adb logcat | grep "Please set the grant explicitly in the app"

必要な権限を明示的に付与するには、 FLAG_GRANT_READ_URI_PERMISSION フラグを ACTION_SEND インテントと ACTION_SEND_MULTIPLE インテントに追加します。

Kotlin

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION)

Java

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION);

ACTION_IMAGE_CAPTURE インテントには、FLAG_GRANT_READ_URI_PERMISSION フラグと FLAG_GRANT_WRITE_URI_PERMISSION フラグの両方を含めます。

Kotlin

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION or Intent.FLAG_GRANT_WRITE_URI_PERMISSION)

Java

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION | Intent.FLAG_GRANT_WRITE_URI_PERMISSION);

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

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 を返します。

クロス プロファイル ループバック トラフィックのブロック

Android 17 以降では、デフォルトでプロファイル間のループバック トラフィックが許可されなくなりました。同じプロファイル内のループバック トラフィックは影響を受けません。 この変更は、アプリがターゲットとする API レベルに関係なく、Android 17 以降で実行されるすべてのアプリに適用されます。

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

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

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

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

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

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

手入力

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

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

Android 17 以降では、アプリが View.requestPointerCapture() を使用してポインタ キャプチャをリクエストし、ユーザーがタッチパッドを使用している場合、システムはユーザーのタップによるポインタの移動とスクロール操作を認識し、キャプチャされたマウスのポインタとスクロール ホイールの移動と同じ方法でアプリに報告します。ほとんどの場合、キャプチャされたマウスをサポートするアプリで、タッチパッド用の特別な処理ロジックを追加する必要がなくなります。詳細については、View.POINTER_CAPTURE_MODE_RELATIVE のドキュメントをご覧ください。

以前は、システムはタッチパッドからのジェスチャーを認識しようとせず、代わりに、タッチスクリーンのタップと同様の形式で、指の絶対位置の生データをアプリに配信していました。アプリでこの絶対データが引き続き必要な場合は、代わりに View.POINTER_CAPTURE_MODE_ABSOLUTE を使用して新しい View.requestPointerCapture(int) メソッドを呼び出す必要があります。

メディア

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

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

Android 17 以降では、オーディオ フレームワークは、オーディオ再生、音声フォーカス リクエスト、音量変更 API などのバックグラウンド オーディオ インタラクションに対する制限を適用し、これらの変更がユーザーによって意図的に開始されるようにします。

アプリが有効なライフサイクルにないときにアプリが音声 API を呼び出そうとすると、例外をスローしたり、エラー メッセージを提供したりすることなく、音声再生 API と音量変更 API はサイレントに失敗します。音声フォーカス API が結果コード AUDIOFOCUS_REQUEST_FAILED で失敗します。

軽減策など、詳しくは、バックグラウンド音声の強化をご覧ください。

接続

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