Auf dieser Seite erfahren Sie, wie Sie die Cloud-Sicherungen und den D2D-Übertragungsprozess (Gerät-zu-Gerät) für Ihre App testen. Es ist wichtig, beide mit jedem Hauptrelease Ihrer App zu testen, damit Ihre Nutzer Ihre App weiterhin auf einem neuen Gerät verwenden können. Sicherung und Übertragung ähneln sich zwar, aber unter Android 12 (API-Level 31) und höher gibt es wichtige Unterschiede zwischen den beiden Funktionen. Das größte ist, dass die Datenübertragung eine viel größere Datengröße von 2 GB hat, verglichen mit 25 MB bei der Cloud-Sicherung.
In diesem Leitfaden erfahren Sie, wie Sie sowohl die Cloud-Sicherung und -Wiederherstellung als auch die D2D-Übertragung während des gesamten Entwicklungszyklus effizient testen können.
So funktionieren Sicherungstests
In diesem Abschnitt werden verschiedene Teile des Android-Sicherungsframeworks und ihre Interaktion mit Apps beschrieben, die die automatische Sicherung und die Sicherung von Schlüssel/Wert-Paaren unterstützen. Während der App-Entwicklungsphase werden die meisten internen Funktionen des Frameworks abstrahiert, sodass Sie diese Informationen nicht kennen müssen. Während der Testphase wird jedoch ein Verständnis dieser Konzepte immer wichtiger.
Das folgende Diagramm veranschaulicht den Datenfluss bei der Sicherung und Wiederherstellung in der Cloud. Zu Testzwecken kann dasselbe Gerät für die Sicherung und Wiederherstellung in der Cloud verwendet werden.
Das folgende Diagramm veranschaulicht den Datenfluss bei einer D2D-Übertragung:
Im Gegensatz zu Tests in der Cloud für Back-ups und Wiederherstellungen benötigen D2D-Tests ein Quell- und ein Zielgerät, von dem und auf das kopiert werden kann.
Der Backup Manager Service ist ein Android-Systemdienst, der Sicherungs- und Wiederherstellungsvorgänge orchestriert und initiiert. Der Dienst ist über die Backup Manager API zugänglich.
Während eines Sicherungsvorgangs fragt der Dienst Ihre App nach Sicherungsdaten und übergibt sie dann an den Sicherungs-Transport, der die Daten in der Cloud archiviert. Während eines Wiederherstellungsvorgangs ruft der Sicherungsmanagerdienst die Sicherungsdaten aus dem Sicherungstransport ab und stellt sie auf dem Gerät wieder her. Bei einer D2D-Übertragung fragt der Sicherungsmanagerdienst Ihre App nach Sicherungsdaten und leitet sie direkt an den Sicherungsmanagerdienst auf dem neuen Gerät weiter, der sie in Ihre App lädt.
Sicherungstransporte sind Android-Komponenten, die für das Speichern und Abrufen Ihrer App-Daten verantwortlich sind. Ein Android-Gerät kann null oder mehrere Sicherungstransporte haben, aber nur einer dieser Transports kann als aktiv markiert werden. Die verfügbaren Sicherungstransporte unterscheiden sich je nach Gerät aufgrund von Anpassungen durch Gerätehersteller und Dienstanbieter. Die meisten Google Play-kompatiblen Geräte werden jedoch mit den folgenden Transporten geliefert:
- GMS-Transport: Der aktive Cloud-Sicherungs-Transport auf den meisten Geräten, Teil der Google Mobile Services. Dabei werden die Daten im Android-Sicherungsservice gespeichert.
- D2D-Transport: Dieser Transport wird bei der D2D-Migration verwendet, um Daten direkt von einem Gerät zum anderen zu übertragen.
Tools
Wenn Sie Ihre Sicherungs- und Wiederherstellungsvorgänge testen möchten, müssen Sie die folgenden Tools kennen.
adb: zum Ausführen von Befehlen auf dem Gerät oder Emulator.bmgr: verschiedene Sicherungs- und Wiederherstellungsvorgänge ausführen.logcat: um die Ausgabe der Sicherungs- und Wiederherstellungsvorgänge aufzurufen.
Cloud-Sicherung testen
Die Cloud-Sicherung und -Wiederherstellung kann mit einem einzelnen Gerät durchgeführt werden. Folgen Sie dazu der Anleitung in diesem Abschnitt.
Gerät oder Emulator für Cloud-Sicherungen vorbereiten
Bereiten Sie Ihr Gerät oder Ihren Emulator auf die Sicherungstests vor. Gehen Sie dazu die folgende Checkliste durch:
- Für die automatische Sicherung muss auf dem Gerät oder Emulator Android 6.0 (API-Level 23) oder höher installiert sein.
- Für die Schlüssel/Wert-Sicherung benötigen Sie ein Gerät oder einen Emulator mit Android 2.2 (API-Level 8) oder höher.
- Sie benötigen eine Internetverbindung, um die Cloud-Sicherung zu testen.
- Melden Sie sich mit einem Google-Konto auf dem Gerät an und legen Sie es unter Einstellungen -> Google -> Sicherung als Sicherungskonto fest.
Um die Cloud-Sicherung zu testen, lösen Sie eine Cloud-Sicherung aus. Deinstallieren Sie dann die App und installieren Sie sie neu. Verwenden Sie das folgende Skript test_cloud_backup.sh, um diese Schritte wiederholbar zu machen. Damit wird Ihre App gesichert, das APK lokal heruntergeladen, deinstalliert und das APK neu installiert:
#!/bin/bash -eu
: "${1?"Usage: $0 package name"}"
# Initialize and create a backup
adb shell bmgr enable true
adb shell bmgr transport com.android.localtransport/.LocalTransport | grep -q "Selected transport" || (echo "Error: error selecting local transport"; exit 1)
adb shell settings put secure backup_local_transport_parameters 'is_encrypted=true'
adb shell bmgr backupnow "$1" | grep -F "Package $1 with result: Success" || (echo "Backup failed"; exit 1)
# Uninstall and reinstall the app to clear the data and trigger a restore
apk_path_list=$(adb shell pm path "$1")
OIFS=$IFS
IFS=$'\n'
apk_number=0
for apk_line in $apk_path_list
do
(( ++apk_number ))
apk_path=${apk_line:8:1000}
adb pull "$apk_path" "myapk${apk_number}.apk"
done
IFS=$OIFS
adb shell pm uninstall --user 0 "$1"
apks=$(seq -f 'myapk%.f.apk' 1 $apk_number)
adb install-multiple -t --user 0 $apks
# Clean up
adb shell bmgr transport com.google.android.gms/.backup.BackupTransportService
rm $apks
echo "Done"
Testschritte
- Öffnen Sie die App, melden Sie sich an und ändern Sie alle Einstellungen.
- Führen Sie das Script aus und geben Sie dabei den Paketnamen an, z. B.
test_cloud_backup.sh com.example.myapp. - Öffnen Sie die Anwendung noch einmal und prüfen Sie, ob sie ordnungsgemäß funktioniert und alle Daten beibehalten werden.
Sie möchten nicht, dass sich Ihre Nutzer anmelden müssen und alle Einstellungen, Fortschritte und Anwendungsdaten so wie zuvor sind. Wenn Ihre Testergebnisse diese Kriterien nicht erfüllen, prüfen Sie, ob Sie die Sicherungen richtig konfiguriert haben, ohne wichtige Daten auszulassen, und ob Sie auch die Wiederherstellung aller im Cache gespeicherten Daten, die Sie von der Sicherung ausgeschlossen haben, verwalten. Wiederholen Sie die Schritte 1 bis 3 für jede Testiteration.
D2D-Übertragung testen
Die umfassendste Möglichkeit, die D2D-Übertragung zu testen, besteht darin, den gesamten Inhalt Ihres Smartphones auf ein neues, auf die Werkseinstellungen zurückgesetztes Gerät zu übertragen und zu prüfen, ob es richtig funktioniert. Das kann jedoch umständlich und zeitaufwendig sein, wenn Sie den Vorgang mehrmals wiederholen müssen. Diese Schritte zeigen, wie Sie eine Übertragung mit einem einzelnen Gerät simulieren, ohne das Gerät wiederholt auf die Werkseinstellungen zurückzusetzen.
Gerät für D2D-Tests vorbereiten
So bereiten Sie ein Gerät für den D2D-Transfer vor:
- Auf deinem Gerät muss Android 12 (API-Level 31) oder höher installiert sein.
- Wenn du die neueste Version von D2D testen möchtest, richte deine App auf Android 12 (API-Level 31) oder höher aus.
- Erstellen Sie das folgende Script
test_d2d.sh, um die Wiederholung des Tests zu unterstützen:
#!/bin/bash -eu
: "${1?"Usage: $0 package name"}"
# Initialize and create a backup
adb shell bmgr enable true
adb shell settings put secure backup_enable_d2d_test_mode 1
adb shell bmgr transport com.google.android.gms/.backup.migrate.service.D2dTransport
adb shell bmgr init com.google.android.gms/.backup.migrate.service.D2dTransport
adb shell bmgr list transports | grep -q -F " * com.google.android.gms/.backup.migrate.service.D2dTransport" || (echo "Failed to select and initialize backup transport"; exit 1)
adb shell bmgr backupnow "$1" | grep -F "Package $1 with result: Success" || (echo "Backup failed"; exit 1)
# Uninstall and reinstall the app to clear the data and trigger a restore
apk_path_list=$(adb shell pm path "$1")
OIFS=$IFS
IFS=$'\n'
apk_number=0
for apk_line in $apk_path_list
do
(( ++apk_number ))
apk_path=${apk_line:8:1000}
adb pull "$apk_path" "myapk${apk_number}.apk"
done
IFS=$OIFS
adb shell pm uninstall --user 0 "$1"
adb shell bmgr transport com.google.android.gms/.backup.BackupTransportService
apks=$(seq -f 'myapk%.f.apk' 1 $apk_number)
adb install-multiple -t --user 0 $apks
# Clean up
adb shell bmgr init com.google.android.gms/.backup.migrate.service.D2dTransport
adb shell settings put secure backup_enable_d2d_test_mode 0
adb shell bmgr transport com.google.android.gms/.backup.BackupTransportService
rm $apks
echo "Done"
Testschritte
- Installieren Sie die App, die Sie testen möchten, auf dem Gerät.
- Öffnen Sie die App, melden Sie sich an und ändern Sie die Einstellungen der App.
- Führen Sie das Script auf Ihrem Gerät aus und geben Sie den Paketnamen ein, z. B.
test_d2d.sh com.example.myapp. - Wenn das Script abgeschlossen ist, öffnen Sie die App auf dem Gerät und prüfen Sie, ob sie richtig funktioniert und alle Daten erhalten geblieben sind.
Ihre Nutzer sollen sich nicht anmelden müssen und alle ihre Einstellungen, ihr Fortschritt und ihre App-Daten müssen so angezeigt werden, wie vor dem Ausführen des Scripts. Wenn Ihre Testergebnisse diese Kriterien nicht erfüllen, prüfen Sie, ob Sie die Übertragung richtig konfiguriert haben, ohne wichtige Daten zu überspringen, und ob Sie auch die Wiederherstellung aller im Cache gespeicherten Daten vornehmen, die Sie von der Übertragung ausgeschlossen haben. Wiederholen Sie die Schritte 2 bis 4 für jede Testiteration.
Fehler bei der Sicherung und Wiederherstellung beheben
In diesem Abschnitt erfahren Sie, wie Sie einige häufige Probleme beheben.
Transportkontingent überschritten
Die folgenden Meldungen in Logcat geben an, dass Ihre App das Transportkontingent überschritten hat:
I/PFTBT: Transport rejected backup of <PACKAGE>, skipping
--- or ---
I/PFTBT: Transport quota exceeded for package: <PACKAGE>
Verringern Sie die Menge der Sicherungsdaten und versuchen Sie es noch einmal. Prüfen Sie beispielsweise, ob Sie Daten nur im Cache-Verzeichnis Ihrer App zwischenspeichern. Das Cache-Verzeichnis ist nicht in Back-ups enthalten.
Vollsicherung nicht möglich
Die folgende Meldung in Logcat gibt an, dass der vollständige Sicherungsvorgang fehlgeschlagen ist, weil noch kein Schlüssel/Wert-Sicherungsvorgang auf dem Gerät ausgeführt wurde:
I/BackupManagerService: Full backup not currently possible -- key/value backup
not yet run?
Lösen Sie eine Schlüssel/Wert-Sicherung mit dem Befehl bmgr run aus und versuchen Sie es noch einmal.
Zeitüberschreitung beim Warten auf den Kundenservicemitarbeiter
Die folgende Meldung in Logcat gibt an, dass der Start Ihrer App für die Sicherung länger als 10 Sekunden dauert:
12-05 18:59:02.033 1910 2251 D BackupManagerService:
awaiting agent for ApplicationInfo{5c7cde0 com.your.app.package}
12-05 18:59:12.117 1910 2251 W BackupManagerService:
Timeout waiting for agent ApplicationInfo{5c7cde0 com.your.app.package}
12-05 18:59:12.117 1910 2251 W BackupManagerService:
Can't find backup agent for com.your.app.package
Beachten Sie den Zeitstempelunterschied in der Protokollausgabe. Dieser Fehler tritt in der Regel auf, wenn Ihre App eine Multidex-Konfiguration ohne ProGuard verwendet.
Nicht initialisiertes Sicherungskonto
Die folgenden Meldungen in Logcat geben an, dass die Sicherung angehalten wurde, weil der Sicherungsdatensatz nicht initialisiert wurde:
01-31 14:32:45.698 17280 17292 I Backup: [GmsBackupTransport] Try to backup for
an uninitialized backup account.
01-31 14:32:45.699 1043 18255 W PFTBT: Transport failed; aborting backup: -1001
01-31 14:32:45.699 1043 18255 I PFTBT: Full backup completed with status: -1000
Führen Sie den Sicherungsmanager mit dem Befehl adb shell bmgr run aus und versuchen Sie dann noch einmal, die Sicherung durchzuführen.
Nicht aufgerufene App-Methoden
Da die automatische Sicherung Ihre App mit der Basisklasse Application startet, werden die Einrichtungsmethoden Ihrer App möglicherweise nicht aufgerufen. Bei der automatischen Sicherung werden auch keine Aktivitäten Ihrer App gestartet. Daher können Fehler auftreten, wenn Ihre App in einer Aktivität eingerichtet wird. Weitere Informationen finden Sie unter BackupAgent implementieren.
Im Gegensatz dazu wird Ihre App bei der Sicherung mit Schlüssel/Wert-Paaren mit jeder abgeleiteten Application-Klasse gestartet, die Sie in der App-Manifestdatei deklarieren.
Keine Daten zum Sichern
Die folgenden Meldungen in Logcat geben an, dass Ihre App keine Daten zum Sichern hat:
I Backup : [FullBackupSession] Package com.your.app.package doesn't have any backup data.
--- or ---
I Backup : [D2dTransport] Package com.your.app.package doesn't have any backup data.
Wenn Sie Ihre eigene BackupAgent implementiert haben, bedeutet das wahrscheinlich, dass Sie der Sicherung keine Daten oder Dateien hinzugefügt haben.