Doze Mode: Wesen, Phasen und Energiesparmechanismus

Was ist der Doze Mode

Doze Mode ist ein integrierter Energiesparmechanismus von Android, der aktiviert wird, wenn das Gerät nicht an ein Ladegerät angeschlossen ist, der Bildschirm ausgeschaltet ist und der Benutzer für eine bestimmte Zeit nicht mit dem Gerät interagiert hat. Das Ziel von Doze ist es, die Hintergrundaktivität von Apps zu minimieren, um die Akkulaufzeit im Standby-Modus zu maximieren. Das System verschiebt JobScheduler, Kontosynchronisierung, AlarmManager und Netzwerkanfragen.

Der Modus wurde in Android 6.0 Marshmallow (API 23) eingeführt und in nachfolgenden Versionen erheblich verbessert. Android 7.0 Nougat führte eine zweite Phase (Light Doze) ein, die bei Bewegung des Geräts aktiviert wird. Android 8.0 führte zusätzliche Einschränkungen für Hintergrunddienste ein, die mit Doze zusammenarbeiten. In Android 12+ wurde Doze in ein aktualisiertes Batteriemanagementsystem integriert, das das Benutzerverhalten analysiert.

Es ist wichtig zu verstehen: Der Doze Mode deaktiviert Apps nicht vollständig. Er versetzt sie in einen Zustand mit verschobenen Aufgaben, beendet jedoch keine Prozesse. Ein Foreground Service mit Benachrichtigung arbeitet weiter, High-Priority Push-Benachrichtigungen (FCM high-priority) werden zugestellt und Alarme lösen planmäßig aus. Doze betrifft nur Hintergrundoperationen, die der Benutzer in diesem Moment nicht sieht oder erwartet.

Aktivierungsbedingungen

Doze Mode wird aktiviert, wenn alle Bedingungen erfüllt sind: Der Bildschirm ist länger als 30 Minuten ausgeschaltet (erste Aktivierung), das Gerät ist unbewegt (mittels Beschleunigungssensor) und es ist nicht an ein Ladegerät angeschlossen. Nimmt der Benutzer das Telefon in die Hand oder schließt ein Ladegerät an, wird Doze sofort deaktiviert. In Android 7+ wird Light Doze bereits nach 5 Minuten Inaktivität aktiviert, selbst wenn sich das Gerät bewegt.

Wie der Doze Mode funktioniert

Doze Mode verwaltet die Hintergrundaktivität über den Systemdienst DeviceIdleController, der den Zustand der Sensoren, des Bildschirms und des Ladegeräts analysiert. Wenn alle Aktivierungsbedingungen erfüllt sind, versetzt das System die Apps in den Standby-Modus und gruppiert ihre Anfragen in Wartungsfenster. Innerhalb dieser Fenster werden alle verschobenen Aufgaben — Netzwerkaufrufe, Synchronisierung, AlarmManager — gebündelt ausgeführt.

Der systemeigene PowerManager steuert, welche Apps aus dem Doze austreten können. High-Priority Push-Benachrichtigungen (FCM high-priority) können das Gerät wecken, um eine Nachricht zuzustellen. Das System ignoriert Doze auch für Apps, die der Benutzer zur Batterieoptimierungs-Whitelist hinzugefügt hat. Alle anderen Apps müssen auf das nächste Wartungsfenster warten.

Die Dauer der Wartungsfenster im Deep Doze steigt exponentiell: Das erste Fenster nach 1 Stunde, das zweite nach 2 Stunden, das dritte nach 4 Stunden und so weiter bis zu einem maximalen Intervall von 12 Stunden. Das bedeutet, je länger das Gerät im Doze ist, desto seltener können Apps Hintergrundaufgaben ausführen — der Akku wird so aggressiv wie möglich geschont.

Auswirkungen auf Netzwerkanfragen

Im Doze Mode werden alle Netzwerkanfragen bis zum Öffnen eines Wartungsfensters ausgesetzt. Die einzigen Ausnahmen sind FCM High-Priority-Nachrichten (mit dem Tag „high_priority“ im Payload) und Signale von AlarmManager mit den Flags setAndAllowWhileIdle() oder setExactAndAllowWhileIdle(). Normale Netzwerkaufrufe über Retrofit, OkHttp oder Volley werden erst ausgeführt, wenn ein Fenster geöffnet wird.

Phasen des Doze Mode

Doze Mode besteht aus zwei Phasen: Light Doze (leichter Schlaf) und Deep Doze (Tiefschlaf). Jede Phase hat ihre eigenen Einschränkungen und unterschiedliche Aktivierungsschwellen. Das Verständnis des Unterschieds zwischen den Phasen ist für einen Entwickler, der Hintergrundaufgaben entwickelt, die gegen den Energiesparmodus resistent sind, von entscheidender Bedeutung.

Light Doze (leichter Schlaf)

