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. Obwohl Sicherung und Übertragung ähnlich sind, gibt es wichtige Unterschiede zwischen den beiden in Android 12 (API-Level 31) und höher. Insbesondere hat die Übertragung ein viel größeres Datenlimit von 2 GB im Vergleich zu 25 MB für Cloud-Sicherungen.
In diesem Leitfaden wird beschrieben, wie Sie sowohl die Cloud-Sicherung und -Wiederherstellung als auch die D2D-Übertragung während des Entwicklungszyklus effizient testen können.
So funktioniert das Testen von Sicherungen
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 für die Cloud-Sicherung und -Wiederherstellung erfordern D2D-Tests ein Quell- und ein Zielgerät, von und auf das kopiert werden soll.
Der Backup Manager-Dienst ist ein Android-Systemdienst, der Sicherungs- und Wiederherstellungsvorgänge orchestrieren 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 Sicherungsübertragungen unterscheiden sich aufgrund von Anpassungen von Geräteherstellern und Dienstanbietern von Gerät zu Gerät. Die meisten Google Play-fähigen Geräte werden jedoch mit folgenden Transporten ausgeliefert:
- 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 auf ein anderes 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: zum Ansehen der Ausgabe von Sicherungs- und Wiederherstellungsvorgängen
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:
- Prüfen Sie für die automatische Sicherung, ob Sie ein Gerät oder einen Emulator mit Android 6.0 (API-Level 23) oder höher verwenden.
- 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, starten Sie eine Cloud-Sicherung und deinstallieren Sie die App dann. Sie können diese Schritte wiederholen, indem Sie das folgende Script test_cloud_backup.sh verwenden, das Ihre App sichert, das APK lokal herunterlädt, es deinstalliert und wieder 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 App noch einmal und prüfen Sie, ob sie ordnungsgemäß 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 sein wie zuvor. 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. Dies kann jedoch umständlich und zeitaufwendig sein, wenn Sie den Vorgang mehrmals wiederholen müssen. In diesen Schritten wird gezeigt, wie Sie eine Übertragung mit einem einzelnen Gerät simulieren, ohne das Gerät wiederholt auf die Werkseinstellungen zurücksetzen zu müssen.
Gerät für D2D-Tests vorbereiten
So bereiten Sie ein Gerät für den D2D-Transfer vor:
- Auf Ihrem Gerät muss Android 12 (API-Level 31) oder höher installiert sein.
- Wenn Sie die neueste Version von D2D testen möchten, richten Sie Ihre App auf Android 12 (API-Level 31) oder höher aus.
- Erstellen Sie das folgende Skript
test_d2d.sh, um eine 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 Skript auf Ihrem Gerät aus und übergeben Sie den Paketnamen, 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 Schlüsseldaten auszulassen, und dass Sie auch alle Daten im Cache wiederherstellen, die Sie von der Übertragung ausgeschlossen haben. Wiederholen Sie die Schritte 2 bis 4 für jeden Testdurchlauf.
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. Achten Sie beispielsweise darauf, dass Daten nur im Cache-Verzeichnis Ihrer Anwendung zwischengespeichert werden. Das Cache-Verzeichnis ist nicht in Sicherungen 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 einen Kundenservicemitarbeiter
Die folgende Meldung in Logcat zeigt an, dass der Start Ihrer Anwendung zur Sicherung mehr 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.
App-Methoden werden nicht aufgerufen
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.
Beim Schlüssel/Wert-Sicherungsmechanismus wird Ihre App dagegen mit einer beliebigen Application-Unterklasse gestartet, die Sie in der Manifestdatei Ihrer App deklarieren.
Keine zu sichernden Daten
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.