Doze Mode: 本質、フェーズ、省電力メカニズム

Doze Modeとは

Doze ModeはAndroidに組み込まれた省電力メカニズムで、デバイスが充電器に接続されておらず、画面がオフで、ユーザーが一定時間デバイスを操作していないときに作動します。Dozeの目的は、バックグラウンドアプリのアクティビティを最小限に抑え、スタンバイモードでのバッテリー寿命を最大化することです。システムはJobScheduler、アカウント同期、AlarmManager、ネットワークリクエストを延期します。

このモードはAndroid 6.0 Marshmallow（API 23）で導入され、その後のバージョンで大幅に改善されました。Android 7.0 Nougatではデバイスの動きに応じて作動する第2フェーズ（Light Doze）が追加されました。Android 8.0ではDozeと連携するバックグラウンドサービスに追加の制限が導入されました。Android 12+ではDozeはユーザーの行動を分析する更新されたバッテリー管理システムと統合されました。

重要な理解点：Doze Modeはアプリを完全に無効にするわけではありません。タスクを延期した状態に移行させますが、プロセスを強制終了することはありません。通知付きのForeground Serviceは動作を継続し、高優先度プッシュ通知（FCM high-priority）は配信され、アラームはスケジュールどおりに作動します。Dozeはユーザーがその時点で見たり期待したりしないバックグラウンド操作にのみ影響します。

作動条件

Doze Modeはすべての条件が満たされると作動します：画面が30分以上オフ（初回作動）、デバイスが静止している（加速度センサーを使用）、充電器に接続されていない。ユーザーが電話を手に取るか充電器を接続すると、Dozeは直ちに無効になります。Android 7+では、デバイスが動いている場合でも、わずか5分のアイドル後にLight Dozeが作動します。

Doze Modeの仕組み

Doze ModeはシステムサービスDeviceIdleControllerを通じてバックグラウンドアクティビティを管理し、センサー、画面、充電器の状態を分析します。すべての作動条件が満たされると、システムはアプリをスタンバイモードに移行させ、そのリクエストをメンテナンスウィンドウにグループ化します。これらのウィンドウ内で、延期されたすべてのタスク（ネットワーク呼び出し、同期、AlarmManager）が一括実行されます。

システムのPowerManagerはDozeから復帰できるアプリを制御します。高優先度プッシュ通知（FCM high-priority）はメッセージ配信のためにデバイスを復帰させることができます。システムはユーザーがバッテリー最適化のWhitelistに追加したアプリについてはDozeを無視します。他のすべてのアプリは次のメンテナンスウィンドウを待つ必要があります。

Deep Dozeのメンテナンスウィンドウの間隔は指数的に増加します：最初のウィンドウは1時間後、2番目は2時間後、3番目は4時間後、最大12時間まで。つまり、デバイスがDozeにある時間が長いほど、アプリがバックグラウンドタスクを実行できる頻度が低くなり、バッテリーを可能な限り積極的に節約します。

ネットワークリクエストへの影響

Doze Modeでは、すべてのネットワークリクエストはメンテナンスウィンドウが開くまで中断されます。唯一の例外はFCM高優先度メッセージ（ペイロードに“high_priority”タグ付き）と、AlarmManagerのsetAndAllowWhileIdle()またはsetExactAndAllowWhileIdle()フラグを持つシグナルです。Retrofit、OkHttp、Volleyによる通常のネットワーク呼び出しはウィンドウが開くまで実行されません。

Doze Modeのフェーズ

Doze Modeは2つのフェーズで構成されます：Light Doze（軽い眠り）とDeep Doze（深い眠り）。各フェーズは独自の制限を課し、異なる作動しきい値を持ちます。フェーズの違いを理解することは、省電力モードに耐性のあるバックグラウンドタスクを設計する開発者にとって重要です。

Light Doze（軽い眠り）

Light Dozeはデバイスの5〜30分のアイドル後（画面オフ、動きなし）に作動します。このフェーズではネットワークリクエストと同期が中断されますが、AlarmManagerとJobSchedulerはわずかな遅延で動作を継続します。アプリはプッシュ通知を受信するか充電器に接続するとLight Dozeから復帰できます。Light Dozeは完全な静止を必要としません。デバイスは動いていても構いません。

