アプリ スタンバイ バケット

Android 9（API レベル 28）以降では、アプリ スタンバイ バケットをサポートしています。アプリ スタンバイ バケットは、システムが、リソースに対するアプリのリクエストをアプリの最終利用時刻と使用頻度に基づいて優先順位付けするために使用されます。各アプリは、その使用パターンに基づいて 5 つの優先度バケットのいずれかに振り分けられます。システムは、各アプリが入っているバケットに基づいて、そのアプリで使用できるデバイス リソースを制限します。

優先度バケット

システムは各アプリを優先度バケットに動的に割り当て、必要に応じて再割り当てします。システムは、各アプリが使用される確率を機械学習で求めるプリロードされたアプリを利用して、アプリを適切なバケットに割り当てます。このシステムアプリがデバイスに存在しない場合、デフォルトでは最終利用時刻に基づいてアプリを並べ替えます。アプリは、アクティブになるほど高い優先度を与えるバケットに割り当てられ、多くのシステム リソースを利用できるようになります。特に、このバケットによって、アプリのジョブが実行される頻度、アプリがアラームをトリガーする頻度が決まります。こうした制限は、デバイスが電池で動作している間にのみ適用されます。デバイスの充電中は、どの制限も適用されません。

注: すべてのメーカーは、アクティブでないアプリをバケットに割り当てる方法について独自の基準を設定できます。アプリがどのバケットに割り当てられるかに影響を与えようとしないでください。そうではなく、アプリがどのバケットにあっても適切な振る舞いをするようにしてください。アプリは UsageStatsManager.getAppStandbyBucket() を呼び出すことで、現在どのバケットにあるかを確認できます。

バケットには次の種類があります。

1. アクティブ（active）: 現在使用されている、またはごく最近使用されたアプリ
2. ワーキング セット（working set）: 定期的に使用されているアプリ
3. 高頻度（frequent）: 毎日ではないが、よく使用されるアプリ
4. 低頻度（rare）: あまり使用されないアプリ
5. 制限あり（restricted）: アプリがシステム リソースを大量に消費するか、望ましくない動作を引き起こす可能性がある

さらに、インストールされているのに実行されたことがないアプリのために、未使用バケットという特別なバケットがあります。システムはこうしたアプリに厳しい制限を課しています。

注: Doze 除外リストに登録されているアプリには、アプリ スタンバイ バケットに基づく制限が適用されません。

注: 以下の説明は、予測不可能な場合を対象としています。これに対し、機械学習を使用して動作を予測する場合、最近使用されたかどうかではなく、ユーザーの次のアクションを予測してバケットが選択されます。たとえば、最近使用されたアプリが、機械学習で数時間は使用されないと予測されて、低頻度バケットに入れられる可能性があります。

アクティブ

アプリが、ユーザーによって現在使用されているか、最近使用された場合、アクティブ バケットに入ります。次に例を示します。

• アプリがアクティビティを開始した
• アプリがフォアグラウンド サービスを実行している
• アプリに、フォアグラウンド アプリで使用されるコンテンツ プロバイダに関連付けられた同期アダプタがある
• ユーザーがアプリからの通知をクリックする

アプリがアクティブ バケット内にある場合、システムはアプリのジョブやアラームに制限を加えません。

ユーザーの操作でアプリを「アクティブ」バケットに入れる

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 日です。

  注: デバイスがオフになっていた時間は、アプリが操作されなかった時間による制限にカウントされません。

• アプリが 24 時間以内にブロードキャストまたはバインディングを過度に呼び出した。

システムがアプリを制限付きバケットに入れた場合は、次の制限が適用されます。

• 1 日に 1 回、10 分間のバッチ セッションでジョブを実行できます。このセッションでは、アプリのジョブが他のアプリのジョブとグループ化されます。
  • 制限付きジョブは単独で実行されません。同時に実行 / 保留中のジョブが少なくとも 1 つ必要です（他のジョブを含めることができます）。
