Features von Android Marshmallow Teil 3

Autobackup in Android Marshmallow: Das müssen Entwickler wissen

Michael Gruczel

©Shutterstock/taromanaiai

Dieser Beitrag beleuchtet die neue Autobackup-Funktionalität, welche mit Android Marshmallow Anwendern zur Verfügung stehen wird. Mit Hilfe dieser Funktionalität soll dem Nutzer das Wechseln eines Smartphones, ohne Verlust seiner Einstellungen, ermöglicht werden – ohne den Entwickler dafür Code schreiben zu lassen.

Was hat es mit Autobackup auf sich ?

Mit Android Marshmallow macht Google den Entwicklern das automatische Backup von Anwendungen leichter. Vor Android 6.0 (API level 23) wurden App-Daten nicht automatisch wiederhergestellt. Damit sind häufig alle Einstellungen bei einem Wechsel auf ein anderes Smartphone verloren gegangen, wenn die Entwickler keine eigene Lösung oder die von Google angebotene Backup API angebunden haben. Mit Android 23 ist dies nicht mehr nötig.

Devices, auf denen Android 6.0 oder eine neuere Androidversion läuft und die auch mit Android 6.0 als Zielplattform gebaut wurden, machen automatisch ein Backup in der Google Cloud. Entwickler müssen dafür keinen Code schreiben. Das Backup wird durchgeführt, wenn das Gerät lädt, sich im Wi-Fi befindet, es gerade nicht genutzt wird und seit dem letzten Backup mehr als 24 Stunden vergangen sind. Damit könnte man diesen Blogbeitrag ja eigentlich schon abschliessen, wenn nicht einige Sachen zu beachten wären.

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

Warum muss ich als Entwickler handeln ?

Als Entwickler muss ich handeln, weil das Autobackup auch ohne Code-Änderungen wirksam wird und dann zu unerwünschtem Verhalten führen kann. Es stellt sich deshalb die Frage, welche Daten in die Cloud gehören und welche dort nicht abgelegt werden sollten. Manche Daten sind auf einem anderen Gerät einfach nutzlos. So wird ein GCM Token (also die Identifikation des Gerätes für das Cloud Messaging) zum Beispiel auf einem anderen Gerät nicht funktionieren und sollte deshalb nicht wiederhergestellt, sondern neu angefordert werden. Auch wenn die Anwender beim Einrichten des Google Accounts der Nutzung der Google Cloud als Backup zustimmen müssen, sollte mit sensitiven Daten vorsichtig umgegangen werden.

Abgesehen davon sollte sich der Entwickler nur bedingt auf das Autobackup verlassen. Der Anwender könnte der Synchronisation nicht zustimmen oder die Anwendung könnte in das Mengenlimit fallen. Der Dienst ist zwar kostenlos und die Daten werden dem User nicht an seine persönlichen Google Drive Quotas angerechnet, aber jede App kann nur bis zu 25 MB speichern. Danach wird die Synchronisation nicht mehr durchgeführt. 25 MB sind eine Menge für Konfigurationen, aber sehr wenig für Medien.

Wie können Daten vom Backup ausgeschlossen werden ?

Ohne jegliche Konfiguration wird automatisch alles in die Cloud gelegt, außer einige temporäre Daten, zum Beispiel Daten, welche durch getCacheDir(), getCodeCacheDir(), getNoBackupFilesDir() referenziert werden. Um dies zu ändern, kann das Backup gänzlich deaktiviert werden (android:allowBackup=“false“ innerhalb der Deklaration der Applikation in der Manifest Datei) oder es kann explizit definiert werden, welche Daten vom Backup ausgeschlossen werden sollen. Dies möchte ich an zwei Beispiel verdeutlichen.

 


 
...




    
    
	