Light Doze wird nach 5–30 Minuten Geräte-Inaktivität aktiviert (Bildschirm aus, keine Bewegung). In dieser Phase werden Netzwerkanfragen und Synchronisierung ausgesetzt, aber AlarmManager und JobScheduler arbeiten mit geringen Verzögerungen weiter. Apps können aus Light Doze austreten, wenn sie eine Push-Benachrichtigung erhalten oder an ein Ladegerät angeschlossen werden. Light Doze erfordert keine vollständige Unbeweglichkeit — das Gerät kann sich bewegen.

Deep Doze (Tiefschlaf)

Deep Doze tritt nach 60–90 Minuten Inaktivität bei unbewegtem Gerät ein (der Beschleunigungssensor erfasst keine Bewegung). Im Deep Doze ist das System beim Verschieben von Aufgaben wesentlich aggressiver: Wartungsfenster öffnen sich seltener (mit exponentiell steigendem Intervall), AlarmManager löst nur mit den Flags setAndAllowWhileIdle() aus und WakeLock funktioniert nicht wie gewohnt. Apps, die nicht auf der Whitelist stehen, werden fast vollständig von Hintergrundaktivität ausgeschlossen.

Einschränkungen im Doze Mode

Doze Mode erlegt mehrere Kategorien von Einschränkungen auf, die ein Entwickler beim Entwerfen einer App berücksichtigen muss. Das Ignorieren dieser Einschränkungen führt dazu, dass Hintergrundaufgaben nicht ausgeführt werden und der Benutzer ein fehlerhaftes App-Verhalten sieht — fehlende Updates, nicht gesendete Nachrichten, unvollständige Synchronisierung.

Netzwerkeinschränkungen

Alle Netzwerkanfragen werden blockiert, bis ein Wartungsfenster geöffnet wird. Dies betrifft HTTP-Aufrufe, WebSocket-Verbindungen und Dateidownloads. Die Ausnahme sind FCM High-Priority-Nachrichten, die über einen separaten, von Doze unabhängigen Google Play Services-Kanal laufen. Für die Synchronisierung kritischer Daten wird die Verwendung von WorkManager mit der Richtlinie NetworkType.CONNECTED empfohlen.

AlarmManager-Einschränkungen

AlarmManager verschiebt im Deep Doze alle Alarme außer denen, die mit den Methoden setAndAllowWhileIdle() und setExactAndAllowWhileIdle() erstellt wurden. Allerdings haben auch diese Methoden eine Einschränkung — nicht mehr als 1 Auslösung pro 9 Minuten pro App. Genaue Alarme mit setExact() garantieren im Deep Doze keine Auslösung zur angegebenen Zeit.

WakeLock-Einschränkungen

WakeLock verhält sich im Doze Mode ungewöhnlich: Das System hält die Aufwecksperre für Apps außerhalb der Whitelist nicht aufrecht. Selbst wenn eine App korrekt einen PARTIAL_WAKE_LOCK erworben hat, kann das System ihn beim Eintritt in Deep Doze zwangsweise freigeben. Die einzige Möglichkeit, die Aufgabenausführung im Doze zu garantieren, ist die Verwendung eines Foreground Service mit einer Benachrichtigung.

• Netzwerk — alle Anfragen bis zum Wartungsfenster verschoben, außer FCM high-priority
• AlarmManager — genaue Alarme verschoben; setAndAllowWhileIdle — nicht mehr als 1/9 Min
• WakeLock — für Apps außerhalb der Whitelist zwangsweise freigegeben
• JobScheduler — Aufgaben in Wartungsfenstern mit exponentiellem Intervall gruppiert
• Synchronisierung — Account SyncManager bis zum Verlassen des Doze ausgesetzt

Whitelist und Ausnahmen

Die Whitelist von Doze ist eine Liste von Apps, denen das System Hintergrundaktivität im Energiesparmodus mit minimalen Einschränkungen erlaubt. Der Benutzer kann Apps manuell über Einstellungen → Akku → Akku-Optimierung zur Liste hinzufügen. System-Apps, Launcher und Google Play Services befinden sich standardmäßig auf der Whitelist.

Ein Entwickler kann die Aufnahme in die Whitelist über einen Systemdialog mit dem Intent ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS beantragen. Dazu ist die Berechtigung REQUEST_IGNORE_BATTERY_OPTIMIZATIONS im Manifest erforderlich. Google empfiehlt jedoch nicht, ohne triftigen Grund eine Ausnahme zu beantragen — Apps, die diese Möglichkeit missbrauchen, riskieren bei der Veröffentlichung im Google Play Store abgelehnt zu werden.

Ohne Whitelist kann eine App FCM High-Priority verwenden, um das Gerät aus dem Doze zu wecken. Jede dieser Nachrichten gibt der App ein kurzes Fenster (10–30 Sekunden) zur Aufgabenausführung. Für längere Vorgänge muss die App einen Foreground Service starten, der innerhalb der Doze-Wartungsfenster weiterarbeitet. Google bietet auch einen Befreiungsmechanismus für bestimmte App-Typen: Navigation, medizinische Apps, Messenger.