• 制限の少ないバケットに配置された場合に比べて、アプリが実行できる優先ジョブが少なくなります。
• アプリはアラームを 1 日に 1 回呼び出すことができます。このアラームは、正確なアラームまたは不正確なアラームのいずれかです。

注: 他のバケットとは異なり、制限付きバケットには、デバイスが充電中であっても電源管理に関する制限が適用されます。ただし、デバイスが充電中の場合、アイドル状態の場合、定額制ネットワーク上にある場合は、制限が緩和されます。

制限付きバケットの適用対象外

次の種類のアプリは、「制限付き」アプリ スタンバイ バケットの適用対象から除外され、Android 12 以降でも、操作されなかった場合のトリガーをバイパスします。

• コンパニオン デバイスのアプリ
• デバイス上でデモモードで実行されているアプリ
• デバイス所有者アプリ
• プロファイル所有者アプリ
• 永続的なアプリ
• VPN アプリ
• ROLE_DIALER ロールを持つアプリ
• ユーザーがシステム設定で「制限なし」の機能を利用することを明示的に指定したアプリ
• アクティブなウィジェットがあるアプリ
• ピクチャー イン ピクチャー（PIP）モードで表示されるアプリ
• 画面上でアクティブなアプリの 1 つであるアプリ
• 次の権限の 1 つ以上が付与されているアプリ:
  • USE_EXACT_ALARM
  • SCHEDULE_EXACT_ALARM
  • ACCESS_BACKGROUND_LOCATION
  • CAMERA
  • RECORD_AUDIO

おすすめの方法

アプリがすでに Doze およびアプリ スタンバイのおすすめの方法に従っている場合、新しい電源管理機能の扱いは難しくありません。ただし、以前は正常に機能していたアプリの動作に、問題が発生する場合があります。

• システムを操作してアプリをいずれかのバケットに入れようとしないでください。システムがバケットに振り分ける方法は変更される可能があり、すべてのデバイス メーカーが独自のアルゴリズムで独自のバケットアプリを作成することもできます。そのようなことはせず、アプリがどのバケット内にあっても適切な振る舞いをするようにしてください。
• アプリにランチャー アクティビティがない場合、アクティブ バケットに昇格することはありません。アプリを再設計して、ランチャー アクティビティを持たせることをおすすめします。
• アプリの通知でアクションを実行できない場合、ユーザーは、通知を操作してアプリをアクティブ バケットに昇格するきっかけを与えることができません。この場合、ユーザーが応答できるように通知を再設計することをおすすめします。ガイドラインについては、マテリアル デザインの通知のデザイン パターンをご覧ください。
• 同様に、優先度の高い Firebase Cloud Messaging（FCM）メッセージを受信してもアプリに通知が表示されない場合、アプリを操作してアクティブ バケットに昇格する機会がユーザーに与えられません。実際は、優先度の高い FCM メッセージを使用するのは、ユーザーに通知を表示したいときだけなので、このような状況は発生しません。12L（API レベル 32）以前では、ユーザー操作のきっかけを与えない FCM メッセージを不適切に高優先度としてマークすると、それ以降のメッセージの優先順位が低下する場合があります。

  注: ユーザーが通知を繰り返し閉じると、システムはその通知を今後ブロックするかどうかをユーザーに選択させます。 アプリをアクティブ バケットに留めるためだけに、ユーザーに不要な通知を送らないでください。

• アプリが複数のパッケージに分割されている場合、それらのパッケージは異なるバケットに入っている可能性があるため、アクセスレベルが異なる可能性があります。パッケージをさまざまなバケットに割り当ててアプリをテストし、アプリが適切な振る舞いをすることを確認してください。

テスト

アプリがどのバケットにあるかを確認するには、次のいずれかを行います。

• getAppStandbyBucket() を呼び出します。

• ターミナル ウィンドウで次のコマンドを実行します。

  adb shell am get-standby-bucket PACKAGE_NAME

値が STANDBY_BUCKET_ACTIVE（10）より大きいアプリ スタンバイ バケットにアプリが配置されるたびに、アプリに制限が加えられます。