Doze Mode: istota, fazy i mechanizm oszczędzania energii

Co to jest Doze Mode

Doze Mode to wbudowany mechanizm oszczędzania energii w Androidzie, aktywujący się, gdy urządzenie nie jest podłączone do ładowarki, ekran jest wyłączony, a użytkownik nie korzysta z urządzenia przez określony czas. Celem Doze jest zminimalizowanie aktywności aplikacji w tle, aby maksymalnie wydłużyć żywotność baterii w trybie czuwania. System opóźnia JobScheduler, synchronizację kont, AlarmManager i żądania sieciowe.

Tryb został wprowadzony w Android 6.0 Marshmallow (API 23) i znacząco rozbudowany w kolejnych wersjach. W Android 7.0 Nougat pojawiła się druga faza (Light Doze), aktywująca się podczas ruchu urządzenia. Android 8.0 wprowadził dodatkowe ograniczenia na usługi działające w tle, współpracujące z Doze. W Android 12+ Doze został zintegrowany ze zaktualizowanym systemem zarządzania baterią, analizującym zachowanie użytkownika.

Ważne jest, aby zrozumieć: Doze Mode nie wyłącza aplikacji całkowicie. Przełącza je w stan z odroczonymi zadaniami, ale nie zabija procesów. Foreground Service z powiadomieniem nadal działa, powiadomienia push wysokiego priorytetu (FCM high-priority) są dostarczane, a alarmy uruchamiają się zgodnie z harmonogramem. Doze wpływa tylko na operacje w tle, których użytkownik nie widzi i nie oczekuje w danym momencie.

Warunki aktywacji

Doze Mode aktywuje się po spełnieniu wszystkich warunków: ekran wyłączony przez ponad 30 minut (pierwsza aktywacja), urządzenie nieruchome (wykorzystywany jest akcelerometr), niepodłączone do ładowarki. Jeśli użytkownik weźmie telefon do ręki lub podłączy ładowarkę, Doze natychmiast się dezaktywuje. W Android 7+ Light Doze aktywuje się już po 5 minutach bezczynności, nawet podczas ruchu urządzenia.

Jak działa Doze Mode

Doze Mode zarządza aktywnością w tle poprzez systemowy serwis DeviceIdleController, który analizuje stan czujników, ekranu i ładowarki. Po spełnieniu wszystkich warunków aktywacji system przełącza aplikacje w tryb oczekiwania, grupując ich żądania w okna serwisowe. Wewnątrz tych okien wszystkie odroczone zadania — wywołania sieciowe, synchronizacja, AlarmManager — są wykonywane partiami.

Systemowy PowerManager kontroluje, które aplikacje mogą wybudzać się z Doze. Powiadomienia push wysokiego priorytetu (FCM high-priority) mogą obudzić urządzenie w celu dostarczenia wiadomości. System ignoruje również Doze dla aplikacji dodanych przez użytkownika do Whitelist optymalizacji baterii. Wszystkie pozostałe aplikacje muszą czekać na następne okno serwisowe.

Czas trwania okien serwisowych w Deep Doze zwiększa się wykładniczo: pierwsze okno po 1 godzinie, drugie po 2 godzinach, trzecie po 4 godzinach i tak dalej, aż do maksymalnego interwału wynoszącego 12 godzin. Oznacza to, że im dłużej urządzenie znajduje się w Doze, tym rzadziej aplikacje mogą wykonywać zadania w tle — bateria jest oszczędzana maksymalnie agresywnie.

Wpływ na żądania sieciowe

W Doze Mode wszystkie żądania sieciowe są wstrzymywane do nadejścia okna serwisowego. Wyjątek stanowią tylko FCM high-priority messages (z tagiem „high_priority” w payload) i sygnały z AlarmManager z flagami setAndAllowWhileIdle() lub setExactAndAllowWhileIdle(). Zwykłe wywołania sieciowe przez Retrofit, OkHttp lub Volley nie zostaną wykonane, dopóki nie otworzy się okno.

Fazy Doze Mode

Doze Mode składa się z dwóch faz: Light Doze (lekki sen) i Deep Doze (głęboki sen). Każda faza nakłada własne ograniczenia i ma różne progi aktywacji. Zrozumienie różnicy między fazami jest kluczowe dla programisty projektującego zadania w tle odporne na tryb oszczędzania energii.

Light Doze (lekki sen)