So überprüfen Sie den Whitelist-Status

Um zu überprüfen, ob eine App auf der Batterieoptimierungs-Whitelist steht, wird die Methode powerManager.isIgnoringBatteryOptimizations() verwendet. Wenn die Methode false zurückgibt, unterliegt die App allen Doze-Einschränkungen. Bei true kann die App Wakelock, AlarmManager und Netzwerk auch im Deep Doze ohne Einschränkungen nutzen. Der Missbrauch dieses Privilegs führt jedoch zu schlechten Benutzerbewertungen.

Testen des Doze Mode

Das Testen des App-Verhaltens im Doze Mode ist ein obligatorischer Entwicklungsschritt, da Doze Hintergrundfunktionen stören kann. Android bietet Befehlszeilen-Tools über ADB, um das Gerät zwangsweise in Light Doze und Deep Doze zu versetzen. Tests müssen auf einem physischen Gerät oder Emulator mit Android 6.0+ durchgeführt werden.

Zum Eintritt in den Light Doze wird der Befehl adb shell dumpsys deviceidle step light verwendet. Für Deep Doze — adb shell dumpsys deviceidle step deep. Der Befehl adb shell dumpsys deviceidle force-idle deep versetzt das Gerät sofort in Deep Doze, ohne auf das Standard-Timeout zu warten. Nach dem Testen wird Doze mit dem Befehl adb shell dumpsys deviceidle unforce beendet.

# Erzwungener Eintritt in Light Doze
$ adb shell dumpsys deviceidle step light

# Erzwungener Eintritt in Deep Doze
$ adb shell dumpsys deviceidle step deep

# Sofortiger Übergang zu Deep Doze
$ adb shell dumpsys deviceidle force-idle deep

# Doze beenden
$ adb shell dumpsys deviceidle unforce

# Doze-Status anzeigen
$ adb shell dumpsys deviceidle

Überprüfung der App-Funktion

Nach dem Übergang in den Doze Mode muss überprüft werden: ob Netzwerkanfragen funktionieren (sie sollten verschoben sein), ob AlarmManager auslöst, ob FCM-Nachrichten zugestellt werden und ob WorkManager-Aufgaben korrekt ausgeführt werden. WorkManager arbeitet im Doze weiter: Seine Aufgaben werden in Wartungsfenstern ausgeführt. Wenn eine Aufgabe jedoch sofortige Ausführung erfordert, geben Sie setExpedited() an oder verwenden Sie einen Foreground Service.

Best Practices für den Doze Mode

Die Entwicklung einer App, die gegen den Doze Mode resistent ist, erfordert ein Umdenken bei der Herangehensweise an Hintergrundaufgaben. Google empfiehlt, die App so zu gestalten, dass sie unter allen Doze-Einschränkungen korrekt funktioniert, ohne auf die sofortige Ausführung von Hintergrundoperationen angewiesen zu sein. Das grundlegende Prinzip ist die Verwendung von WorkManager für alle Hintergrundaufgaben, die verschoben werden können.

WorkManager verwenden

WorkManager ist die von Google empfohlene API für Hintergrundaufgaben, da sie sich automatisch an Doze anpasst. WorkManager verwendet JobScheduler (API 23+) oder AlarmManager + BroadcastReceiver auf älteren Versionen. WorkManager-Aufgaben werden im nächsten Doze-Wartungsfenster oder bei Bedarf sofort über Expedited Work (Foreground Service unter der Haube) ausgeführt.

Foreground Service für kritische Aufgaben

Wenn eine Aufgabe nicht verschoben werden kann (Medienwiedergabe, Navigation, VoIP), verwenden Sie einen Foreground Service mit einer obligatorischen Benachrichtigung. Ein Foreground Service erhält eine Ausnahme von Doze: Er kann einen WakeLock halten und Netzwerkanfragen ausführen. Allerdings unterliegt auch ein Foreground Service für einige Aufgabentypen den Deep Doze-Wartungsfenster-Richtlinien — zum Beispiel dataSync.

FCM High-Priority für Benachrichtigungen

Für die Zustellung von Nachrichten, die sofortige Aufmerksamkeit erfordern (eingehender Anruf, dringende Benachrichtigung), verwenden Sie FCM High-Priority-Nachrichten. Solche Nachrichten wecken das Gerät aus dem Doze und geben der App ein kurzes Verarbeitungsfenster. Verwenden Sie High-Priority nicht für normale Benachrichtigungen — dies führt zu schneller Batterieentladung und kann von Google Play als Richtlinienverstoß gewertet werden.

• WorkManager — bevorzugte API für alle verschiebbaren Hintergrundaufgaben
• Foreground Service — für kritische Aufgaben mit sichtbarer Benachrichtigung
• FCM High-Priority — für dringende Nachrichten mit Geräteweckung
• Fordern Sie nicht ohne dringende Notwendigkeit die Whitelist an — dies verschlechtert die Benutzererfahrung
• Testen Sie die App vor der Veröffentlichung über ADB im Light und Deep Doze