Doze Mode: essens, faser och mekanism för energibesparing

Vad är Doze Mode

Doze Mode är en inbyggd energisparmekanism i Android som aktiveras när enheten inte är ansluten till laddaren, skärmen är avstängd och användaren inte interagerar med enheten under en viss tid. Målet med Doze är att minimera bakgrundsaktivitet för appar för att maximera batteritiden i standbyläge. Systemet skjuter upp JobScheduler, kontosynkronisering, AlarmManager och nätverksförfrågningar.

Läget introducerades i Android 6.0 Marshmallow (API 23) och förbättrades avsevärt i efterföljande versioner. I Android 7.0 Nougat uppträdde en andra fas (Light Doze) som aktiveras vid enhetens rörelse. Android 8.0 införde ytterligare begränsningar för bakgrundstjänster som fungerar tillsammans med Doze. I Android 12+ integrerades Doze med ett uppdaterat batterihanteringssystem som analyserar användarens beteende.

Det är viktigt att förstå: Doze Mode inaktiverar inte appar helt. Det för över dem till ett tillstånd med uppskjutna uppgifter, men dödar inte processer. Foreground Service med en notis fortsätter att fungera, push-notiser med hög prioritet (FCM high-priority) levereras och alarm utlöses enligt schema. Doze påverkar endast bakgrundsoperationer som användaren inte ser och inte förväntar sig för tillfället.

Aktiveringsvillkor

Doze Mode aktiveras när alla villkor är uppfyllda: skärmen är avstängd i mer än 30 minuter (första aktiveringen), enheten är stilla (accelerometer används), inte ansluten till laddaren. Om användaren tar upp telefonen eller ansluter laddaren, avaktiveras Doze omedelbart. I Android 7+ aktiveras Light Doze redan efter 5 minuters inaktivitet, även när enheten rör sig.

Hur fungerar Doze Mode

Doze Mode hanterar bakgrundsaktivitet via systemtjänsten DeviceIdleController, som analyserar status för sensorer, skärm och laddare. När alla aktiveringsvillkor är uppfyllda för systemet över appar till vänteläge och grupperar deras förfrågningar i servicefönster. Inuti dessa fönster utförs alla uppskjutna uppgifter — nätverksanrop, synkronisering, AlarmManager — i batchar.

Systemets PowerManager kontrollerar vilka appar som kan lämna Doze. Push-notiser med hög prioritet (FCM high-priority) kan väcka enheten för meddelandeleverans. Systemet ignorerar också Doze för appar som användaren har lagt till i Whitelist för batterioptimering. Alla andra appar måste vänta på nästa servicefönster.

Varaktigheten för servicefönster i Deep Doze ökar exponentiellt: första fönstret efter 1 timme, andra efter 2 timmar, tredje efter 4 timmar och så vidare upp till maxintervallet på 12 timmar. Detta innebär att ju längre enheten är i Doze, desto mer sällan kan appar utföra bakgrundsuppgifter — batteriet sparas maximalt aggressivt.

Inverkan på nätverksförfrågningar

I Doze Mode pausas alla nätverksförfrågningar tills servicefönstret anländer. Endast FCM high-priority-meddelanden (med taggen “high_priority” i payload) och signaler från AlarmManager med flaggorna setAndAllowWhileIdle() eller setExactAndAllowWhileIdle() är undantag. Vanliga nätverksanrop via Retrofit, OkHttp eller Volley kommer inte att utföras förrän fönstret öppnas.

Faser av Doze Mode

Doze Mode består av två faser: Light Doze (lätt sömn) och Deep Doze (djup sömn). Varje fas inför sina egna begränsningar och har olika aktiveringströsklar. Att förstå skillnaden mellan faserna är avgörande för en utvecklare som designar bakgrundsuppgifter som är motståndskraftiga mot energisparläget.

Light Doze (lätt sömn)

