Android 9（API レベル 28）以降では、アプリ スタンバイ バケットをサポートしています。アプリ スタンバイ バケットは、アプリの最終利用日時と使用頻度に基づいて、リソースに対するアプリのリクエストをシステムが優先順位付けするために使用されます。各アプリは、その使用パターンに基づいて 5 つの優先度バケットのいずれかに振り分けられます。システムは、各アプリが入っているバケットに基づいて、そのアプリで使用できるデバイス リソースを制限します。
優先度バケット
システムは各アプリを優先度バケットに動的に割り当て、必要に応じて再割り当てします。システムは、プリロードされたアプリを活用して各アプリがどの程度使用されるのかを機械学習で判断し、適切なバケットにアプリを割り当てます。
このシステムアプリがデバイスに存在しない場合、デフォルトで最終利用日時に基づいてアプリを並べ替えます。アプリは、アクティブになるほど優先度の高いバケットに割り当てられ、多くのシステム リソースを利用できるようになります。特に、このバケットによって、アプリのジョブが実行される頻度、アプリがアラームをトリガーする頻度が決まります。こうした制限は、デバイスが電池で動作している間にのみ適用されます。デバイスの充電中は、どの制限も適用されません。
優先度バケットは次のとおりです。
- アクティブ（active）: 使用中であるか最近使用されたアプリ
- ワーキング セット（working set）: 定期的に使用されているアプリ
- 高頻度（frequent）: 毎日ではないが、よく使用されているアプリ
- 低頻度（rare）: あまり使用されていないアプリ
- 制限付き（restricted）: システム リソースを大量に消費するか、望ましくない動作を引き起こす可能性があるアプリ
優先バケット以外にも、インストールされたものの実行されていないアプリ専用の未使用バケットがあります。システムはこうしたアプリに厳しい制限を課しています。
以下の説明は、予測不可能な場合についてのものです。これに対し、機械学習を使用して動作を予測する場合、最近使用されたかどうかではなく、ユーザーの次のアクションを予測してバケットが選択されます。たとえば、最近使用されたアプリでも、機械学習で数時間は使用されないと予測されて、低頻度バケットに入れられる可能性があります。
アクティブ
アプリが使用中であるか最近使用された場合、または次のいずれかが行われた場合には、アクティブ バケットに入ります。
- アクティビティを起動する
- 長時間実行フォアグラウンド サービスを実行する
- ユーザーが通知からタップした
アプリがアクティブ バケット内にある場合、システムはアプリのジョブやアラームに最小限の制限を適用します。
- Android 16（API レベル 36）以降では、アクティブなバケット内のアプリによって開始されたバックグラウンド ジョブには、十分なランタイム クォータが割り当てられます。これには、
JobSchedulerで直接スケジュールされたジョブだけでなく、WorkManager やDownloadManagerなどの他のライブラリによって作成されたジョブも含まれます。
ユーザーの操作でアプリをアクティブとして割り当てる
Android 9（API レベル 28）以降では、ユーザーが特定の方法でアプリを操作した場合に、システムはアプリを一時的にアクティブ バケットに入れます。ユーザーがアプリの操作を停止した後、使用履歴に基づいてアプリはバケットに振り分けられます。
このシステム動作をトリガーする操作の例を次に示します。
ユーザーがアプリから送信された通知をタップした。
ユーザーがメディアボタンをタップして、アプリのフォアグラウンド サービスを操作した。
ユーザーが Android Automotive OS の操作中にアプリに接続し、アプリでフォアグラウンド サービスまたは
CONNECTION_TYPE_PROJECTIONのいずれかが使用された。
ワーキング セット
アプリが頻繁に実行されているもののアクティブではない場合、ワーキング セット バケットに入ります。たとえば、ユーザーがほぼ毎日起動するソーシャル メディア アプリは、ワーキング セットに入っている可能性が高くなります。アプリが間接的に使用される場合も、ワーキング セット バケットに昇格されます。
アプリがワーキング セット内にある場合、システムはジョブの実行とアラームのトリガーの機能に緩やかな制限を加えます。詳細については、電源管理リソースの上限をご覧ください。
高頻度
アプリが毎日ではなくとも定期的に使用される場合、高頻度バケットに入ります。たとえば、ユーザーがジムで実行するワークアウト記録アプリは、高頻度バケットに入っている可能性があります。
アプリが高頻度バケット内にある場合、システムはジョブの実行とアラームのトリガーの機能により強い制限を加えます。詳細については、電源管理リソースの上限をご覧ください。
低頻度
アプリがあまり使用されない場合、低頻度バケットに入ります。たとえば、ユーザーが滞在中にしか実行しないホテルアプリは低頻度バケットに入ります。
アプリが低頻度バケット内にある場合、システムは、ジョブの実行とアラームのトリガーの機能に厳重な制限を加えます。また、アプリのインターネットへの接続機能も制限します。詳細については、電源管理リソースの上限をご覧ください。
制限付き
Android 12（API レベル 31）で追加されたこのバケットは、すべてのバケットの中で、優先度が最も低く制限が最も多いバケットです。システムは、ユーザーがアプリを操作する頻度など、アプリの動作を考慮して、制限付きバケットに入れるかどうかを判断します。
Android 13（API レベル 33）以降では、アプリが除外の対象である場合を除き、次のような状況の場合にシステムはアプリを制限付きバケットに入れます。
ユーザーが特定の日数の間、アプリを操作していない。Android 12（API レベル 31）、12L（API レベル 32）では、45 日間です。Android 13 では、8 日間に短縮されています。
システムがアプリを制限付きバケットに入れた場合は、次の制限が適用されます。
- 1 日に 1 回、10 分間のバッチ セッションでジョブを実行できます。このセッションでは、アプリのジョブが他のアプリのジョブとグループ化されます。
- 制限付きジョブは単独では実行されません。同時に実行または保留するジョブが少なくとも 1 つ必要です（他のジョブを含めることができます）。
- 制限の少ないバケットに配置された場合に比べて、アプリが実行できる優先ジョブが少なくなります。
- アプリはアラームを 1 日に 1 回呼び出すことができます。このアラームは、正確なアラームまたは不正確なアラーム、いずれの可能性もあります。
制限付きバケットの適用対象外
次の種類のアプリは、制限付きバケットの対象から除外され、Android 12 以降でも、操作されなかった場合のトリガーをバイパスします。
- コンパニオン デバイス アプリ
- デバイス上でデモモードで実行されているアプリ
- デバイス所有者アプリ
- プロファイル所有者アプリ
- 永続アプリ
- VPN アプリ
ROLE_DIALERロールを持つアプリ- ユーザーがシステム設定で「制限なし」の機能を利用することを明示的に指定したアプリ
- アクティブなウィジェットがあるアプリ
- 次の権限の 1 つ以上が付与されているアプリ:
優先度バケットを評価する
アプリが割り当てられているバケットを確認するには、次のいずれかを行います。
getAppStandbyBucket()を呼び出します。ターミナル ウィンドウで次のコマンドを実行します。
adb shell am get-standby-bucket PACKAGE_NAME
STANDBY_BUCKET_ACTIVE（10）より大きい値を持つアプリ スタンバイ バケットにアプリが配置されるたびに、アプリに制限が加えられます。
おすすめの方法
アプリが Doze およびアプリ スタンバイのおすすめの方法に従っている場合、後の電源管理機能は難しいものではありません。ただし、以前は正常に機能していたアプリの動作に、問題が発生する場合があります。
- システムを操作してアプリを特定のバケットに入れようとしないでください。システムの優先順位の付け方は変更できるため、どのデバイス メーカーも、独自のアルゴリズムで独自のバケットアプリを作成する可能性があります。そのようなことはせず、アプリはどのバケット内にあっても適切に動作することが重要です。
- アプリにランチャー アクティビティがない場合、アクティブ バケットに昇格することはありません。そのようなアクティビティを持たせるよう、アプリの再設計を検討してください。
ユーザーがアプリの通知を操作できない場合、アクティブ バケットへのアプリの昇格もトリガーできません。この場合は、ユーザーが操作できるように一部の通知を再設計することを検討してください。ガイドラインについては、マテリアル デザインの通知のデザイン パターンをご覧ください。
優先度の高い Firebase Cloud Messaging（FCM）メッセージを受信してもアプリに通知が表示されない場合、ユーザーはアプリを操作してアクティブ バケットに昇格させることはできません。実際は、優先度の高い FCM メッセージを使用するのは、ユーザーに通知をプッシュしたいときだけなので、このような状況は発生しません。12L（API レベル 32）以前では、ユーザー操作をトリガーしない場合に FCM メッセージを高優先度として不適切にマークすると、それ以降のメッセージの優先順位が低下する場合があります。
アプリが複数のパッケージに分割されている場合、それらのパッケージは異なるバケットに入っており、アクセスレベルが異なる可能性があります。さまざまなバケットに割り当てられたパッケージを使用してこれらのアプリをテストし、アプリが適切に動作することを確認してください。