Neues Android-Handy: Welche Daten Ihrer Geschäfts-App sollen wirklich mitkommen?
Eine App auf einem neuen Handy zu installieren ist nicht dasselbe wie ihre bisherigen lokalen Daten wiederherzustellen. Legen Sie vor der Entwicklung fest, welche Einstellungen und Entwürfe übertragen werden sollen, welche Informationen vom Server neu geladen werden und welche gerätebezogenen Daten ausdrücklich nicht mitkommen dürfen.
Diese Entscheidung betrifft den Gerätewechsel und die Wiederherstellung von App-Daten. Sie ist weder die Archivierung einer selten genutzten App auf demselben Telefon noch ein Zurücksetzen Ihrer zentralen Geschäftsdatenbank. Eine pauschale Zusage „Ihre Daten bleiben erhalten“ beschreibt keinen dieser Abläufe ausreichend.
Zuerst die Daten in verständliche Gruppen einteilen
Erstellen Sie mit dem Entwickler eine kurze Liste: wiederherstellbare Einstellungen, schützenswerte lokale Arbeit, erneut herunterladbare Dateien und gerätespezifische Zustände. Für jede Gruppe braucht es eine vereinbarte Behandlung beim Gerätewechsel.
Ein auf dem Server bestätigter Auftrag sollte nach berechtigter Anmeldung aus dem aktuellen führenden System kommen. Ein noch nicht übermittelter Entwurf kann dagegen ausschließlich auf dem alten Gerät existieren. Eine Kopie der Bedienoberfläche beweist nicht, dass dieser Entwurf überhaupt gesichert wurde.
Die offizielle Android-Dokumentation zu Auto Backup beschreibt, dass standardmäßig viele App-Dateien, lokale Datenbanken und Einstellungen einbezogen werden können. Cache-Verzeichnisse und das ausdrücklich für nicht zu sichernde Daten vorgesehene Verzeichnis sind ausgenommen. Entwickler können zusätzliche Ein- und Ausschlussregeln definieren. Lassen Sie deshalb die tatsächliche Zuordnung Ihrer Daten zeigen, statt aus dem Namen einer Speicherfunktion eine Sicherungszusage abzuleiten.
Automatische Sicherung ist keine laufende Synchronisierung
Android nennt Voraussetzungen für automatische Sicherungen, darunter die aktivierte Gerätesicherung, einen zeitlichen Abstand zur vorherigen Sicherung, ein unbeschäftigtes Gerät und eine geeignete Netzwerkverbindung. Die Dokumentation weist ausdrücklich darauf hin, dass ein Gerät unter Umständen nie gesichert wird.
Damit ist ein frisch gespeicherter lokaler Entwurf nicht automatisch auf einem Ersatzgerät verfügbar. Vereinbaren Sie, wie die App lokale Arbeit kennzeichnet und welcher gesonderte Ablauf für wichtige noch nicht übermittelte Daten vorgesehen ist. Versprechen Sie weder einen minutengenauen Sicherungsstand noch eine erfolgreiche Wiederherstellung allein aufgrund der Plattformfunktion.
Auch der Umfang ist begrenzt. Android dokumentiert für Auto Backup ein Kontingent pro App und Nutzer; bei dessen Überschreitung wird die Cloud-Sicherung nicht durchgeführt, bis die beschriebene Voraussetzung wieder erfüllt ist. Der Entwickler sollte mit der tatsächlichen Datenmenge testen und unnötig große, erneut ladbare Dateien nicht unbemerkt zum Hindernis für wertvolle lokale Arbeit machen.
Cloud-Sicherung und direkte Übertragung getrennt prüfen
Ein Umzug mit beiden Telefonen und eine Wiederherstellung ohne verfügbares Altgerät sind verschiedene Prüffälle. Android erlaubt je nach Betriebssystem und Zielversion der App unterschiedliche Regeln für Cloud-Sicherung und direkte Geräteübertragung.
Besonders wichtig: Für Apps mit Zielversion Android 12 oder höher kann das Abschalten von android:allowBackup auf Geräten mancher Hersteller zwar die Cloud-Sicherung verhindern, nicht aber die direkte Geräteübertragung. „Backup ausgeschaltet“ ist deshalb ohne Versions- und Gerätebezug keine vollständige Aussage darüber, ob Daten das Telefon verlassen können.
Lassen Sie die unterstützte Kombination aus Android-Version, App-Zielversion und vorgesehenen Geräten nennen. Prüfen Sie ausdrücklich beide Übertragungswege, sofern sie zum vereinbarten Umfang gehören. Dieser Beitrag verspricht keine Unterstützung eines Wechsels auf ein anderes Betriebssystem; das wäre eine zusätzliche, gesondert zu bestätigende Anforderung.
Wiederhergestellte Daten brauchen eine aktuelle Berechtigungsprüfung
Ein alter lokaler Kundenstand beweist nicht, dass das Konto heute noch Zugriff hat. Die Anwendung sollte nach dem vereinbarten Anmelde- und Berechtigungskonzept aktuelle Daten laden und unberechtigte Detailansichten verhindern. Eine wiederhergestellte Einstellung darf keine entzogene Rolle zurückbringen.
Gerätekennungen brauchen ebenfalls eine bewusste Behandlung. Die Android-Dokumentation nennt solche Kennungen als typische Ausschlüsse und erklärt am Beispiel von Benachrichtigungsregistrierungen, dass die Übernahme eines alten gerätebezogenen Werts unerwartetes Verhalten verursachen kann. Fordern Sie daher eine Prüfung der gerätegebundenen Zustände, nicht das unkritische Kopieren sämtlicher Dateien.
Für Anmeldedaten und sensible Informationen muss der Entwickler das geeignete Plattform- und Sicherheitskonzept benennen. Ein zusätzliches Textfeld oder das blinde Mitnehmen einer lokalen Datei ist kein hier empfohlenes Wiederherstellungsverfahren. Die konkrete Schutzwirkung benötigt eigene Prüfung.
Einen echten Wiederanlauf abnehmen
Nutzen Sie Testgeräte und erfundene Konten für Ihre Abnahmekriterien. Prüfen Sie eine vorgesehene Cloud-Wiederherstellung und, falls vereinbart, einen direkten Gerätewechsel. Kontrollieren Sie danach jede zugesagte Datengruppe einzeln.
Ergänzen Sie einen nicht gesicherten Entwurf, eine ausgeschlossene Datei, erneut ladbare Inhalte und ein Konto, dessen Zugriff inzwischen geändert wurde. Wiederhergestellte lokale Arbeit muss vor einer Übermittlung wieder dem richtigen Konto und dem aktuellen Geschäftsvorgang zugeordnet werden. Sie darf keine bereits bestätigte Serveraktion blind ein zweites Mal auslösen.
Dokumentieren Sie, welche Geräte und Übertragungswege tatsächlich erprobt wurden. Zum Gespräch über Ihre Android-App genügt eine leere Datenübersicht ohne vertrauliche Inhalte. Das Ziel ist ein erklärbarer Wechsel zurück zur erlaubten Arbeit, nicht ein pauschales Versprechen, dass auf einem neuen Telefon alles genauso bleibt.