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

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

Beginning with Android 17, Android is expanding its protection for SMS messages containing one-time passwords (OTP).

In previous versions of Android, this protection was primarily focused on the SMS Retriever format. Delivery of messages containing an SMS retriever hash was delayed for most apps for three hours. However, certain certain apps (like the default SMS handler) were exempt from the delay, and the app that owned the hash was also exempted.

Beginning with Android 17, the protection is also applied to WebOTP format messages. If an app has permission to read SMS messages but is not the intended recipient of a WebOTP message (as determined by domain verification), the message is not accessible to the app until three hours after the message's receipt. This change is intended to improve user security by ensuring that only apps associated with the domain mentioned in the message can programmatically read the verification code.

During this three hour delay, the SMS_RECEIVED_ACTION broadcast is withheld and SMS provider database queries are filtered. The SMS message is available to these apps after the delay. This change applies to all apps, regardless of their target API level.

Certain apps such as the default SMS assistant app, connected device companion apps, etc., are exempted from this delay. All apps that rely on reading SMS messages for OTP extraction should transition to using SMS Retriever or SMS User Consent APIs to ensure continued functionality.

セキュリティ

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

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

Apps should avoid creating excessive numbers of keys in Android Keystore, because it is a shared resource for all apps on the device. Beginning with Android 17, the system enforces a limit on the number of keys an app can own. The limit is 50,000 keys for non-system apps targeting Android 17 (API level 37) or higher, and 200,000 keys for all other apps. System apps have a limit of 200,000 keys, regardless of which API level they target.

If an app attempts to create keys beyond the limit, the creation fails with a KeyStoreException. The exception's message string contains information about the key limit. If the app calls getNumericErrorCode() on the exception, the return value depends on what API level the app targets:

  • Apps targeting Android 17 (API level 37) or higher: getNumericErrorCode() returns the new ERROR_TOO_MANY_KEYS value.
  • All other apps: getNumericErrorCode() returns ERROR_INCORRECT_USAGE.

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

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

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

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

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

Beginning with Android 17, when the device's configuration changes (for example, through rotation), and this is not handled by the app itself, the previous IME visibility is not restored.

If your app undergoes a configuration change that it does not handle, and the app needs the keyboard to be visible after the change, you must explicitly request this. You can make this request in one of the following ways:

  • Set the android:windowSoftInputMode attribute to stateAlwaysVisible.
  • Programmatically request the soft keyboard in your activity's onCreate() method, or add the onConfigurationChanged() method.

手入力

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 では、Bluetooth 接続の切断を自動的に解決するために設計されたシステムレベルの拡張機能である自律的な再ペア設定が導入されています。

以前は、バインドが失われた場合、ユーザーは [設定] に手動で移動して、周辺機器のペア設定を解除してから再度ペア設定する必要がありました。この機能は、Android 16 のセキュリティ強化を基盤として、ユーザーが手動で設定に移動して周辺機器のペア設定を解除し、再ペア設定する必要なく、システムがバックグラウンドで接続を再確立できるようにします。

ほとんどのアプリではコードの変更は必要ありませんが、デベロッパーは Bluetooth スタックの次の動作変更について認識しておく必要があります。

  • 新しいペア設定コンテキスト: ACTION_PAIRING_REQUEST に EXTRA_PAIRING_CONTEXT エクストラが含まれるようになりました。これにより、アプリは標準のペア設定リクエストと自律システムが開始した再ペア設定の試行を区別できます。
  • 条件付き鍵の更新: 再ペア設定が成功し、新しい接続が以前のボンドのセキュリティ レベルを満たすか、それを超える場合にのみ、既存のセキュリティ鍵が置き換えられます。
  • インテントのタイミングの変更: ACTION_KEY_MISSING インテントは、自律的な再ペア設定の試行が失敗した場合にのみブロードキャストされるようになりました。これにより、システムがバックグラウンドでボンドを正常に復元した場合に、アプリで不要なエラー処理を行う必要がなくなります。
  • ユーザー通知: システムは、新しい UI 通知とダイアログを介して再ペア設定を管理します。ユーザーには、再ペア設定の試行を確認するよう求めるメッセージが表示され、再接続を認識できるようになっています。

周辺機器メーカーとコンパニオン アプリ デベロッパーは、ハードウェアとアプリがバインドの移行を適切に処理することを確認する必要があります。この動作をテストするには、次のいずれかの方法でリモート ボンドの損失をシミュレートします。

  • 周辺機器から手動でペア設定情報を削除する
  • [設定] > [接続済みのデバイス] でデバイスのペア設定を手動で解除します。