Deep Doze（深い眠り）

Deep Dozeはデバイスが静止した状態（加速度センサーが動きを検出しない）で60〜90分のアイドル後に発生します。Deep Dozeでは、システムはタスクの延期において大幅に積極的になります。メンテナンスウィンドウの頻度が低下し（指数的に間隔が増加）、AlarmManagerはsetAndAllowWhileIdle()フラグでのみ作動し、WakeLockは通常通り機能しません。Whitelistにないアプリはバックグラウンドアクティビティをほぼ完全に奪われます。

Doze Modeの制限

Doze Modeはアプリを設計する際に開発者が考慮すべきいくつかのカテゴリの制限を課します。これらの制限を無視すると、バックグラウンドタスクが実行されず、ユーザーはアプリの不正確な動作（更新の欠落、未送信メッセージ、不完全な同期）を目にすることになります。

ネットワーク制限

すべてのネットワークリクエストはメンテナンスウィンドウが開くまでブロックされます。これはHTTP呼び出し、WebSocket接続、ファイルダウンロードに適用されます。例外はFCM高優先度メッセージで、Dozeに依存しないGoogle Play Servicesの別チャネルを通過します。重要なデータ同期には、NetworkType.CONNECTEDポリシーのWorkManagerを使用することを推奨します。

AlarmManagerの制限

Deep DozeのAlarmManagerは、setAndAllowWhileIdle()およびsetExactAndAllowWhileIdle()メソッドで作成されたものを除き、すべてのアラームを延期します。ただし、これらのメソッドにも制限があります。アプリごとに9分間に1回以上作動しません。Deep DozeでのsetExact()による正確なアラームは指定時間に作動することを保証しません。

WakeLockの制限

WakeLockはDoze Modeで異常な動作をします：システムはWhitelist外のアプリに対してウェイクロックを保持しません。アプリが正しくPARTIAL_WAKE_LOCKを取得していても、Deep Dozeが開始されるとシステムが強制的に解放する可能性があります。Dozeでタスクの実行を保証する唯一の方法は、通知付きのForeground Serviceを使用することです。

• ネットワーク — FCM high-priorityを除くすべてのリクエストはメンテナンスウィンドウまで延期
• AlarmManager — 正確なアラームは延期。setAndAllowWhileIdle — 1/9分以内
• WakeLock — Whitelist外のアプリに対して強制解放
• JobScheduler — タスクは指数的間隔でメンテナンスウィンドウにグループ化
• 同期 — Dozeから復帰するまでAccount SyncManagerは中断

Whitelistと例外

DozeのWhitelistは、システムが最小限の制限で省電力モードでのバックグラウンドアクティビティを許可するアプリのリストです。ユーザーは設定→バッテリー→バッテリー最適化から手動でアプリをリストに追加できます。システムアプリ、ランチャー、Google Play ServicesはデフォルトでWhitelistに含まれています。

開発者はIntent ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONSを使用したシステムダイアログを通じてWhitelistへの追加をリクエストできます。そのためにはマニフェストでREQUEST_IGNORE_BATTERY_OPTIMIZATIONS権限が必要です。ただし、Googleは正当な理由なしに例外をリクエストすることを推奨していません。この機能を乱用するアプリはGoogle Playへの公開時に拒否されるリスクがあります。

Whitelistがなくても、アプリはFCM高優先度を使用してデバイスをDozeから復帰させることができます。そのようなメッセージごとにアプリにはタスク実行のための短いウィンドウ（10〜30秒）が与えられます。より長い操作には、アプリはForeground Serviceを起動する必要があり、Dozeのメンテナンスウィンドウ内で動作を継続します。Googleは特定の種類のアプリ（ナビゲーション、医療、メッセージング）に対して免除メカニズムも提供しています。

Whitelistステータスの確認方法

