システムは、デバイスの状態、アプリの状態、アプリのスタンバイ バケットに基づいて、リソースに対するアプリのリクエストを優先順位付けします。
Android システムは、2 つの異なる方法でリソースの上限を適用できます。リソース使用率を最適化する方法の 1 つは、デバイスが低消費電力のデバイス状態（Doze モードなど）を終了するまで、処理の実行を延期することです。たとえば、通常のジョブと不正確なアラームは延期され、デバイスがスリープ モードを終了した後に実行されます。
別の方法として、アプリの現在のスタンバイ バケットに基づいて、アプリがデバイスを起動して処理を行う頻度を減らすこともできます。システムは、頻度（アプリがデバイスをスリープ解除する頻度）と合計時間（デバイスがスリープ解除された状態が続く時間）の両方を減らすことができます。たとえば、アプリがまれなスタンバイ バケットにある場合、アプリは 24 時間のローリング期間で合計 10 分間、スケジュールされたジョブを実行できます。
WorkManager は、アプリが可視状態になっていないときに JobScheduler を使用してタスクをスケジュール設定するため、ワーカーはジョブリソースの上限の影響を受けます。
制限について詳しくは、以下をご覧ください。
デバイスの状態とアプリの状態は、アプリのスタンバイ バケットの上限よりも優先される場合があります。たとえば、デバイスが充電中の場合、システムは、まれなスタンバイ バケット内のアプリが 24 時間のローリング期間で 10 分を超えるジョブを実行することを許可します。
動作が変更され、リソースの上限にも影響しています。詳細については、リソースの上限に影響する Android の動作の変更をご覧ください。
デバイスの状態に基づくリソースの上限
また、デバイスの状態に基づいてリソースの上限を免除または適用することもできます。たとえば、充電中のデバイスには、アプリ スタンバイ バケットに関係なく、リソースへの無制限のアクセス権が付与されます。
デバイスの状態 |
仕事 |
アラーム |
ネットワーク アクセス |
Firebase Cloud Messaging |
充電 |
制限付きスタンバイ バケットを除き、実行数の上限なし |
ユーザーがアプリのバッテリーを手動で制限する場合を除き、すべてのスタンバイ バケットとプロセス状態に実行制限なし |
制限なし |
制限なし |
画面がオン |
実行上限はスタンバイ バケットに基づいて適用されます。 |
実行上限は、アプリのプロセスとスタンバイ バケットに基づいて適用されます。 |
アクセスはスタンバイ バケットまたはアプリのプロセスの状態によって異なります |
制限なし |
画面がオフで、スリープ状態が有効 |
実行上限はスタンバイ バケットに基づいて適用され、実行はドーズ メンテナンス期間に延期されます。 |
実行上限はスタンバイ バケットに基づいて適用されます。 通常のアラーム: スリープ メンテナンスの時間枠まで延期 アイドル状態時のアラーム: 1 時間あたり 7 回に制限 |
スリープ中は制限される |
高優先度: 実行数の上限なし 通常の優先度: スリープ モードのメンテナンスの時間枠まで延期 |
アプリの状態に基づくリソースの上限
システムがアプリ スタンバイ バケットのリソース上限を適用するかどうかは、アプリプロセスの重要性に応じて異なります。プロセスの重要度のレベルについては、ActivityManager.RunningAppProcessInfo.importance をご覧ください。
デバイスのユーザーは、アプリの電力管理の最適化を手動でオーバーライドすることもできます。これは、アプリのスタンバイ バケットの上限に優先されます。
アプリの状態 |
仕事 |
アラーム |
ネットワーク |
アプリのプロセスが可視状態またはフォアグラウンド状態である |
実行の上限なし |
フリークエンシーの上限なし |
制限なし |
アプリのプロセスがフォアグラウンド サービスを実行している |
実行上限はスタンバイ バケットに基づいて適用されます*** |
フリークエンシーの上限はスタンバイ バケットに基づいて適用されます |
制限なし |
ユーザーがアプリのバッテリーを手動で制限している |
実行が制限されている |
実行が制限されている |
アクセスはスタンバイ バケットの動作によって異なります |
ユーザーがアプリのバッテリーの制限を手動で解除する |
実行上限が緩和されている*** |
実行の上限なし |
デバイスがデータセーバー モードでない限り、無制限 |
*** ジョブの実行割り当ての動作が Android 16 で変更されました。Android 16 より前は、アプリがフォアグラウンド サービスを実行している場合や、ユーザーがアプリのバッテリーを制限していない場合、実行上限はありませんでした。
アプリ スタンバイ バケットに基づくリソースの上限
注: この表の値は、実行時間の保証ではありません。他のデバイスの状態やバケットの変更がリソース制約に影響する可能性があるためです。また、これらの値は Android の今後のリリースで変更される可能性があります。
通常のジョブ、優先ジョブ、アラーム、ネットワーク アクセスは、アプリ スタンバイ バケットに基づいて制限できます。アプリのスタンバイ バケットがアプリに与える影響を把握するには、これらの電力管理の制限をガイドラインとして使用します。最適なパフォーマンスを得るには、アプリ スタンバイのベスト プラクティスに準拠し、タスク スケジューリング API のバッテリー使用量を最適化します。
Android 13 以降、アプリのスタンバイ バケットは、アプリが使用できる優先度の高い FCM の数を決定するものではなくなりました。
アプリ スタンバイ バケット |
正社員* |
優先ジョブ** |
アラーム |
ネットワーク |
アクティブ: |
60 分間の累積で最大 20 分*** |
24 時間以内に最大 30 分*** |
実行の上限なし |
制限なし |
ワーキング セット: |
4 時間の期間で最大 10 分 |
24 時間以内に最大 15 分 |
1 時間あたり 10 回に制限 |
制限なし |
高頻度: |
12 時間以内に最大 10 分 |
24 時間以内に最大 10 分 |
1 時間あたり 2 回に制限 |
制限なし |
低頻度: |
24 時間以内に最大 10 分 |
24 時間以内に最大 10 分 |
1 時間あたり 1 回に制限 |
無効 |
制限付き: |
1 日 1 回、最大 10 分 |
24 時間の移動ウィンドウで最大 5 分 |
無効 |
* 通常のジョブは、JobScheduler の setUserInitiated(true) フラグまたは setExpedited(true) フラグ、または WorkManager のエクスプレス ワーカーを使用していないジョブを表します。
** エクスプレス ジョブには通常のジョブとは別の実行上限があります。エクスプレスの上限が使い果たされた後も通常のジョブの実行上限を使用して実行を続行するように、WorkManager で設定できます。
*** ジョブの実行割り当ての動作が Android 16 で変更されました。Android 16 より前は、アプリがアクティブ スタンバイ バケットにある場合の実行上限はありませんでした。
リソースの上限に影響する Android の動作の変更
以下の Android のアップデートで、アプリのリソースの上限が変更されました。
Android 16
Android では、次の要素に基づいて通常のジョブ実行とエクスプレス ジョブ実行のランタイム割り当てを調整しました。
- アプリがどのアプリ スタンバイ バケットに属しているか
- アプリがトップ状態のときにジョブの実行が開始された場合
- フォアグラウンド サービスを実行中にジョブが実行されている場合
Android 13
優先度の高い Firebase Cloud Messaging（FCM）の割り当ての動作の変更
- アプリ スタンバイ バケットは、アプリが使用できる優先度の高い FCM の数を決定するものではなくなりました。
- 通知につながらない優先度の高いメッセージをアプリが継続的に送信していることが検出された場合は、システムが優先度の高いメッセージをダウングレードするようになりました
- 優先度の高いメッセージの最新のガイドラインについては、メッセージの優先度を設定、管理するをご覧ください。
Android 9
Android 9 では、新しい電池管理機能であるアプリ スタンバイ バケットが導入されました。アプリ スタンバイ バケットは、システムが、リソースに対するアプリのリクエストをアプリの最終利用時刻と使用頻度に基づいて優先順位付けするために使用されます。各アプリは、その使用パターンに基づいて 5 つの優先度バケットのいずれかに振り分けられます。システムは、各アプリが入っているバケットに基づいて、そのアプリで使用できるデバイス リソースを制限します。