Light Doze aktywuje się po 5–30 minutach bezczynności urządzenia (ekran wyłączony, brak ruchu). W tej fazie żądania sieciowe i synchronizacja są wstrzymywane, ale AlarmManager i JobScheduler nadal działają z niewielkimi opóźnieniami. Aplikacje mogą wybudzić się z Light Doze po otrzymaniu powiadomienia push lub po podłączeniu do ładowarki. Light Doze nie wymaga całkowitego bezruchu — urządzenie może się poruszać.

Deep Doze (głęboki sen)

Deep Doze następuje po 60–90 minutach bezczynności przy nieruchomym urządzeniu (akcelerometr nie rejestruje ruchu). W Deep Doze system znacznie agresywniej opóźnia zadania: okna serwisowe otwierają się rzadziej (z wykładniczym wzrostem interwału), AlarmManager uruchamia się tylko z flagami setAndAllowWhileIdle(), a WakeLock nie działa w standardowym trybie. Aplikacje nieznajdujące się na Whitelist praktycznie całkowicie tracą możliwość działania w tle.

Ograniczenia w Doze Mode

Doze Mode nakłada kilka kategorii ograniczeń, które programista musi uwzględnić przy projektowaniu aplikacji. Ignorowanie tych ograniczeń prowadzi do tego, że zadania w tle nie są wykonywane, a użytkownik widzi nieprawidłowe działanie aplikacji — brak aktualizacji, niewysłane wiadomości, niezrealizowaną synchronizację.

Ograniczenia sieciowe

Wszystkie żądania sieciowe są blokowane do nadejścia okna serwisowego. Dotyczy to wywołań HTTP, połączeń WebSocket, pobierania plików. Wyjątkiem są wiadomości FCM high-priority, które przechodzą przez oddzielny kanał Google Play Services, niezależny od Doze. Do synchronizacji krytycznych danych zaleca się używanie WorkManager z polityką NetworkType.CONNECTED.

Ograniczenia AlarmManager

AlarmManager w Deep Doze opóźnia wszystkie alarmy z wyjątkiem tych utworzonych metodami setAndAllowWhileIdle() i setExactAndAllowWhileIdle(). Jednak nawet te metody mają ograniczenie — nie więcej niż 1 wyzwolenie na 9 minut na aplikację. Dokładne alarmy setExact() w Deep Doze nie gwarantują wyzwolenia o określonej porze.

Ograniczenia WakeLock

WakeLock w Doze Mode działa niestandardowo: system nie utrzymuje blokady snu dla aplikacji spoza Whitelist. Nawet jeśli aplikacja poprawnie przechwyciła PARTIAL_WAKE_LOCK, po nadejściu Deep Doze system może go siłą zwolnić. Jedynym sposobem na zagwarantowanie wykonania zadania w Doze jest użycie Foreground Service z powiadomieniem.

• Sieć — wszystkie żądania odroczone do okna serwisowego, z wyjątkiem FCM high-priority
• AlarmManager — dokładne alarmy są opóźniane; setAndAllowWhileIdle — nie częściej niż 1/9 min
• WakeLock — siłowo zwalniany dla aplikacji spoza Whitelist
• JobScheduler — zadania grupowane w okna serwisowe z wykładniczym interwałem
• Synchronizacja — Account SyncManager wstrzymywany do wyjścia z Doze

Whitelist i wyjątki

Whitelist (biała lista) Doze to zestaw aplikacji, którym system zezwala na aktywność w tle w trybie oszczędzania energii z minimalnymi ograniczeniami. Użytkownik może ręcznie dodawać aplikacje do listy przez Ustawienia → Bateria → Optymalizacja baterii. Aplikacje systemowe, programy uruchamiające i usługi Google Play Services znajdują się na Whitelist domyślnie.

Programista może poprosić o dodanie do Whitelist za pomocą systemowego dialogu z Intent ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS. W tym celu w manifeście wymagane jest uprawnienie REQUEST_IGNORE_BATTERY_OPTIMIZATIONS. Google nie zaleca jednak proszenia o wyjątek bez ważnego powodu — aplikacje nadużywające tej możliwości ryzykują odrzucenie przy publikacji w Google Play.

Bez Whitelist aplikacja może używać FCM high-priority do wybudzania urządzenia z Doze. Każda taka wiadomość daje aplikacji krótkie okno (10–30 sekund) na wykonanie zadania. W przypadku dłuższych operacji aplikacja powinna uruchomić Foreground Service, który będzie kontynuował działanie w oknach serwisowych Doze. Google udostępnia również mechanizm zwolnienia dla niektórych typów aplikacji: nawigacyjnych, medycznych, komunikatorów.

Jak sprawdzić status Whitelist

