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” в 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 повідомлення високого пріоритету, які проходять через окремий канал 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 високого пріоритету для пробудження пристрою з Doze. Кожне таке повідомлення дає додатку коротке вікно (10–30 секунд) для виконання завдання. Для більш тривалих операцій додаток повинен запустити Foreground Service, який продовжить роботу у вікнах обслуговування Doze. Google також надає механізм звільнення для деяких типів додатків: навігаційні, медичні, месенджери.

Як перевірити статус 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 високого пріоритету для повідомлень

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

• WorkManager — кращий API для всіх відкладених фонових завдань
• Foreground Service — для критичних завдань з видимим повідомленням
• FCM високого пріоритету — для доставки термінових повідомлень з пробудженням пристрою
• Не запитуйте Whitelist без крайньої необхідності — це погіршує досвід користувача
• Тестуйте додаток у Light та Deep Doze через ADB перед випуском