Doze Mode: суть, фазы и механизм энергосбережения

Что такое Doze Mode

Doze Mode — это встроенный механизм энергосбережения Android, активирующийся, когда устройство не подключено к зарядному устройству, экран выключен и пользователь не взаимодействует с девайсом в течение определённого времени. Цель Doze — минимизировать фоновую активность приложений, чтобы максимально продлить жизнь батареи в режиме ожидания. Система откладывает JobScheduler, синхронизацию аккаунтов, AlarmManager и сетевые запросы.

Режим был представлен в Android 6.0 Marshmallow (API 23) и значительно доработан в последующих версиях. В Android 7.0 Nougat появилась вторая фаза (Light Doze), активирующаяся при движении устройства. Android 8.0 ввёл дополнительные ограничения на фоновые сервисы, работающие в паре с Doze. В Android 12+ Doze был интегрирован с обновлённой системой управления батареей, анализирующей поведение пользователя.

Важно понимать: Doze Mode не отключает приложения полностью. Он переводит их в состояние с отложенными задачами, но не убивает процессы. Foreground Service с уведомлением продолжает работать, push-уведомления высокого приоритета (FCM high-priority) доставляются, а будильники срабатывают по расписанию. Doze влияет только на фоновые операции, которые пользователь не видит и не ожидает в данный момент.

Условия активации

Doze Mode активируется при выполнении всех условий: экран выключен более 30 минут (первая активация), устройство неподвижно (используется акселерометр), не подключено к зарядке. Если пользователь берёт телефон в руки или подключает зарядное устройство, Doze немедленно деактивируется. В Android 7+ Light Doze активируется уже через 5 минут бездействия, даже при движении устройства.

Как работает Doze Mode

Doze Mode управляет фоновой активностью через системный сервис DeviceIdleController, который анализирует состояние датчиков, экрана и зарядного устройства. Когда все условия активации выполнены, система переводит приложения в режим ожидания, группируя их запросы в окна обслуживания. Внутри этих окон все отложенные задачи — сетевые вызовы, синхронизация, AlarmManager — выполняются пачкой.

Системный PowerManager контролирует, какие приложения могут выходить из Doze. Push-уведомления с высоким приоритетом (FCM high-priority) могут пробудить устройство для доставки сообщения. Также система игнорирует Doze для приложений, добавленных пользователем в Whitelist оптимизации батареи. Все остальные приложения должны дожидаться следующего окна обслуживания.

Длительность окон обслуживания в Deep Doze увеличивается экспоненциально: первое окно через 1 час, второе через 2 часа, третье через 4 часа и так далее до максимального интервала в 12 часов. Это значит, что чем дольше устройство находится в Doze, тем реже приложения могут выполнять фоновые задачи — батарея экономится максимально агрессивно.

Влияние на сетевые запросы

В Doze Mode все сетевые запросы приостанавливаются до наступления окна обслуживания. Исключение составляют только FCM high-priority messages (с тегом "high_priority" в payload) и сигналы от AlarmManager с флагами setAndAllowWhileIdle() или setExactAndAllowWhileIdle(). Обычные сетевые вызовы через Retrofit, OkHttp или Volley не будут выполнены, пока не откроется окно.

Фазы Doze Mode

Doze Mode состоит из двух фаз: Light Doze (лёгкий сон) и Deep Doze (глубокий сон). Каждая фаза накладывает свои ограничения и имеет различные пороги активации. Понимание разницы между фазами критично для разработчика, проектирующего фоновые задачи, устойчивые к режиму энергосбережения.

Light Doze (лёгкий сон)

Light Doze активируется через 5–30 минут бездействия устройства (экран выключен, нет движения). В этой фазе сетевые запросы и синхронизация приостанавливаются, но AlarmManager и JobScheduler продолжают работать с небольшими задержками. Приложения могут выходить из Light Doze при получении push-уведомления или при подключении к зарядке. Light Doze не требует полной неподвижности — устройство может находиться в движении.

Deep Doze (глубокий сон)

Deep Doze наступает после 60–90 минут бездействия при неподвижном устройстве (акселерометр не фиксирует движения). В Deep Doze система существенно агрессивнее откладывает задачи: окна обслуживания открываются реже (с экспоненциальным увеличением интервала), AlarmManager срабатывает только с флагами setAndAllowWhileIdle(), а WakeLock не работает в обычном режиме. Приложения, не находящиеся в Whitelist, практически полностью лишаются фоновой активности.