アプリがバッテリー最適化のWhitelistに含まれているか確認するには、powerManager.isIgnoringBatteryOptimizations()メソッドを使用します。メソッドがfalseを返す場合、アプリはすべてのDoze制限の対象となります。trueを返す場合、アプリはDeep Dozeでも制限なくWakelock、AlarmManager、ネットワークを使用できます。ただし、この特権を乱用するとユーザーから低評価を受けることになります。

Doze Modeのテスト

Doze Modeでのアプリの動作のテストは必須の開発ステップです。Dozeはバックグラウンド機能を妨害する可能性があるためです。AndroidはADBを介したコマンドラインツールを提供し、デバイスをLight DozeとDeep Dozeに強制移行できます。テストはAndroid 6.0+の実機またはエミュレータで実行する必要があります。

Light Dozeに入るには、コマンドadb shell dumpsys deviceidle step lightを使用します。Deep Dozeにはadb shell dumpsys deviceidle step deep。コマンドadb shell dumpsys deviceidle force-idle deepは標準タイムアウトを待たずにデバイスを即座にDeep Dozeに移行します。テスト後はコマンドadb shell dumpsys deviceidle unforceでDozeを終了します。

# Light Dozeに強制移行
$ adb shell dumpsys deviceidle step light

# Deep Dozeに強制移行
$ adb shell dumpsys deviceidle step deep

# 即座にDeep Dozeに移行
$ adb shell dumpsys deviceidle force-idle deep

# Dozeを終了
$ adb shell dumpsys deviceidle unforce

# Dozeステータスを確認
$ adb shell dumpsys deviceidle

アプリの動作確認

Doze Modeに移行後、ネットワークリクエストが機能するか（延期されるべき）、AlarmManagerが作動するか、FCMメッセージが配信されるか、WorkManagerタスクが正しく実行されるかを確認します。WorkManagerはDozeでも動作を継続し、そのタスクはメンテナンスウィンドウで実行されます。ただし、タスクが即時実行を必要とする場合は、setExpedited()を指定するかForeground Serviceを使用します。

Doze Modeのベストプラクティス

Doze Modeに耐性のあるアプリを開発するには、バックグラウンドタスクへのアプローチを再考する必要があります。Googleは、バックグラウンド操作の即時実行に依存せず、Dozeの制限下でも正しく動作するようアプリを設計することを推奨しています。基本原則は、延期可能なすべてのバックグラウンドタスクにWorkManagerを使用することです。

WorkManagerの使用

WorkManagerはバックグラウンドタスクに推奨されるGoogle APIであり、Dozeに自動的に適応します。WorkManagerはJobScheduler（API 23+）または古いバージョンではAlarmManager + BroadcastReceiverを使用します。WorkManagerタスクは直近のDozeメンテナンスウィンドウで実行されるか、必要に応じてExpedited Work（内部でForeground Serviceを使用）により即時実行されます。

重要なタスクにはForeground Service

タスクを延期できない場合（メディア再生、ナビゲーション、VoIP）は、必須の通知を伴うForeground Serviceを使用します。Foreground ServiceはDozeの免除を受け、WakeLockを保持しネットワークリクエストを実行できます。ただし、Foreground Serviceでも一部のタスク（dataSyncなど）ではDeep Dozeのメンテナンスウィンドウポリシーの対象となります。

通知にはFCM高優先度

即時の注意を要するメッセージ（着信、緊急通知）の配信には、FCM高優先度メッセージを使用します。これらのメッセージはデバイスをDozeから復帰させ、アプリに処理のための短いウィンドウを提供します。通常の通知に高優先度を使用しないでください。バッテリーの急速な消耗を招き、Google Playのポリシー違反と見なされる可能性があります。

• WorkManager — すべての延期可能なバックグラウンドタスクに推奨されるAPI
• Foreground Service — 可視通知を伴う重要なタスクに使用
• FCM高優先度 — デバイス復帰を伴う緊急メッセージ配信に使用
• 本当に必要な場合を除き Whitelistをリクエストしない — ユーザー体験を損なう
• リリース前に ADB経由でLightおよびDeep Dozeでのテストを実施