Doze Mode: podstata, fáze a mechanismus úspory energie

Co je Doze Mode

Doze Mode je vestavěný mechanismus úspory energie v Androidu, který se aktivuje, když zařízení není připojeno k nabíječce, obrazovka je vypnutá a uživatel po určitou dobu se zařízením neinteraguje. Cílem Doze je minimalizovat aktivitu aplikací na pozadí, aby se maximalizovala výdrž baterie v pohotovostním režimu. Systém odkládá JobScheduler, synchronizaci účtů, AlarmManager a síťové požadavky.

Režim byl představen v Android 6.0 Marshmallow (API 23) a byl výrazně vylepšen v následujících verzích. V Android 7.0 Nougat se objevila druhá fáze (Light Doze), aktivující se při pohybu zařízení. Android 8.0 zavedl další omezení na služby na pozadí pracující společně s Doze. V Android 12+ byl Doze integrován s aktualizovaným systémem správy baterie, analyzujícím chování uživatele.

Je důležité pochopit: Doze Mode aplikace zcela nevypíná. Převádí je do stavu s odloženými úkoly, ale nezabíjí procesy. Foreground Service s oznámením nadále funguje, push oznámení s vysokou prioritou (FCM high-priority) jsou doručována a budíky se spouštějí podle plánu. Doze ovlivňuje pouze operace na pozadí, které uživatel v danou chvíli nevidí a neočekává.

Podmínky aktivace

Doze Mode se aktivuje při splnění všech podmínek: obrazovka je vypnutá déle než 30 minut (první aktivace), zařízení je nehybné (používá se akcelerometr), není připojeno k nabíječce. Pokud uživatel vezme telefon do ruky nebo připojí nabíječku, Doze se okamžitě deaktivuje. V Android 7+ se Light Doze aktivuje již po 5 minutách nečinnosti, i při pohybu zařízení.

Jak funguje Doze Mode

Doze Mode řídí aktivitu na pozadí prostřednictvím systémové služby DeviceIdleController, která analyzuje stav senzorů, obrazovky a nabíječky. Když jsou splněny všechny podmínky aktivace, systém převede aplikace do pohotovostního režimu a seskupuje jejich požadavky do oken služeb. Uvnitř těchto oken jsou všechny odložené úkoly — síťová volání, synchronizace, AlarmManager — prováděny dávkově.

Systémový PowerManager kontroluje, které aplikace mohou z Doze vystoupit. Push oznámení s vysokou prioritou (FCM high-priority) mohou probudit zařízení k doručení zprávy. Systém také ignoruje Doze pro aplikace přidané uživatelem do Whitelist optimalizace baterie. Všechny ostatní aplikace musí čekat na další okno služeb.

Délka oken služeb v Deep Doze se exponenciálně zvyšuje: první okno po 1 hodině, druhé po 2 hodinách, třetí po 4 hodinách a tak dále až do maximálního intervalu 12 hodin. To znamená, že čím déle zařízení zůstává v Doze, tím méně často mohou aplikace vykonávat úkoly na pozadí — baterie je šetřena maximálně agresivně.

Dopad na síťové požadavky

V Doze Mode jsou všechny síťové požadavky pozastaveny do příchodu okna služeb. Výjimku tvoří pouze zprávy FCM high-priority (s tagem „high_priority” v payloadu) a signály z AlarmManager s příznaky setAndAllowWhileIdle() nebo setExactAndAllowWhileIdle(). Běžná síťová volání přes Retrofit, OkHttp nebo Volley nebudou provedena, dokud se okno neotevře.

Fáze Doze Mode

Doze Mode se skládá ze dvou fází: Light Doze (lehký spánek) a Deep Doze (hluboký spánek). Každá fáze ukládá svá vlastní omezení a má různé prahy aktivace. Pochopení rozdílu mezi fázemi je klíčové pro vývojáře navrhujícího úkoly na pozadí odolné vůči režimu úspory energie.

Light Doze (lehký spánek)