Ограничения при Doze Mode

Doze Mode накладывает несколько категорий ограничений, которые разработчик обязан учитывать при проектировании приложения. Игнорирование этих ограничений приводит к тому, что фоновые задачи не выполняются, а пользователь видит некорректную работу приложения — отсутствие обновлений, неотправленные сообщения, невыполненную синхронизацию.

Сетевые ограничения

Все сетевые запросы блокируются до наступления окна обслуживания. Это касается HTTP-вызовов, WebSocket-соединений, загрузки файлов. Исключение — FCM high-priority сообщения, которые проходят через отдельный канал Google Play Services, не зависящий от Doze. Для синхронизации критических данных рекомендуется использовать WorkManager с политикой NetworkType.CONNECTED.

Ограничения AlarmManager

AlarmManager в Deep Doze откладывает все будильники, кроме созданных методами setAndAllowWhileIdle() и setExactAndAllowWhileIdle(). Однако даже эти методы имеют ограничение — не более 1 срабатывания за 9 минут на приложение. Точные будильники setExact() в Deep Doze не гарантируют срабатывания в заданное время.

Ограничения WakeLock

WakeLock в Doze Mode работает нестандартно: система не удерживает блокировку сна для приложений вне Whitelist. Даже если приложение корректно захватило PARTIAL_WAKE_LOCK, при наступлении Deep Doze система может принудительно освободить его. Единственный способ гарантировать выполнение задачи в Doze — использовать Foreground Service с уведомлением.

• Сеть — все запросы отложены до окна обслуживания, кроме FCM high-priority
• AlarmManager — точные будильники откладываются; setAndAllowWhileIdle — не чаще 1/9 мин
• WakeLock — принудительно освобождается для приложений вне Whitelist
• JobScheduler — задачи группируются в окна обслуживания с экспоненциальным интервалом
• Синхронизация — Account SyncManager приостанавливается до выхода из Doze

Whitelist и исключения

Whitelist (белый список) Doze — это перечень приложений, которым система разрешает фоновую активность в режиме энергосбережения с минимальными ограничениями. Пользователь может вручную добавлять приложения в список через Настройки → Батарея → Оптимизация батареи. Системные приложения, лаунчеры и сервисы Google Play Services находятся в Whitelist по умолчанию.

Разработчик может запросить добавление в Whitelist через системный диалог с Intent ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS. Для этого в манифесте требуется разрешение REQUEST_IGNORE_BATTERY_OPTIMIZATIONS. Однако Google не рекомендует запрашивать исключение без веской причины — приложения, злоупотребляющие этой возможностью, рискуют быть отклонёнными при публикации в Google Play.

Без Whitelist приложение может использовать FCM high-priority для пробуждения устройства из Doze. Каждое такое сообщение даёт приложению короткое окно (10–30 секунд) для выполнения задачи. Для более длительных операций приложение должно запустить Foreground Service, который продолжит работу в окнах обслуживания Doze. Google также предоставляет механизм exemption для некоторых типов приложений: навигационные, медицинские, мессенджеры.

Как проверить статус Whitelist

Для проверки, находится ли приложение в Whitelist оптимизации батареи, используется метод powerManager.isIgnoringBatteryOptimizations(). Если метод возвращает false, приложение подчиняется всем ограничениям Doze. Если true — приложение может использовать Wakelock, AlarmManager и сеть без ограничений даже в Deep Doze. Однако злоупотребление этой привилегией приведёт к плохим отзывам пользователей.

Тестирование 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 без ожидания стандартного таймаута. После тестирования Doze отключается командой adb shell dumpsys deviceidle unforce.

# Принудительный вход в 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 подчиняется политике окон обслуживания Deep Doze для некоторых типов задач — например, dataSync.

FCM high-priority для уведомлений

Для доставки сообщений, требующих немедленного внимания (входящий звонок, срочное уведомление), используйте FCM high-priority сообщения. Такие сообщения пробуждают устройство из Doze и дают приложению короткое окно для обработки. Не используйте high-priority для обычных уведомлений — это приведёт к быстрому разряду батареи и может быть расценено Google Play как нарушение политики.

• WorkManager — предпочтительный API для всех отложенных фоновых задач
• Foreground Service — для критических задач с видимым уведомлением
• FCM high-priority — для доставки срочных сообщений с пробуждением устройства
• Не запрашивай Whitelist без крайней необходимости — это ухудшает пользовательский опыт
• Тестируй приложение в Light и Deep Doze через ADB перед релизом