Smarte Apps für Kunden aus der Automobilbranche oder der Industrie – damit befasst sich das App-Entwicklungsteam bei in-tech. Das Spektrum reicht von der Maschinensteuerung via Smartphone übers mobile Bezahlen bis hin zur Musiksteuerung im Auto. Um hierbei die neuesten Technologien einsetzen und Kunden die beste Lösung anbieten zu können, haben sich die App-Entwickler bei in-tech immer wieder mit neuesten Systemen und Versionen auseinandergesetzt – in diesem Fall mit Android Oreo.
Von den insbesondere Hintergrunddienste betreffenden Einschränkungen in Android 8 verspricht sich Google eine längere Akkulaufzeit und eine flüssigere Bedienung. Damit wird der unter Android 7 begonnene Weg, Möglichkeiten für Entwickler einzuschränken, die sich negativ auf die Leistung des Geräts und auf die Batterielaufzeit auswirken können, konsequent fortgeführt.
Der Fokus der Änderungen in Android 7 lag darauf zu verhindern, dass bei bestimmten Ereignissen eine Vielzahl von zunächst inaktiven Apps gleichzeitig in Aktion tritt, das System überlastet und so die Bedienung des Geräts stört. Um solche Situationen zu vermeiden, wurden sowohl das Senden als auch das Empfangen bestimmter Broadcasts wie CONNECTIVITY_ACTION, ACTION_NEW_PICTURE und ACTION_NEW_VIDEO eingeschränkt.
Fortgeführt wird dies mit Android 8. Außerdem wird die Häufigkeit von Positionsabfragen durch Hintergrunddienste limitiert.
Quelle: Roman Samokhin – Fotolia.com
Die Einschränkungen von Hintergrunddiensten betreffen lediglich Apps, die Android 8 als Zielplattform nutzen (targetSDK = 26) und die sich im Hintergrund befinden. Dies ist dann der Fall, wenn die App weder sichtbar ist, noch einen Vordergrunddienst laufen lässt oder wenn keine andere App im Vordergrund mit ihr kommuniziert. Sollte eine App in den Hintergrund geraten, kann das System deren Hintergrunddienste nach einigen Minuten stoppen.
Um sicherzugehen, dass eine App auch im Hintergrund notwendige Aufgaben verrichten kann, können, wo dies sinnvoll ist, statt Hintergrunddiensten Vordergrunddienste verwendet werden. Eine andere Möglichkeit ist es, den Android JobScheduler zu nutzen, der mit Android 5 (API-Level 21) eingeführt wurde. Dem JobScheduler können Aufgaben übergeben werden, die entweder einmalig oder periodisch vom System abgearbeitet werden. Auch eine gegebenenfalls notwendige Form der Netzwerkverbindung kann angegeben werden, sodass es möglich ist, beispielsweise eine Aufgabe nur dann zu starten, wenn eine WLAN-Verbindung verfügbar ist. Als zusätzliche Bedingung kann genannt werden, dass das Gerät zum Zeitpunkt der Ausführung ansonsten ungenutzt sein muss. Sollte eine Aufgabe nicht erfolgreich ausgeführt werden können, kann der JobScheduler die Aufgabe später erneut starten. Dabei ist es auch möglich, die Zeiten zwischen den Ausführungsversuchen exponentiell oder linear ansteigen zu lassen.
Apps, die auch Systeme mit einem API-Level unter 21 unterstützen müssen, können nicht auf den JobScheduler zurückgreifen. Stattdessen kann der Firebase JobDispatcher oder die Android-Job-Bibliothek von Evernote genutzt werden. Der Firebase JobDispatcher kann auf allen Systemen (z.B. Smartphones, Tablets, Smart-TVs) ab API-Level 9 (Android 2.3) eingesetzt werden, was allerdings die Google Play Services voraussetzt. Die Android-Job-Bibliothek von Evernote kann ab API-Level 14 (Android 4.0) genutzt werden; sie benötigt keine Google Play Services. Apps, die die Evernote-Bibliothek nutzen, laufen also auch auf Geräten mit Custom-ROMs oder auf Amazon-Fire-Geräten, die oft auf die Google Play Services verzichten. Beide Bibliotheken stehen unter der Apache License 2.0, was den Einsatz sowohl in freier als auch in proprietärer Software erlaubt.
Ein häufiger Kritikpunkt von Nutzern ist der hohe Batterieverbrauch von Apps als Folge von häufigen Positionsabfragen per GPS. Ab Android 8 können Apps im Hintergrund die Position nicht mehr so oft abfragen, wie dies bisher der Fall war. Apps im Vordergrund verhalten sich weiterhin wie gewohnt.
Eine App im Hintergrund erhält nur noch ein paarmal pro Stunde Positions-Updates, auch wenn sie sie häufiger angefordert hat. Dies betrifft alle Apps, die auf Geräten mit Android 8 laufen, und nicht nur die, die speziell für Android 8 erstellt wurden. Es ist daher empfehlenswert, auch das Verhalten älterer Apps unter Android 8 zu überprüfen, um möglichen Nutzerbeschwerden zuvorkommen zu können.
Um auch im Hintergrund die Position weiterhin häufiger als ein paarmal pro Stunde zu erhalten, kann anstatt eines Hintergrunddienstes ein Vordergrunddienst benutzt werden. Dies hat für Nutzer den Vorteil, dass der Vordergrundservice durch eine Notification sichtbar ist und beendet werden kann, wenn er nicht mehr benötigt wird. Eine weitere Alternative ist die Nutzung der Geofencing API der Google Play Services. Mit dieser ist es möglich, eine Benachrichtigung vom System anzufordern, wenn das Gerät in ein vorher bestimmtes Gebiet bewegt wird oder es verlässt.
Erhält die App im Hintergrund lediglich passiv Positionsdaten, indem sie beim Location Manager einen Location Provider mit dem Provider-Namen PASSIVE_PROVIDER anfordert, ändert sich auch mit Android 8 nichts am Verhalten. Allerdings erhält die App im Hintergrund dann auch nur Positionsdaten, wenn eine andere App im Vordergrund sich für den Empfang von Positionsdaten beim Location Provider registriert hat.
Broadcasts
Wie die Änderungen, die das Verhalten der Hintergrunddienste anbelangen, betreffen die Änderungen bezüglich der Broadcasts ebenfalls lediglich Apps, die Android 8 (API-Level 26) als Zielplattform benutzen.
Ab Android 8 können Apps keine impliziten Broadcasts im Manifest mehr registrieren. Implizite Broadcasts sind relativ unspezifische Nachrichten, wie zum Beispiel ACTION_BATTERY_CHANGED. Dieser Broadcast weist lediglich darauf hin, dass sich der Batteriestatus geändert hat, aber nicht darauf, welche Änderung genau stattgefunden hat. Explizite Broadcasts sind genauer in dem, was sie beschreiben, wie zum Beispiel ACTION_BATTERY_LOW. Ein Broadcast dieses Typs weist darauf hin, dass die Batterie einen niedrigen Ladezustand erreicht hat. Eine App kann sofort darauf reagieren, ohne weitere Anfragen durchführen zu müssen. Explizite Broadcasts können weiterhin auch im Manifest registriert werden. Implizite Broadcasts müssen von der App mittels Context.registerReceiver() während der Laufzeit registriert werden.
Welche Broadcasts zu den expliziten und welche zu den impliziten zählen, ist nur teilweise aus der Android-Dokumentation ersichtlich. Um die Unübersichtlichkeit jedoch zu erhöhen, gibt es zahlreiche Ausnahmemöglichkeiten. Diese sind im API Guide beschrieben.
Auch wenn die Änderungen in Android 8 für Entwickler einen gewissen Aufwand bedeuten, dürften die notwendigen Anpassungen oftmals überschaubar sein. Da in den meisten Fällen Alternativen zum bisherigen Vorgehen bestehen, lohnt es sich nicht, die Änderungen auf die lange Bank zu schieben. Zwar wird sich im Verhalten der Apps nicht viel für die Nutzer unmittelbar Ersichtliches ändern, doch werden die Einschränkungen für die Entwickler insgesamt hoffentlich zur Verbesserung der Batterielaufzeit und einer flüssigeren Oberfläche von Android-Geräten mit weniger Rucklern führen. Außerdem können Entwickler bei dieser Gelegenheit die Notwendigkeit der Hintergrundaktionen von Apps überdenken, ausgetretene Pfade verlassen und ein ressourcenschonenderes Verhalten der eigenen Apps anstreben.
Weitere Informationen finden Sie unter:
https://developer.android.com/about/versions/oreo/background.html
https://developer.android.com/about/versions/oreo/background-location-limits.html