Na tej stronie dowiesz się, jak przetestować kopie zapasowe w chmurze i proces przenoszenia danych z urządzenia na urządzenie (D2D) w przypadku Twojej aplikacji. Ważne jest, aby testować obie te funkcje przy każdej głównej wersji aplikacji, aby mieć pewność, że użytkownicy będą mogli nadal korzystać z aplikacji na nowym urządzeniu. Kopia zapasowa i przenoszenie danych są do siebie podobne, ale w Androidzie 12 (poziom API 31) i nowszych wersjach występują między nimi istotne różnice. Najważniejsza z nich to limit rozmiaru danych, który w przypadku przenoszenia wynosi 2 GB, a w przypadku kopii zapasowej w chmurze – 25 MB.
Z tego przewodnika dowiesz się, jak skutecznie testować tworzenie kopii zapasowych w chmurze i przywracanie danych oraz przesyłanie danych z urządzenia na urządzenie w trakcie całego cyklu programowania.
Jak działa testowanie kopii zapasowych
W tej sekcji opisujemy różne elementy struktury tworzenia kopii zapasowych na Androidzie i sposób, w jaki współpracują one z aplikacjami obsługującymi automatyczne tworzenie kopii zapasowych i tworzenie kopii zapasowych par klucz-wartość. Podczas fazy tworzenia aplikacji większość wewnętrznych mechanizmów platformy jest ukryta, więc nie musisz znać tych informacji. Jednak w fazie testów zrozumienie tych pojęć staje się ważniejsze.
Na diagramie poniżej widać, jak przepływają dane podczas tworzenia kopii zapasowej w chmurze i przywracania z niej. Do testowania można użyć tego samego urządzenia do tworzenia kopii zapasowej w chmurze i przywracania danych.
Ten diagram pokazuje przepływ danych podczas przesyłania danych z urządzenia na urządzenie:
W przeciwieństwie do testowania tworzenia i przywracania kopii zapasowych w chmurze testowanie D2D wymaga urządzenia źródłowego i docelowego, z którego i na które można kopiować dane.
Usługa Menedżera kopii zapasowych to usługa systemowa Androida, która koordynuje i inicjuje operacje tworzenia i przywracania kopii zapasowych. Usługa jest dostępna za pomocą interfejsu API Backup Manager.
Podczas operacji tworzenia kopii zapasowej usługa wysyła do aplikacji zapytanie o dane kopii zapasowej, a następnie przekazuje je do transportu kopii zapasowej, który archiwizuje dane w chmurze. Podczas operacji przywracania usługa Menedżer kopii zapasowych pobiera dane kopii zapasowej z transportu kopii zapasowej i przywraca je na urządzeniu. W przypadku przenoszenia danych z urządzenia na urządzenie usługa Menedżera kopii zapasowych wysyła do aplikacji zapytanie o dane kopii zapasowej i przekazuje je bezpośrednio do usługi Menedżera kopii zapasowych na nowym urządzeniu, która wczytuje je do aplikacji.
Usługi transportu kopii zapasowych to komponenty Androida, które odpowiadają za przechowywanie i pobieranie danych aplikacji. Urządzenie z Androidem może mieć 0 lub więcej transportów zapasowych, ale tylko jeden z nich może być oznaczony jako aktywny. Dostępne metody tworzenia kopii zapasowych różnią się w zależności od urządzenia ze względu na dostosowania wprowadzane przez producentów urządzeń i dostawców usług, ale większość urządzeń z Google Play jest dostarczana z tymi metodami:
- GMS Transport: aktywny transport kopii zapasowych w chmurze na większości urządzeń, będący częścią Usług mobilnych Google. Ten transport przechowuje dane w usłudze tworzenia kopii zapasowych Androida.
- D2D Transport: ten transport jest używany w migracji D2D do przenoszenia danych bezpośrednio z jednego urządzenia na drugie.
Narzędzia
Aby przetestować operacje tworzenia kopii zapasowej i przywracania danych, musisz poznać te narzędzia:
adb: do uruchamiania poleceń na urządzeniu lub emulatorze.bmgr: do wykonywania różnych operacji tworzenia i przywracania kopii zapasowych.logcat: aby wyświetlić wyniki operacji tworzenia i przywracania kopii zapasowych.
Testowanie kopii zapasowej w chmurze
Kopię zapasową w chmurze i przywracanie można wykonać na jednym urządzeniu, postępując zgodnie z instrukcjami w tej sekcji.
Przygotowywanie urządzenia lub emulatora do tworzenia kopii zapasowych w chmurze
Przygotuj urządzenie lub emulator do testowania kopii zapasowej, wykonując czynności z tej listy kontrolnej:
- W przypadku automatycznej kopii zapasowej sprawdź, czy używasz urządzenia lub emulatora z Androidem 6.0 (poziom interfejsu API 23) lub nowszym.
- W przypadku tworzenia kopii zapasowej par klucz-wartość sprawdź, czy używasz urządzenia lub emulatora z Androidem 2.2 (poziom interfejsu API 8) lub nowszym.
- Aby przetestować kopię zapasową w chmurze, musisz mieć dostęp do internetu.
- Zaloguj się na urządzeniu za pomocą konta Google i ustaw je jako konto kopii zapasowej w Ustawieniach –> Google –> Kopia zapasowa.
Aby przetestować kopię zapasową w chmurze, uruchom ją, a następnie odinstaluj i ponownie zainstaluj aplikację. Aby powtórzyć te czynności, możesz użyć tego skryptu:test_cloud_backup.sh, który tworzy kopię zapasową aplikacji, pobiera lokalnie plik APK, odinstalowuje go i ponownie instaluje.
#!/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"
Etapy testowania
- Otwórz aplikację, zaloguj się i zmień wszystkie ustawienia.
- Uruchom skrypt, podając nazwę pakietu, np.
test_cloud_backup.sh com.example.myapp - Ponownie otwórz aplikację i sprawdź, czy działa prawidłowo i czy wszystkie dane zostały zachowane.
Nie chcesz, aby użytkownicy musieli się logować, a wszystkie ich ustawienia, postępy i dane aplikacji muszą być takie jak wcześniej. Jeśli wyniki testu nie spełniają tych kryteriów, upewnij się, że kopie zapasowe są prawidłowo skonfigurowane i nie pominięto żadnych kluczowych danych. Sprawdź też, czy obsługujesz ponowne tworzenie danych z pamięci podręcznej, które zostały wykluczone z kopii zapasowej. Powtórz kroki 1–3 w przypadku każdej iteracji testu.
Testowanie przenoszenia danych z urządzenia na urządzenie
Najdokładniejszym sposobem przetestowania przesyłania danych z urządzenia na urządzenie jest przeniesienie całej zawartości telefonu na nowe urządzenie przywrócone do ustawień fabrycznych i sprawdzenie, czy działa ono prawidłowo. Jeśli jednak musisz powtórzyć ten proces wiele razy, może to być niewygodne i czasochłonne. Z tego przewodnika dowiesz się, jak przeprowadzić symulację przenoszenia danych na jedno urządzenie bez konieczności wielokrotnego przywracania na nim ustawień fabrycznych.
Przygotowywanie urządzenia do testowania D2D
Aby przetestować przesyłanie D2D na jednym urządzeniu, przygotuj je w ten sposób:
- Na urządzeniu musi być zainstalowany Android 12 (API na poziomie 31) lub nowszy.
- Aby przetestować najnowszą wersję D2D, kieruj aplikację na Androida 12 (API na poziomie 31) lub nowszego.
- Aby umożliwić powtarzanie testu, utwórz ten skrypt:
test_d2d.sh.
#!/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"
Etapy testowania
- Zainstaluj na urządzeniu aplikację, którą chcesz przetestować.
- Otwórz aplikację, zaloguj się i zmodyfikuj jej ustawienia.
- Uruchom skrypt na urządzeniu, podając nazwę pakietu, np.
test_d2d.sh com.example.myapp. - Po zakończeniu działania skryptu otwórz aplikację na urządzeniu i sprawdź, czy działa prawidłowo, a wszystkie dane zostały zachowane.
Nie chcesz, aby użytkownicy musieli się logować, a wszystkie ich ustawienia, postępy i dane aplikacji muszą wyglądać tak samo jak przed uruchomieniem skryptu. Jeśli wyniki testu nie spełniają tych kryteriów, sprawdź, czy konfiguracja przenoszenia jest prawidłowa i czy nie pominięto żadnych kluczowych danych. Upewnij się też, że obsługujesz ponowne tworzenie danych z pamięci podręcznej, które zostały wykluczone z przenoszenia. Powtórz kroki 2–4 dla każdej iteracji testu.
Rozwiązywanie problemów z tworzeniem i przywracaniem kopii zapasowej
W tej sekcji znajdziesz pomoc w rozwiązywaniu typowych problemów.
Przekroczono limit transportu
Te komunikaty w Logcat wskazują, że aplikacja przekroczyła limit transportu:
I/PFTBT: Transport rejected backup of <PACKAGE>, skipping
--- or ---
I/PFTBT: Transport quota exceeded for package: <PACKAGE>
Zmniejsz ilość danych kopii zapasowej i spróbuj ponownie. Sprawdź na przykład, czy dane są zapisywane w pamięci podręcznej tylko w katalogu pamięci podręcznej aplikacji. Katalog pamięci podręcznej nie jest uwzględniany w kopiach zapasowych.
Nie można utworzyć pełnej kopii zapasowej
Ten komunikat w Logcat wskazuje, że operacja pełnej kopii zapasowej nie powiodła się, ponieważ na urządzeniu nie przeprowadzono jeszcze operacji tworzenia kopii zapasowej par klucz-wartość:
I/BackupManagerService: Full backup not currently possible -- key/value backup
not yet run?
Uruchom kopię zapasową par klucz-wartość za pomocą polecenia bmgr run, a potem spróbuj ponownie.
Limit czasu oczekiwania na pracownika obsługi klienta
Ten komunikat w Logcat wskazuje, że uruchomienie aplikacji na potrzeby kopii zapasowej trwa dłużej niż 10 sekund:
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
Zwróć uwagę na różnicę sygnatur czasowych w danych wyjściowych logu. Ten błąd występuje zwykle wtedy, gdy aplikacja korzysta z konfiguracji multidex bez ProGuard.
Nie zainicjowane konto kopii zapasowej
Poniższe komunikaty w Logcat wskazują, że tworzenie kopii zapasowej zostało wstrzymane, ponieważ zestaw danych kopii zapasowej nie został zainicjowany:
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
Uruchom menedżera kopii zapasowych za pomocą polecenia adb shell bmgr run, a następnie spróbuj ponownie utworzyć kopię zapasową.
Metody aplikacji nie zostały wywołane
Ponieważ funkcja automatycznej kopii zapasowej uruchamia aplikację z klasą bazową Application, metody konfiguracji aplikacji mogą nie zostać wywołane. Automatyczna kopia zapasowa nie uruchamia też żadnych działań aplikacji, więc jeśli aplikacja wykonuje konfigurację w ramach działania, mogą pojawić się błędy. Więcej informacji znajdziesz w artykule Implementowanie klasy BackupAgent.
Z kolei tworzenie kopii zapasowej par klucz-wartość uruchamia aplikację z dowolną Applicationklasą podrzędną zadeklarowaną w pliku manifestu aplikacji.
Brak danych do utworzenia kopii zapasowej
Poniższe komunikaty w narzędziu Logcat wskazują, że aplikacja nie ma danych do utworzenia kopii zapasowej:
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.
Jeśli masz własną implementacjęBackupAgent, prawdopodobnie oznacza to, że nie dodano żadnych danych ani plików do kopii zapasowej.