In dem ersten Beispiel aus Listing 1 und 2 würden shared preferences, die unter dem Key gcm abgelegt sind, excluded werden. Ebenso die Datenbank device_info nicht ins Backup eingehen. Dabei würde Listing 2 in einer Datei namens backupscheme.xml im res/xml/ Ordner abgelegt werden und dann im Manifest (Listing 1) referenziert werden. Alternativ ist es auch möglich, anstatt Dateien vom Backup auszuschliessen, den umgekehrten Weg zu gehen und explizit Daten für das Backup zu includen. Existiert eine include-Anweisung, so wird das automatische Backup auf die angegeben includes reduziert.



    
    


 

    SharedPreferences prefsInclude = this.getSharedPreferences(
                "test", Context.MODE_PRIVATE);
    prefsInclude.edit().putString("elem", “something”).apply();

Listing 3 zeigt ein solches Beispiel in dem nur die Datenbank (der Datenbankname wäre hier device_info.db) und die shared preferences unter dem Pfad test gesichert werden würden (Listing 4 zeigt beispielhaft den Zugriff auf die shared preferences unter dem Pfad „test“).

Ebenso kann der oberste Ordner der App (root) oder externer Speicher (external) in includes oder excludes angegeben werden. Die genaue Spezifikation der Konfiguration vernachlässige ich hier, weil die Beispiele die Einfachheit und Mächtigkeit bereits aufzeigen. Diese kann aber hier nachgelesen werden.

Wie sieht es mit der Kompatibilität aus ?

Autobackup funktioniert auf Geräten mit Android 23. Wenn Backups auf älteren Geräten funktionieren sollen, so ist dies nicht durch Autobackup abgedeckt, aber kann zum Beispiel mittels der bereits vorhandenen Backup API implementiert werden. Dies ist deutlich komplizierter. Zunächst muss ein Konto für den ebenso kostenlosen Backup Service angelegt werden und nach einer Konfiguration des Zugangs im Manifest muss dann ein Backup-Agent implementiert werden. Dieser Agent kann mit Hilfe von Hilfsklassen einzelne Elemente sichern. Die Wiederherstellung kann dann ebenso im Code angefragt werden. Nähere Details sind hier zu finden. Soll nun auf Geräten mit Android Marshmallow die AutoBackup-Funktionalität verwendet werden, aber auf älteren Geräten die Backup API, so kann dem Manifest der Eintrag android:fullBackupOnly=“true“ hinzugefügt werden. Dieser wird auf älteren Geräten ignoriert, sodass eine Implementierung mittels der Backup API weiterhin funktioniert. Auf neueren Geräten wird dann aber die neue Auto Backup-Lösung verwendet.

API Summit 2018
Christian Schwendtner

GraphQL – A query language for your API

mit Christian Schwendtner (PROGRAMMIERFABRIK)

DDD Summit 2018
Nicole Rauch

Domain-Driven Design für Einsteiger

mit Nicole Rauch (Softwareentwicklung und Entwicklungscoaching)

Wie teste ich Autobackup ?

Der Test eines Backups über die Cloud und die Wiederherstellung ist etwas umständlich. Listing 5 zeigt deshalb die Simulation über die Kommandozeile. Dabei wird zunächst ein lokaler Backup-Manager gestartet (anstatt der Cloud) und der Loglevel erhöht. Dann wird zunächst ein Backup einer Anwendung simuliert und dann das Backup wieder hergestellt. In dem Beispiel müsste natürlich der Package-Name mit dem Package der Anwendung ausgetauscht werden.

$ adb shell setprop log.tag.BackupXmlParserLogging VERBOSE
$ adb shell bmgr run
$ adb shell bmgr fullbackup 
$ adb shell bmgr restore 

Fazit und Ausblick

Wir haben gesehen, wie mit Hilfe des neuen Autobackups leicht Konfigurationen in der Cloud gesichert werden können und worauf dabei geachtet werden muss. Der nächste Teil schließt die Reihe um einige spannende Neuerungen in Android Marshmallow mit einem Einblick in die neue Fingerabdruck-API und einen Ausblick auf weitere Änderungen ab.

Aufmacherbild: Phone android M (6.0) is marshmallow von Shutterstock / Urheberrecht: taromanaiai

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: