Auf dieser Seite erfahren Sie, wie Sie die Cloud-Back-ups und den Prozess für die Geräte-zu-Gerät-Übertragung (D2D) für Ihre App testen. Es ist wichtig, beide Prozesse bei jeder Hauptversion Ihrer App zu testen, damit Ihre Nutzer Ihre App weiterhin auf einem neuen Gerät verwenden können. Sicherung und Übertragung sind zwar ähnlich, aber es gibt wichtige Unterschiede zwischen den beiden in Android 12 (API-Level 31) und höher. Der wichtigste Unterschied ist, dass die Übertragung ein viel höheres Datenlimit von 2 GB hat, verglichen mit 25 MB für die Cloud-Sicherung.
In diesem Leitfaden erfahren Sie, wie Sie sowohl Cloud-Sicherung und ‑Wiederherstellung als auch D2D-Übertragung während des gesamten Entwicklungszyklus effizient testen können.
So funktioniert das Testen von Sicherungen
In diesem Abschnitt werden verschiedene Komponenten des Android-Sicherungsframeworks und ihre Interaktion mit Apps beschrieben, die die automatische Sicherung und die Schlüssel/Wert-Sicherung unterstützen. Während der App-Entwicklungsphase werden die meisten internen Abläufe des Frameworks abstrahiert, sodass Sie diese Informationen nicht benötigen. Während der Testphase ist es jedoch wichtig, diese Konzepte zu verstehen.
Das folgende Diagramm zeigt, wie Daten während der Cloud-Sicherung und ‑Wiederherstellung fließen. Zu Testzwecken kann dasselbe Gerät für die Cloud-Sicherung und ‑Wiederherstellung verwendet werden.
Das folgende Diagramm veranschaulicht den Datenfluss während einer D2D-Übertragung:
Im Gegensatz zu Cloud-Sicherungs- und ‑Wiederherstellungstests sind für D2D-Tests ein Quellgerät und ein Zielgerät erforderlich, von denen bzw. auf die kopiert werden kann.
Der Backup Manager Service ist ein Android-Systemdienst, der Sicherungs- und Wiederherstellungsvorgänge koordiniert 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. Bei einem Wiederherstellungsvorgang ruft der Backup Manager Service die Sicherungsdaten vom Sicherungstransport ab und stellt die Daten auf dem Gerät wieder her. Bei einer D2D-Übertragung fragt der Backup Manager Service Ihre App nach Sicherungsdaten ab und übergibt sie direkt an den Backup Manager Service auf dem neuen Gerät, der sie in Ihre App lädt.
Backup Transports sind Android-Komponenten, die für das Speichern und Abrufen Ihrer App-Daten verantwortlich sind. Ein Android-Gerät kann null oder mehrere Sicherungsübertragungsarten haben, aber nur eine davon kann als aktiv markiert sein. Die verfügbaren Sicherungsübertragungen unterscheiden sich je nach Gerät aufgrund von Anpassungen durch Gerätehersteller und Dienstanbieter. Die meisten Google Play-fähigen Geräte werden jedoch mit den folgenden Übertragungen ausgeliefert:
- GMS-Transport:Der aktive Cloud-Sicherungstransport auf den meisten Geräten, Teil der Google Mobile-Dienste. Bei diesem Transport werden Daten im Android Backup Service gespeichert.
- D2D-Transport:Dieser Transport wird bei der D2D-Migration verwendet, um Daten direkt von einem Gerät auf ein anderes zu übertragen.
Tools
Um Ihre Sicherungs- und Wiederherstellungsvorgänge zu testen, müssen Sie sich mit den folgenden Tools auskennen.
adb: Befehle auf dem Gerät oder Emulator ausführen.bmgr: zum Ausführen verschiedener Sicherungs- und Wiederherstellungsvorgänge.logcat: um die Ausgabe von Sicherungs- und Wiederherstellungsvorgängen zu sehen.
Cloud-Backup testen
Cloud-Sicherungen und ‑Wiederherstellungen können mit einem einzelnen Gerät durchgeführt werden, indem Sie die Schritte in diesem Abschnitt ausführen.
Gerät oder Emulator für Cloud-Sicherungen vorbereiten
Bereiten Sie Ihr Gerät oder Ihren Emulator für das Testen von Sicherungen vor, indem Sie die folgende Checkliste durchgehen:
- Prüfen Sie, ob Sie für die automatische Sicherung ein Gerät oder einen Emulator mit Android 6.0 (API‑Level 23) oder höher verwenden.
- Prüfen Sie, ob Sie für die Sicherung von Schlüssel/Wert-Paaren ein Gerät oder einen Emulator mit Android 2.2 (API-Level 8) oder höher verwenden.
- Sie benötigen eine Internetverbindung, um die Cloud-Sicherung zu testen.
- Melden Sie sich auf dem Gerät mit einem Google-Konto an und legen Sie es unter Einstellungen > Google > Sicherung als Sicherungskonto fest.
Wenn Sie die Cloud-Sicherung testen möchten, lösen Sie eine Cloud-Sicherung aus und deinstallieren und installieren Sie die App dann neu. Damit diese Schritte wiederholbar sind, können Sie das folgende Skript test_cloud_backup.sh verwenden, mit dem Ihre App gesichert, das APK lokal heruntergeladen, die App deinstalliert und das APK neu installiert wird:
#!/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 Skript aus und übergeben Sie Ihren Paketnamen, 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.
Sie möchten nicht, dass sich Ihre Nutzer anmelden müssen, und alle Einstellungen, Fortschritte und 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 Neuerstellung aller im Cache gespeicherten Daten berücksichtigen, die Sie aus der Sicherung ausgeschlossen haben. Wiederholen Sie die Schritte 1 bis 3 für jede Testiteration.
D2D-Übertragung testen
Am besten testen Sie die D2D-Übertragung, indem Sie den gesamten Inhalt Ihres Smartphones auf ein neues, auf die Werkseinstellungen zurückgesetztes Gerät übertragen und prüfen, ob alles richtig funktioniert. Das kann jedoch umständlich und zeitaufwendig sein, wenn Sie den Vorgang mehrmals wiederholen müssen. In dieser Anleitung erfahren Sie, wie Sie eine Übertragung mit einem einzelnen Gerät simulieren können, ohne das Gerät wiederholt auf die Werkseinstellungen zurückzusetzen.
Gerät für D2D-Tests vorbereiten
So bereiten Sie ein einzelnes Gerät für den D2D-Transfer vor:
- Auf Ihrem Gerät muss Android 12 (API‑Level 31) oder höher ausgeführt werden.
- 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 Skript auf Ihrem Gerät aus und übergeben Sie Ihren Paketnamen, z. B.
test_d2d.sh com.example.myapp. - Wenn das Skript fertig ist, öffnen Sie die App auf dem Gerät und prüfen Sie, ob sie korrekt funktioniert und alle Daten beibehalten wurden.
Sie möchten nicht, dass sich Ihre Nutzer anmelden müssen, und alle ihre Einstellungen, Fortschritte und App-Daten müssen so angezeigt werden wie vor der Ausführung des Skripts. Wenn Ihre Testergebnisse diese Kriterien nicht erfüllen, prüfen Sie, ob Sie die Übertragung richtig konfiguriert haben, ohne wichtige Daten auszulassen, und ob Sie auch die Neuerstellung aller im Cache gespeicherten Daten berücksichtigen, die Sie von der Übertragung ausgeschlossen haben. Wiederholen Sie die Schritte 2 bis 4 für jede Testiteration.
Fehlerbehebung bei Sicherung und Wiederherstellung
In diesem Abschnitt finden Sie Hilfe bei der Behebung einiger häufiger Probleme.
Transportkontingent überschritten
Die folgenden Meldungen in Logcat weisen darauf hin, 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 speichern. 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 auf dem Gerät noch kein Key-Value-Sicherungsvorgang stattgefunden hat:
I/BackupManagerService: Full backup not currently possible -- key/value backup
not yet run?
Lösen Sie mit dem Befehl bmgr run eine Schlüssel/Wert-Sicherung aus und versuchen Sie es noch einmal.
Zeitlimit für Warten auf 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
Achten Sie auf den Zeitstempelunterschied in der Logausgabe. 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 das Sicherungs-Dataset 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 Backup-Manager mit dem Befehl adb shell bmgr run aus und versuchen Sie dann noch einmal, die Sicherung durchzuführen.
App-Methoden nicht aufgerufen
Da Auto Backup Ihre App mit einer Basisklasse von Application startet, werden die Einrichtungsmethoden Ihrer App möglicherweise nicht aufgerufen. Die automatische Sicherung startet auch keine Aktivitäten Ihrer App. Wenn Ihre App also eine Einrichtung in einer Aktivität durchführt, werden möglicherweise Fehler angezeigt. Weitere Informationen finden Sie unter BackupAgent implementieren.
Beim Key-Value-Backup wird Ihre App dagegen mit jeder Application-Unterklasse gestartet, die Sie in der Manifestdatei Ihrer App deklarieren.
Keine Daten zum Sichern
Die folgenden Meldungen in Logcat weisen darauf hin, 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.