Light Doze aktiveras efter 5–30 minuters inaktivitet (skärm avstängd, ingen rörelse). I denna fas pausas nätverksförfrågningar och synkronisering, men AlarmManager och JobScheduler fortsätter att fungera med små fördröjningar. Appar kan lämna Light Doze vid mottagning av en push-notis eller vid anslutning till laddaren. Light Doze kräver inte fullständig stillhet — enheten kan röra sig.

Deep Doze (djup sömn)

Deep Doze inträffar efter 60–90 minuters inaktivitet med en stillastående enhet (accelerometer registrerar ingen rörelse). I Deep Doze skjuter systemet upp uppgifter betydligt mer aggressivt: servicefönster öppnas mer sällan (med exponentiellt ökande intervall), AlarmManager utlöses endast med flaggorna setAndAllowWhileIdle() och WakeLock fungerar inte i normalt läge. Appar som inte finns på Whitelist förlorar praktiskt taget all bakgrundsaktivitet.

Begränsningar i Doze Mode

Doze Mode inför flera kategorier av begränsningar som utvecklaren måste beakta vid design av appen. Att ignorera dessa begränsningar leder till att bakgrundsuppgifter inte utförs och användaren ser att appen inte fungerar korrekt — inga uppdateringar, ej skickade meddelanden, ej utförd synkronisering.

Nätverksbegränsningar

Alla nätverksförfrågningar blockeras tills servicefönstret anländer. Detta gäller HTTP-anrop, WebSocket-anslutningar, filnedladdningar. Undantag — FCM high-priority-meddelanden som går via en separat Google Play Services-kanal, oberoende av Doze. För synkronisering av kritisk data rekommenderas användning av WorkManager med policyn NetworkType.CONNECTED.

AlarmManager-begränsningar

AlarmManager i Deep Doze skjuter upp alla alarm utom de som skapats med metoderna setAndAllowWhileIdle() och setExactAndAllowWhileIdle(). Men även dessa metoder har en begränsning — inte mer än 1 utlösning per 9 minuter per app. Exakta alarm setExact() i Deep Doze garanterar inte utlösning vid angiven tid.

WakeLock-begränsningar

WakeLock i Doze Mode fungerar icke-standard: systemet behåller inte sömnlåset för appar utanför Whitelist. Även om appen korrekt har fångat PARTIAL_WAKE_LOCK, kan systemet vid Deep Doze tvångsfrigöra det. Det enda sättet att garantera utförande av en uppgift i Doze är att använda Foreground Service med en notis.

• Nätverk — alla förfrågningar uppskjutna till servicefönstret, utom FCM high-priority
• AlarmManager — exakta alarm skjuts upp; setAndAllowWhileIdle — max 1/9 min
• WakeLock — tvångsfrigjort för appar utanför Whitelist
• JobScheduler — uppgifter grupperas i servicefönster med exponentiellt intervall
• Synkronisering — Account SyncManager pausas tills utträde ur Doze

Whitelist och undantag

Whitelist (vit lista) Doze är den uppsättning appar som systemet tillåter bakgrundsaktivitet i energisparläge med minimala begränsningar. Användaren kan manuellt lägga till appar via Inställningar → Batteri → Batterioptimering. Systemappar, startprogram och Google Play Services finns på Whitelist som standard.

Utvecklaren kan begära tillägg till Whitelist via en systemdialog med Intent ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS. För detta krävs behörigheten REQUEST_IGNORE_BATTERY_OPTIMIZATIONS i manifestet. Google rekommenderar dock inte att begära undantag utan giltig anledning — appar som missbrukar denna möjlighet riskerar att avvisas vid publicering i Google Play.

Utan Whitelist kan appen använda FCM high-priority för att väcka enheten från Doze. Varje sådant meddelande ger appen ett kort fönster (10–30 sekunder) för att utföra en uppgift. För längre operationer måste appen starta en Foreground Service som fortsätter att fungera i Dozes servicefönster. Google tillhandahåller också en befrielsemekanism för vissa typer av appar: navigations-, medicinska och meddelandeappar.

Hur man kontrollerar Whitelist-status

