Android 17 プラットフォームには、アプリに影響を与える可能性のある動作変更が含まれています。
下記の動作変更は、Android 17 上で稼働するすべてのアプリに適用されます。
targetSdkVersionに関係なく。該当する場合は、アプリをテストし、必要に応じて修正して、これらの変更に対応する必要があります。
Android 17 をターゲットとするアプリにのみ影響する動作変更のリストも必ずご確認ください 。
セキュリティ
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 通知とダイアログを使用して再ペア設定を管理します。ユーザーには、再接続を認識できるように、再ペア設定の試行の確認を求めるメッセージが表示されます。
周辺機器メーカーとコンパニオン アプリのデベロッパーは、ハードウェアとアプリがペア設定の移行を適切に処理することを確認する必要があります。この動作をテストするには、次のいずれかの方法でリモートでのペア設定の解除をシミュレートします。
- 周辺機器からペア設定情報を手動で削除する
- [設定] > [接続済みのデバイス] でデバイスのペア設定を手動で解除する