Suche
Neue Features von Android Marshmallow Teil 2

Doze und App Standby in Android Marshmallow: Das müssen Entwickler wissen

Michael Gruczel

© Shutterstock / mato181

Die beiden Modi Doze und App Standby in Android 6.0 SDK (API Level 23) sollen die Akkulaufzeit verlängern. Was Entwickler bei Apps – auch bei älteren – beachten sollten, damit alle Hintergrunddienste weiterhin zuverlässig funktionieren, erklärt dieser Beitrag.

Was hat es mit Doze und App Standby auf sich?

Apps führen immer mehr Tätigkeiten im Hintergrund aus. Dabei handelt es sich häufig um Netzwerk-Traffic. So werden Apps häufig im Hintergrund aktualisiert, um beim nächsten Öffnen der App die aktuellen Daten bereits vorzuhalten und somit Wartezeiten zu vermeiden. Dies führt zu einem hohen Akkuverbrauch, auch wenn das Smartphone nicht aktiv genutzt wird. Um diesem Problem zu begegnen, wird mit Android Marshmallow der sogenannte Doze Modus eingeführt. Wenn ein Smartphone eine gewisse Zeit mit ausgeschaltetem Display verbracht hat und nicht am Stromnetz hängt, wechseln Apps in diesen Modus. Dabei ist es nicht wichtig, ob die App mit dem aktuellen oder einem älteren Ziel-SDK gebaut wurde.

Highlights in Android Marshmallow
Teil 1: Berechtigungskonzept in Android Marshmallow: Das müssen Entwickler wissen
Teil 2: Doze und App Standby in Android Marshmallow: Das müssen Entwickler wissen
Teil 3: Autobackup in Android Marshmallow: Das müssen Entwickler wissen
Teil 4: Fingerprint-Sensor in Android Marshmallow: Das müssen Entwickler wissen

Dies bedeutet, dass Entwickler bereits jetzt reagieren müssen, wenn eigene Apps viele Hintergrund-Tasks durchführen. Im Doze Modus wird die Netzwerkaktivität für die App, CPU intensive Dienste, Standardalarme und die Synchronisation mit Hintergund-Jobs gestoppt. Damit essentielle Tätigkeiten noch im Hintergrund ausgeführt werden können, wird dieser Modus in regelmäßigen Abständen pausiert. In diesem kurzen Zeitfenster können wartende Hintergrundjobs ausgeführt oder auf das Netzwerk zugegriffen werden. Für viele Apps sollte dieses Wartungsfenster ausreichen.

Sollte die App aber mehr Aktivität im Hintergrund benötigen als das Wartungsfenster erlaubt, gibt es einige Möglichkeiten, um trotzdem Tätigkeiten im Hintergrund auszuführen. Sollen Alarme auch im Doze Modus greifen, kann dies zum Beispiel die Methode setAndAllowWhileIdle auf dem Alarm erzwingen. Soll auf das Netzwerk zugriffen werden, lässt sich die App durch GCM-Nachrichten mit hoher Priorität aufwecken. Hat die App bisher keine Pushnachrichten-Anbindung, so ist dies ein hoher Mehraufwand um Daten zu aktualisieren. Tatsächlich macht diese Änderung aber auch architektonisch Sinn.

Pushnachrichten können abhängig von neuen Ereignissen versendet werden, sodass die vermeintlichen Netzwerkanfragen dann auch tatsächlich neue Daten holen. Ist die App über eine GCM-Nachricht aufgeweckt worden, ist auch der Netzwerkzugang erneut möglich bis die App wieder in den Doze Modus wechselt. Die GCM-Nachricht muss dem Anwender dabei nicht kenntlich gemacht werden. Man stelle sich eine App vor, die aktuelle Konzerte in der Heimatstadt anzeigt. Sobald ein neues Konzert angemeldet wird, könnten alle Apps aufgeweckt werden, um die Daten abzurufen.

Während eine App im Doze Modus in regelmäßigen Abständen noch Aktivitäten durchführen kann, werden Apps inaktiv geschaltet, die schon mehrere Tage nicht mehr genutzt wurden. Dieser sogenannte App Standby Modus begrenzt die Möglichkeit zur Aktivität einer App auf einen einzigen Zeitpunkt pro Tag. In der restlichen Zeit sind alle Tasks gestoppt und der Netzwerkzugang gesperrt.

Netzwerkaktivitäten sind stark eingeschränkt – ein Beispiel

Ich will an einem Beispiel verdeutlichen, wie stark Google mit dem neuen Marshmallow die Netzwerkaktivität einschränkt. In Abbildung 1 sind die Netwerkrequests einer Beispiel-App zu sehen. In dieser App wird im Abstand von zehn Sekunden mittels OkHttpClient JAXenter.de aufgerufen. Das Scheduling erfolgt in diesem Beispiel über den Alarmservice. In der Abbildung ist die Ansicht aus dem Chrome Debugger zu sehen, der mittels Stehtho die Netzwerkanfragen aus der App in Chrome sichtbar macht. Man kann gut erkennen, dass die Abfragen erwartungsgemäß in Abständen von circa zehn Sekunden ausgeführt werden. Die App lief hierbei auf einer älteren Androidversion.

Abb 1.: Abfragen im Hintergrund in einem Abstand von zehn Sekunden

Abb 1.: Abfragen im Hintergrund in einem Abstand von zehn Sekunden ©Michael Gruczel

Die Abfragen der exakt gleiche App in Android Marshmallow ist in Abbildung 2 zu sehen. Die ersten sieben Abfragen werden hier in Abständen von rund einer Minute durchgeführt, obwohl die App aktiv und das Scheduling eigentlich auf zehn Sekunden angelegt war. Nach dem siebten Request habe ich die App in der Doze Modus versetzt. Dies lässt sich zu Testzwecken auch über die Kommandozeile mit den Befehlen adb shell dumbsys battery unplug und adb shell dumpsys deviceidle step erzwingen. Dabei wechselt die App bei der Ausführung zwischen dem Doze Modus („IDLE“) und dem Maintenance Modus („IDLE_MAINTENANCE“). Es ist zu erkennen, dass die Netzwerkrequests nicht mehr ausgeführt wurden. Drei Minuten später habe ich den Wartungsmodus aktiviert und die App ca 1,5 Minuten danach wieder aufgeweckt, wodurch die Netzwerkanfragen jeweils wieder gestartet wurden.

Eingeschränkte Abfragen unter Marshmallow

Abb. 2.: Eingeschränkte Abfragen unter Marshmallow ©Michael Gruczel

Fazit und Ausblick

Google schränkt Hintergrundtätigkeiten mit der neuen Androidversion stark ein. Wie stark dies zu einer Verbesserung der Akkulaufzeit beitragen wird, gilt abzuwarten. Wer Apps zur Verfügung stellt, die stark von solchen Hintergrundtasks abhängig sind, muss bereits jetzt handeln, denn die Änderungen sind mit Android Marshmallow sofort wirksam.

Der nächsten Artikel wird sich um die neuen Auto Backup Features in Android Marshmallow drehen.

Aufmacherbild: Smartphone sleeping in the bed von Shutterstock / Urheberrecht: mato181

Verwandte Themen:

Geschrieben von
Michael Gruczel
Michael Gruczel
Michael Gruczel ist seit 2008 als Berater und Entwickler im Bereich Java und DevOps tätig. Als Advisory Consultant von DellEmc berät er Firmen in der Modernisierung von Infrastruktur, Software-Stacks, Softwarearchitekturen und der Optimierung von Strukturen. Dazu gehört der volle Entwicklungszyklus: Von der Discovery, über die Entwicklung, das Testen, das Veröffentlichen bis hin zum Betreiben von Software.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: