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 Panda では、Android Studio Profiler に LeakCanary 統合が専用タスクとして直接追加され、IDE 内でコンテキスト化され、ソースコードと完全に統合されています。
セキュリティ
Android 17 では、デバイスとアプリのセキュリティが次のように改善されています。
usesClearTraffic の非推奨プラン
今後のリリースで、usesCleartextTraffic 要素は非推奨になる予定です。暗号化されていない（HTTP）接続を行う必要があるアプリは、ネットワーク セキュリティ構成ファイルを使用するように移行する必要があります。このファイルを使用すると、アプリがクリアテキスト接続を行う必要があるドメインを指定できます。
ネットワーク セキュリティ構成ファイルは API レベル 24 以上でのみサポートされます。アプリの最小 API レベルが 24 未満の場合は、次の両方を行う必要があります。
usesCleartextTraffic属性をtrueに設定します。- ネットワーク構成ファイルを使用する
アプリの最小 API レベルが 24 以上の場合、ネットワーク構成ファイルを使用できるため、usesCleartextTraffic を設定する必要はありません。
暗黙的な URI 権限付与の制限
現在、アプリが Send、SendMultiple、または ImageCapture のアクションを含む URI でインテントを起動すると、システムはターゲット アプリに読み取りと書き込みの URI 権限を自動的に付与します。この動作は Android 18 で変更される予定です。そのため、アプリはシステムに付与を任せるのではなく、関連する URI 権限を明示的に付与することをおすすめします。
アプリごとのキーストアの上限
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 には、アプリがキーボードやタッチパッドなどの手入力デバイスとやり取りする方法に影響する以下の変更が含まれています。
ポインタ キャプチャ中、タッチパッドはデフォルトで相対イベントを配信する
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 通知とダイアログを介して再ペア設定を管理します。ユーザーには、再ペア設定の試行を確認するよう求めるメッセージが表示され、再接続を認識できるようになっています。
周辺機器メーカーとコンパニオン アプリ デベロッパーは、ハードウェアとアプリがバインドの移行を適切に処理することを確認する必要があります。この動作をテストするには、次のいずれかの方法でリモート ボンドの損失をシミュレートします。
- 周辺機器から手動でペア設定情報を削除する
- [設定] > [接続済みのデバイス] でデバイスのペア設定を手動で解除します。