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

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

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

コア機能

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

アプリのメモリ上限

Android 17 では、アプリと Android ユーザー向けに、より安定した決定論的な環境を構築するため、デバイスの合計 RAM に基づくアプリのメモリ上限が導入されました。これらの上限は、メモリリークやその他の外れ値がシステム全体の不安定性を引き起こし、UI のスタッタリング、バッテリー消費の増加、アプリの強制終了につながる前に、それらに焦点を当てています。ほとんどのアプリ セッションへの影響は最小限になると予想されますが、メモリのベースラインを確立するなど、メモリに関する次のベスト プラクティスをおすすめします。

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

アプリのメモリを管理するのドキュメントでは、アプリのメモリの問題を診断し、リソース消費を最適化するための情報を提供しています。

メモリ制約下でのアプリの動作をテストする

Android Debug Bridge（adb）を使用すると、メモリ制限を課すデバイスでメモリ制限を調整または無効にできます。シェルコマンド am には、メモリ上限を調整するための 3 つのサブコマンドがあります。（これらのコマンドは、メモリ制限を課していないデバイスには影響しません）。

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

メモリ リミッターに一部またはすべてのプロセスを無視するよう指示します。UID（Android ユーザー ID）を渡すと、メモリ制限ツールは、その UID に関連付けられているすべてのプロセスに対する強制適用を無視するよう指示されます。all（すべてのアプリを無視）または none（アプリを無視しない）を渡すこともできます。none を渡すと、am memory-limiter ignore の以前の呼び出しがオーバーライドされます。

メモリ制限ツールに UID を無視するよう指示した場合でも、am memory-limiter manual を呼び出すことで、アプリ内のプロセスに手動でメモリ上限を適用できます。

manual

指定された PID（プロセス ID）のプロセスにメモリ制約を課すようシステムに指示します。メモリ制約は MB 単位の整数で指定します。たとえば、30 を渡すと、プロセスが 30 MB のメモリに制限されます。max を渡すと、そのプロセスのメモリ上限がすべて削除されます。none を渡すと、プロセスに設定された手動制限が削除され、システムのデフォルトの制限（設定されている場合）が復元されます。

status

メモリ制限の現在のステータスをレポートします。ステータスには、表示されるプロセスと表示されないプロセスに課せられたメモリ制限が含まれます。

プライバシー

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 の非推奨プラン

In a future release, we plan to deprecate the usesCleartextTraffic element. Apps that need to make unencrypted (HTTP) connections should migrate to using a network security configuration file, which lets you specify which domains your app needs to make cleartext connections to.

Be aware that network security configuration files are only supported on API levels 24 and higher. If your app has a minimum API level lower than 24, you should do both of the following:

  • Set the usesCleartextTraffic attribute to true
  • Use a network configuration file

If your app's minimum API level is 24 or higher, you can use a network configuration file and you don't need to set 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 密钥库中创建过多的密钥，因为它是设备上所有应用的共享资源。从 Android 17 开始，系统会强制限制应用可拥有的密钥数量。对于以 Android 17（API 级别 37）或更高版本为目标平台的非系统应用，密钥数量上限为 50,000 个；对于所有其他应用，密钥数量上限为 200,000 个。无论系统应用以哪个 API 级别为目标，其密钥数量上限均为 20 万。

如果应用尝试创建超出限制的密钥，则创建会失败并显示 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 には、キーボードやタッチパッドなどのヒューマン入力デバイスとアプリがやり取りする方法に影響する次の変更が含まれています。

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

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 では、メディアの動作が次のように変更されています。

バックグラウンド音声の強化

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 通知とダイアログを介して再ペア設定を管理します。ユーザーには、再ペア設定の試行を確認するよう求めるメッセージが表示され、再接続を認識できるようになっています。

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

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