Light Doze se aktivuje po 5–30 minutách nečinnosti zařízení (obrazovka vypnutá, bez pohybu). V této fázi jsou síťové požadavky a synchronizace pozastaveny, ale AlarmManager a JobScheduler nadále fungují s malými zpožděními. Aplikace mohou z Light Doze vystoupit při přijetí push oznámení nebo při připojení k nabíječce. Light Doze nevyžaduje úplnou nehybnost — zařízení se může pohybovat.

Deep Doze (hluboký spánek)

Deep Doze nastává po 60–90 minutách nečinnosti s nehybným zařízením (akcelerometr nezaznamenává pohyb). V Deep Doze systém odkládá úkoly výrazně agresivněji: okna služeb se otevírají méně často (s exponenciálně rostoucím intervalem), AlarmManager se spouští pouze s příznaky setAndAllowWhileIdle() a WakeLock nefunguje v normálním režimu. Aplikace, které nejsou na Whitelistu, prakticky zcela ztrácejí aktivitu na pozadí.

Omezení v Doze Mode

Doze Mode ukládá několik kategorií omezení, která musí vývojář zohlednit při navrhování aplikace. Ignorování těchto omezení vede k neprovádění úkolů na pozadí a uživatel vidí nesprávnou funkci aplikace — chybějící aktualizace, neodeslané zprávy, neprovedenou synchronizaci.

Síťová omezení

Všechny síťové požadavky jsou blokovány do příchodu okna služeb. To se týká HTTP volání, WebSocket připojení, stahování souborů. Výjimka — zprávy FCM high-priority, které procházejí samostatným kanálem Google Play Services, nezávislým na Doze. Pro synchronizaci kritických dat se doporučuje použití WorkManager s politikou NetworkType.CONNECTED.

Omezení AlarmManager

AlarmManager v Deep Doze odkládá všechny budíky kromě těch vytvořených metodami setAndAllowWhileIdle() a setExactAndAllowWhileIdle(). Avšak i tyto metody mají omezení — ne více než 1 spuštění za 9 minut na aplikaci. Přesné budíky setExact() v Deep Doze negarantují spuštění v nastavený čas.

Omezení WakeLock

WakeLock v Doze Mode funguje nestandardně: systém neudržuje blokování spánku pro aplikace mimo Whitelist. I když aplikace správně získala PARTIAL_WAKE_LOCK, při nástupu Deep Doze jej systém může násilně uvolnit. Jediný způsob, jak zaručit provedení úkolu v Doze, je použití Foreground Service s oznámením.

• Síť — všechny požadavky odloženy do okna služeb, kromě FCM high-priority
• AlarmManager — přesné budíky odloženy; setAndAllowWhileIdle — max 1/9 min
• WakeLock — násilně uvolněn pro aplikace mimo Whitelist
• JobScheduler — úkoly seskupeny do oken služeb s exponenciálním intervalem
• Synchronizace — Account SyncManager pozastaven do výstupu z Doze

Whitelist a výjimky

Whitelist (bílý seznam) Doze je soubor aplikací, kterým systém povoluje aktivitu na pozadí v režimu úspory energie s minimálními omezeními. Uživatel může ručně přidávat aplikace do seznamu přes Nastavení → Baterie → Optimalizace baterie. Systémové aplikace, spouštěče a služby Google Play Services jsou na Whitelistu ve výchozím nastavení.

Vývojář může požádat o přidání na Whitelist prostřednictvím systémového dialogu s Intent ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS. K tomu je v manifestu vyžadováno oprávnění REQUEST_IGNORE_BATTERY_OPTIMIZATIONS. Google však nedoporučuje žádat o výjimku bez závažného důvodu — aplikace zneužívající tuto možnost riskují zamítnutí při publikování v Google Play.

Bez Whitelistu může aplikace používat FCM high-priority k probuzení zařízení z Doze. Každá taková zpráva dává aplikaci krátké okno (10–30 sekund) k provedení úkolu. Pro delší operace musí aplikace spustit Foreground Service, která bude pokračovat v činnosti v oknech služeb Doze. Google také poskytuje mechanismus osvobození pro určité typy aplikací: navigační, lékařské, komunikační.

Jak zkontrolovat stav Whitelist