För att kontrollera om appen finns på Whitelist för batterioptimering används metoden powerManager.isIgnoringBatteryOptimizations(). Om metoden returnerar false är appen underkastad alla Doze-begränsningar. Om true — kan appen använda Wakelock, AlarmManager och nätverk utan begränsningar även i Deep Doze. Missbruk av denna privilegium kommer dock att leda till dåliga användarbetyg.

Testa Doze Mode

Testning av appens beteende i Doze Mode är en obligatorisk utvecklingsfas eftersom Doze kan störa bakgrundsfunktioner. Android tillhandahåller kommandoradsverktyg via ADB för att tvångsföra enheten till Light Doze och Deep Doze. Testning måste utföras på en fysisk enhet eller emulator med Android 6.0+.

För att gå in i Light Doze används kommandot adb shell dumpsys deviceidle step light. För Deep Doze — adb shell dumpsys deviceidle step deep. Kommandot adb shell dumpsys deviceidle force-idle deep för omedelbart enheten till Deep Doze utan att vänta på standard timeout. Efter testning stängs Doze av med kommandot adb shell dumpsys deviceidle unforce.

# Tvingad in i Light Doze
$ adb shell dumpsys deviceidle step light

# Tvingad in i Deep Doze
$ adb shell dumpsys deviceidle step deep

# Omedelbar övergång till Deep Doze
$ adb shell dumpsys deviceidle force-idle deep

# Lämna Doze
$ adb shell dumpsys deviceidle unforce

# Visa Doze-status
$ adb shell dumpsys deviceidle

Kontrollera appens funktion

Efter övergång till Doze Mode måste man kontrollera: om nätverksförfrågningar fungerar (de bör vara uppskjutna), om AlarmManager utlöses, om FCM-meddelanden levereras, om WorkManager-uppgifter utförs korrekt. WorkManager i Doze fortsätter att fungera: dess uppgifter utförs i servicefönstren. Men om uppgiften kräver omedelbar utförande måste setExpedited() anges eller Foreground Service användas.

Bästa praxis för Doze Mode

Utveckling av en app som är motståndskraftig mot Doze Mode kräver omprövning av synen på bakgrundsuppgifter. Google rekommenderar att designa appen så att den fungerar korrekt under alla Doze-begränsningar, utan att förlita sig på omedelbar utförande av bakgrundsoperationer. Den grundläggande principen — använd WorkManager för alla bakgrundsuppgifter som kan skjutas upp.

Använd WorkManager

WorkManager är Googles rekommenderade API för bakgrundsuppgifter eftersom det automatiskt anpassar sig till Doze. WorkManager använder JobScheduler (API 23+) eller AlarmManager + BroadcastReceiver på äldre versioner. WorkManager-uppgifter utförs i närmaste Doze-servicefönster och vid behov — omedelbart via Expedited Work (Foreground Service under huven).

Foreground Service för kritiska uppgifter

Om en uppgift inte kan skjutas upp (mediauppspelning, navigering, VoIP), använd Foreground Service med obligatorisk notis. Foreground Service får undantag från Doze: den kan behålla WakeLock och utföra nätverksförfrågningar. Men även Foreground Service är underkastad Deep Dozes policy för servicefönster för vissa uppgiftstyper — till exempel dataSync.

FCM high-priority för notiser

För leverans av meddelanden som kräver omedelbar uppmärksamhet (inkommande samtal, brådskande notis), använd FCM high-priority-meddelanden. Sådana meddelanden väcker enheten från Doze och ger appen ett kort fönster för bearbetning. Använd inte high-priority för vanliga notiser — detta leder till snabb batteriurladdning och kan betraktas av Google Play som policybrott.

• WorkManager — föredraget API för alla uppskjutbara bakgrundsuppgifter
• Foreground Service — för kritiska uppgifter med synlig notis
• FCM high-priority — för leverans av brådskande meddelanden med enhetsväckning
• Begär inte Whitelist utan yttersta nödvändighet — försämrar användarupplevelsen
• Testa appen i Light och Deep Doze via ADB före lansering