Android 9（API レベル 28）では、新しい電池管理機能であるアプリ スタンバイ バケットが導入されました。アプリ スタンバイ バケットは、システムが、リソースに対するアプリのリクエストをアプリの最終利用時刻と使用頻度に基づいて優先順位付けするために使用されます。各アプリは、その使用パターンに基づいて 5 つの優先度バケットのいずれかに振り分けられます。システムは、各アプリが入っているバケットに基づいて、そのアプリで使用できるデバイス リソースを制限します。
優先度バケット
システムは各アプリを優先度バケットに動的に割り当て、必要に応じて再割り当てします。システムは、各アプリが使用される確率を機械学習で求めるプリロードされたアプリを利用して、アプリを適切なバケットに割り当てます。このシステムアプリがデバイスに存在しない場合、デフォルトでは最終利用時刻に基づいてアプリを並べ替えます。アプリは、アクティブになるほど高い優先度を与えるバケットに割り当てられ、多くのシステム リソースを利用できるようになります。特に、このバケットによって、アプリのジョブが実行される頻度、アプリがアラームをトリガーする頻度、アプリが優先度の高い Firebase Cloud Messaging メッセージを受信できる頻度が決まります。こうした制限は、デバイスが電池で動作している間にのみ適用されます。デバイスの充電中は、どの制限も適用されません。
注: すべてのメーカーは、アクティブでないアプリをバケットに割り当てる方法について独自の基準を設定できます。アプリがどのバケットに割り当てられるかに影響を与えようとしないでください。そうではなく、アプリがどのバケットにあっても適切な振る舞いをするようにしてください。アプリは
UsageStatsManager.getAppStandbyBucket() を呼び出すことで、現在どのバケットにあるかを確認できます。
バケットには次の種類があります。
- アクティブ（active）: 現在使用されている、またはごく最近使用されたアプリ
- ワーキング セット（working set）: 定期的に使用されているアプリ
- 高頻度（frequent）: 毎日ではないが、よく使用されるアプリ
- 低頻度（rare）: あまり使用されないアプリ
さらに、インストールされているのに実行されたことがないアプリのために、未使用バケットという特別なバケットがあります。システムはこうしたアプリに厳しい制限を課しています。
注: Doze ホワイトリストに登録されているアプリには、アプリ スタンバイ バケットに基づく制限が適用されません。
注: 以下の説明は、予測不可能な場合を対象としています。これに対し、機械学習を使用して動作を予測する場合、最近使用されたかどうかではなく、ユーザーの次のアクションを予測してバケットが選択されます。たとえば、最近使用されたアプリが、機械学習で数時間は使用されないと予測されて、低頻度バケットに入れられる可能性があります。
アクティブ
アプリが、ユーザーによって現在使用されているか、最近使用された場合、アクティブ バケットに入ります。次に例を示します。
- アプリがアクティビティを開始した
- アプリがフォアグラウンド サービスを実行している
- アプリに、フォアグラウンド アプリで使用されるコンテンツ プロバイダに関連付けられた同期アダプタがある
- ユーザーがアプリからの通知をクリックする
アプリがアクティブ バケット内にある場合、システムはアプリのジョブ、アラーム、FCM メッセージに制限を加えません。
ワーキング セット
アプリが頻繁に実行されているものの、現在アクティブでない場合、ワーキング セット バケットに入ります。たとえば、ユーザーがほぼ毎日起動するソーシャル メディア アプリは、ワーキング セットに入っている可能性が高くなります。アプリが間接的に使用される場合も、ワーキング セット バケットに昇格されます。
アプリがワーキング セット内にある場合、システムはジョブの実行とアラームのトリガーの機能に緩やかな制限を加えます。詳しくは、電源管理の制限をご覧ください。
高頻度
アプリが毎日ではないが定期的に使用される場合、高頻度バケットに入ります。たとえば、ユーザーがジムで実行するワークアウト記録アプリは、高頻度バケットに入っている可能性があります。
アプリが高頻度バケット内にある場合、システムはジョブの実行とアラームのトリガーの機能により強い制限を加えます。また、優先度の高い FCM メッセージにも上限を与えます。詳しくは、電源管理の制限をご覧ください。
低頻度
アプリがあまり使用されない場合、低頻度バケットに入ります。たとえば、滞在中にしか実行しないホテルアプリは低頻度バケットに入ります。
アプリが低頻度バケット内にある場合、システムは、ジョブの実行、アラームのトリガー、優先度の高い FCM メッセージの受信の機能に強い制限を加えます。 また、アプリのインターネットに接続する機能も制限します。詳しくは、電源管理の制限をご覧ください。
運用ガイド
アプリがすでに Doze およびアプリ スタンバイのおすすめの方法に従っている場合、新しい電源管理機能の扱いは難しくありません。ただし、以前は正常に機能していたアプリの動作に、問題が発生する場合があります。
- システムを操作してアプリをいずれかのバケットに入れようとしないでください。システムがバケットに振り分ける方法は変更される可能があり、すべてのデバイス メーカーが独自のアルゴリズムで独自のバケットアプリを作成することもできます。そのようなことはせず、アプリがどのバケット内にあっても適切な振る舞いをするようにしてください。
- アプリにランチャー アクティビティがない場合、アクティブ バケットに昇格することはありません。アプリを再設計して、ランチャー アクティビティを持たせることをおすすめします。
- アプリの通知でアクションを実行できない場合、ユーザーは、通知を操作してアプリをアクティブ バケットに昇格するきっかけを与えることができません。この場合、ユーザーが応答できるように通知を再設計することをおすすめします。ガイドラインについては、マテリアル デザインの通知のデザイン パターンをご覧ください。
- 同様に、優先度の高い FCM メッセージを受信してもアプリに通知が表示されない場合、アプリを操作してアクティブ バケットに昇格する機会がユーザーに与えられません。実際は、優先度の高い FCM メッセージを使用するのは、ユーザーに通知を表示したいときだけなので、このような状況は発生しません。ユーザー操作のきっかけを与えない FCM メッセージを不適切に高優先度としてマークすると、他の問題を発生させる可能性があります。たとえば、アプリが割り当てを使い果たしてしまい、真に緊急の FCM メッセージが通常の優先度として処理される可能性があります。
注: ユーザーが通知を繰り返し閉じると、システムはその通知を今後ブロックするかどうかをユーザーに選択させます。 アプリをアクティブ バケットに留めるためだけに、ユーザーに不要な通知を送らないでください。
- アプリが複数のパッケージに分割されている場合、それらのパッケージは異なるバケットに入っている可能性があるため、アクセスレベルが異なる可能性があります。パッケージをさまざまなバケットに割り当ててアプリをテストし、アプリが適切な振る舞いをすることを確認してください。