Sicherung und Wiederherstellung testen

Auf dieser Seite wird beschrieben, wie Sie die Cloud-Back-ups und die Übertragung von Gerät zu Gerät (D2D) für Ihre App testen. Es ist wichtig, beide Prozesse bei jedem Hauptrelease Ihrer App zu testen, damit Ihre Nutzer Ihre App weiterhin auf einem neuen Gerät verwenden können. Sowohl die Sicherung als auch die Übertragung sind ähnlich, es gibt jedoch 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 Datenvolumenlimit von 2 GB hat, verglichen mit 2 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 Auto Backup und Key-Value-Backup 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 die Daten während einer Cloud-Sicherung und ‑Wiederherstellung fließen:

Das folgende Diagramm veranschaulicht den Datenfluss während einer D2D-Übertragung:

Im Gegensatz zum Testen der Cloud-Sicherung und ‑Wiederherstellung 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 ab und übergibt sie 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 zuständig sind. Ein Android-Gerät kann null oder mehrere Sicherungstransporte haben, aber jeweils nur einer kann aktiv sein. Die verfügbaren Sicherungsübertragungen unterscheiden sich je nach Gerät, da Gerätehersteller und Dienstanbieter Anpassungen vornehmen. Die meisten Google Play-kompatiblen Geräte werden mit den folgenden Transportarten ausgeliefert:

• GMS Transport:Der aktive Cloud-Sicherungs-Transport auf den meisten Geräten, Teil der Google Mobile Services. In diesem Transport werden Daten im Android Backup Service gespeichert.
• D2D-Übertragung:Diese Übertragung 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: Zum Ausführen von Befehlen auf dem Gerät oder Emulator.
• bmgr: Zum Ausführen verschiedener Sicherungs- und Wiederherstellungsvorgänge.
• logcat: Hier sehen Sie die Ausgabe von Sicherungs- und Wiederherstellungsvorgängen.

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 Sicherungstests vor, indem Sie die folgende Checkliste durchgehen:

1. 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.
2. 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.
3. Sie benötigen eine Internetverbindung, um die Cloud-Sicherung zu testen.
4. Melden Sie sich auf dem Gerät mit einem Google-Konto an und legen Sie es in den 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

1. Öffnen Sie die App, melden Sie sich an und ändern Sie alle Einstellungen.
2. Führen Sie das Skript aus und übergeben Sie Ihren Paketnamen, z. B. test_cloud_backup.sh com.example.myapp.
3. Öffnen Sie die App noch einmal und prüfen Sie, ob sie richtig 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:

1. Auf Ihrem Gerät muss Android 12 (API‑Level 31) oder höher installiert sein.
2. Wenn Sie die aktuelle Version von D2D testen möchten, muss Ihre App auf Android 12 (API‑Level 31) oder höher ausgerichtet sein.
3. 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

1. Installieren Sie die App, die Sie testen möchten, auf dem Gerät.
2. Öffnen Sie die App, melden Sie sich an und ändern Sie die Einstellungen der App.
3. Führen Sie das Skript auf Ihrem Gerät aus und übergeben Sie Ihren Paketnamen, z. B. test_d2d.sh com.example.myapp.
4. 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.

Ihre Nutzer sollen sich nicht anmelden müssen und alle Einstellungen, Fortschritte und App-Daten müssen so angezeigt werden, wie vor dem Ausführen des Skripts. Wenn die Testergebnisse diese Kriterien nicht erfüllen, prüfen Sie, ob Sie die Übertragung richtig konfiguriert haben und keine wichtigen Daten ausgelassen haben. Achten Sie außerdem darauf, dass Sie die Neuerstellung aller im Cache gespeicherten Daten, die Sie von der Übertragung ausgeschlossen haben, richtig handhaben. 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.

Zeitüberschreitung beim Warten auf einen 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 Log-Ausgabe. 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 Back-up-Manager mit dem Befehl adb shell bmgr run aus und versuchen Sie dann noch einmal, das Back-up 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 Funktion „Automatische Sicherung“ startet auch keine Aktivitäten Ihrer App. Wenn Ihre App also eine Einrichtung in einer Aktivität vornimmt, werden möglicherweise Fehler angezeigt. Weitere Informationen finden Sie unter BackupAgent implementieren.

Beim Schlüssel/Wert-Backup wird Ihre App dagegen mit einer beliebigen 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 zu sichernden Daten 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 Ihren eigenen BackupAgent implementiert haben, bedeutet das wahrscheinlich, dass Sie der Sicherung keine Daten oder Dateien hinzugefügt haben.