Aby sprawdzić, czy aplikacja znajduje się na Whitelist optymalizacji baterii, używa się metody powerManager.isIgnoringBatteryOptimizations(). Jeśli metoda zwraca false, aplikacja podlega wszystkim ograniczeniom Doze. Jeśli true — aplikacja może korzystać z Wakelock, AlarmManager i sieci bez ograniczeń nawet w Deep Doze. Nadużywanie tego przywileju doprowadzi jednak do złych opinii użytkowników.

Testowanie Doze Mode

Testowanie zachowania aplikacji w Doze Mode to obowiązkowy etap rozwoju, ponieważ Doze może zakłócić działanie funkcji w tle. Android udostępnia narzędzia wiersza poleceń przez ADB do wymuszonego przełączania urządzenia w Light Doze i Deep Doze. Testowanie należy przeprowadzać na fizycznym urządzeniu lub emulatorze z Android 6.0+.

Aby wejść w Light Doze, używa się komendy adb shell dumpsys deviceidle step light. Dla Deep Doze — adb shell dumpsys deviceidle step deep. Komenda adb shell dumpsys deviceidle force-idle deep natychmiast przełącza urządzenie w Deep Doze bez oczekiwania na standardowy timeout. Po testowaniu Doze wyłącza się komendą adb shell dumpsys deviceidle unforce.

# Wymuszone wejście w Light Doze
$ adb shell dumpsys deviceidle step light

# Wymuszone wejście w Deep Doze
$ adb shell dumpsys deviceidle step deep

# Natychmiastowe przejście w Deep Doze
$ adb shell dumpsys deviceidle force-idle deep

# Wyjście z Doze
$ adb shell dumpsys deviceidle unforce

# Sprawdzenie statusu Doze
$ adb shell dumpsys deviceidle

Sprawdzanie działania aplikacji

Po przełączeniu w Doze Mode należy sprawdzić: czy działają żądania sieciowe (powinny być odroczone), czy uruchamia się AlarmManager, czy dostarczane są wiadomości FCM, czy zadania WorkManager są wykonywane prawidłowo. WorkManager w Doze nadal działa: jego zadania są wykonywane w oknach serwisowych. Jeśli jednak zadanie wymaga natychmiastowego wykonania, należy podać setExpedited() lub użyć Foreground Service.

Najlepsze praktyki dla Doze Mode

Tworzenie aplikacji odpornej na Doze Mode wymaga zmiany podejścia do zadań w tle. Google zaleca projektowanie aplikacji tak, aby działała poprawnie przy dowolnych ograniczeniach Doze, nie polegając na natychmiastowym wykonywaniu operacji w tle. Podstawową zasadą jest używanie WorkManager do wszystkich zadań w tle, które mogą być odroczone.

Używaj WorkManager

WorkManager to zalecany przez Google API do zadań w tle, ponieważ automatycznie dostosowuje się do Doze. WorkManager używa JobScheduler (API 23+) lub AlarmManager + BroadcastReceiver w starszych wersjach. Zadania WorkManager są wykonywane w najbliższym oknie serwisowym Doze, a w razie potrzeby — natychmiast przez Expedited Work (Foreground Service pod maską).

Foreground Service dla krytycznych zadań

Jeśli zadanie nie może być odroczone (odtwarzanie multimediów, nawigacja, VoIP), użyj Foreground Service z obowiązkowym powiadomieniem. Foreground Service otrzymuje wyjątek z Doze: może utrzymywać WakeLock i wykonywać żądania sieciowe. Jednak nawet Foreground Service podlega polityce okien serwisowych Deep Doze dla niektórych typów zadań — na przykład dataSync.

FCM high-priority dla powiadomień

Aby dostarczyć wiadomości wymagające natychmiastowej uwagi (połączenie przychodzące, pilne powiadomienie), używaj wiadomości FCM high-priority. Takie wiadomości wybudzają urządzenie z Doze i dają aplikacji krótkie okno na przetworzenie. Nie używaj high-priority do zwykłych powiadomień — doprowadzi to do szybkiego rozładowania baterii i może zostać uznane przez Google Play za naruszenie polityki.

• WorkManager — preferowane API do wszystkich odroczonych zadań w tle
• Foreground Service — do krytycznych zadań z widocznym powiadomieniem
• FCM high-priority — do dostarczania pilnych wiadomości z wybudzeniem urządzenia
• Nie proś o Whitelist bez skrajnej konieczności — pogarsza to doświadczenie użytkownika
• Testuj aplikację w Light i Deep Doze przez ADB przed wydaniem