Pro kontrolu, zda je aplikace na Whitelistu optimalizace baterie, se používá metoda powerManager.isIgnoringBatteryOptimizations(). Pokud metoda vrací false, aplikace podléhá všem omezením Doze. Pokud true — aplikace může používat Wakelock, AlarmManager a síť bez omezení i v Deep Doze. Zneužití tohoto privilegia však povede ke špatným hodnocením uživatelů.

Testování Doze Mode

Testování chování aplikace v Doze Mode je povinnou fází vývoje, protože Doze může narušit funkce na pozadí. Android poskytuje nástroje příkazového řádku přes ADB pro vynucené přepnutí zařízení do Light Doze a Deep Doze. Testování je třeba provádět na fyzickém zařízení nebo emulátoru s Android 6.0+.

Pro vstup do Light Doze se používá příkaz adb shell dumpsys deviceidle step light. Pro Deep Doze — adb shell dumpsys deviceidle step deep. Příkaz adb shell dumpsys deviceidle force-idle deep okamžitě přepne zařízení do Deep Doze bez čekání na standardní časový limit. Po testování se Doze vypíná příkazem adb shell dumpsys deviceidle unforce.

# Vynucený vstup do Light Doze
$ adb shell dumpsys deviceidle step light

# Vynucený vstup do Deep Doze
$ adb shell dumpsys deviceidle step deep

# Okamžitý přechod do Deep Doze
$ adb shell dumpsys deviceidle force-idle deep

# Výstup z Doze
$ adb shell dumpsys deviceidle unforce

# Zobrazení stavu Doze
$ adb shell dumpsys deviceidle

Kontrola fungování aplikace

Po přepnutí do Doze Mode je třeba zkontrolovat: zda fungují síťové požadavky (měly by být odloženy), zda se spouští AlarmManager, zda jsou doručovány zprávy FCM, zda jsou úkoly WorkManager správně prováděny. WorkManager v Doze nadále funguje: jeho úkoly jsou prováděny v oknech služeb. Pokud však úkol vyžaduje okamžité provedení, je třeba uvést setExpedited() nebo použít Foreground Service.

Nejlepší postupy pro Doze Mode

Vývoj aplikace odolné vůči Doze Mode vyžaduje přehodnocení přístupu k úkolům na pozadí. Google doporučuje navrhovat aplikaci tak, aby správně fungovala při jakýchkoli omezeních Doze, aniž by spoléhala na okamžité provedení operací na pozadí. Základním principem je použití WorkManager pro všechny úkoly na pozadí, které lze odložit.

Používejte WorkManager

WorkManager je doporučené Google API pro úkoly na pozadí, protože se automaticky přizpůsobuje Doze. WorkManager používá JobScheduler (API 23+) nebo AlarmManager + BroadcastReceiver na starších verzích. Úkoly WorkManager jsou prováděny v nejbližším okně služeb Doze a v případě potřeby — okamžitě prostřednictvím Expedited Work (Foreground Service pod kapotou).

Foreground Service pro kritické úkoly

Pokud úkol nelze odložit (přehrávání médií, navigace, VoIP), použijte Foreground Service s povinným oznámením. Foreground Service získává výjimku z Doze: může udržovat WakeLock a provádět síťové požadavky. Avšak i Foreground Service podléhá politice oken služeb Deep Doze pro některé typy úkolů — například dataSync.

FCM high-priority pro oznámení

Pro doručení zpráv vyžadujících okamžitou pozornost (příchozí hovor, naléhavé oznámení) používejte zprávy FCM high-priority. Takové zprávy probouzejí zařízení z Doze a dávají aplikaci krátké okno ke zpracování. Nepoužívejte high-priority pro běžná oznámení — to povede k rychlému vybití baterie a může být Google Play považováno za porušení pravidel.

• WorkManager — preferované API pro všechny odložitelné úkoly na pozadí
• Foreground Service — pro kritické úkoly s viditelným oznámením
• FCM high-priority — pro doručení naléhavých zpráv s probuzením zařízení
• Nežiádejte o Whitelist bez krajní nutnosti — zhoršuje uživatelský zážitek
• Testujte aplikaci v Light a Deep Doze přes ADB před vydáním