Na tej stronie dowiesz się, jak w przypadku Twojej aplikacji testować kopie zapasowe w chmurze i proces przenoszenia danych między urządzeniami. Ważne jest, aby testować je w każdej głównej wersji aplikacji, aby mieć pewność, że użytkownicy mogą nadal jej używać na nowym urządzeniu. Chociaż funkcje tworzenia kopii zapasowej i przenoszenia są podobne, występują między nimi istotne różnice w przypadku Androida 12 (poziom interfejsu API 31) i wyższych. W szczególności chodzi o to, że podczas przenoszenia obowiązuje znacznie większy limit rozmiaru danych wynoszący 2 GB niż w przypadku kopii zapasowej w chmurze (25 MB).
Z tego przewodnika dowiesz się, jak skutecznie przetestować tworzenie i przywracanie kopii zapasowej w chmurze oraz przenoszenie danych D2D w całym cyklu programowania.
Jak działa testowanie kopii zapasowych
W tej sekcji opisujemy różne elementy struktury tworzenia kopii zapasowych Androida i opisujemy ich interakcje z aplikacjami, które obsługują Automatyczną kopię zapasową i kopię zapasową par klucz-wartość. Na etapie tworzenia aplikacji większość wewnętrznych elementów platformy jest odwrócona, więc nie musisz znać tych informacji. Jednak w fazie testowania ważniejsza staje się znajomość tych pojęć.
Poniższy diagram przedstawia przepływ danych podczas tworzenia i przywracania kopii zapasowej w chmurze. Do celów testowych możesz wykorzystać to samo urządzenie do tworzenia i przywracania kopii zapasowych w chmurze.
Poniższy diagram przedstawia przepływ danych podczas transferu D2D:
W przeciwieństwie do testowania tworzenia i przywracania kopii zapasowych w chmurze testy D2D wymagają urządzenia źródłowego i docelowego, z którego będą kopiować dane.
Usługa menedżera kopii zapasowych to usługa systemowa Androida, która administruje i inicjuje operacje tworzenia i przywracania kopii zapasowych. Usługa jest dostępna przez interfejs API Backup Manager.
Podczas wykonywania operacji tworzenia kopii zapasowej usługa wysyła do aplikacji zapytanie o dane kopii zapasowej, a następnie przekazuje ją do zapasowego transportu, który następnie archiwizuje dane w chmurze. Podczas operacji przywracania usługa menedżera kopii zapasowych pobiera dane kopii zapasowej z transportu zapasowego i przywraca je na urządzenie. W przypadku transferu D2D usługa Backup Manager 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 ją do aplikacji.
Pliki zapasowe to komponenty Androida, które odpowiadają za przechowywanie i pobieranie danych aplikacji. Urządzenie z Androidem może nie obsługiwać żadnych transferów zapasowych, ale tylko jeden z nich może być oznaczony jako aktywny. Dostępne dane zapasowe różnią się w zależności od urządzenia ze względu na ustawienia niestandardowe wprowadzone przez producentów urządzeń i dostawców usług, ale większość urządzeń z obsługą Google Play udostępnia te opcje przesyłania:
- GMS Transport: aktywne przesyłanie kopii zapasowych w chmurze na większości urządzeń, które wchodzą w skład Usług mobilnych Google. Ten transport przechowuje dane w usłudze Android Backup Service.
- Transport D2D: 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 i przywracania kopii zapasowych, musisz dowiedzieć się czegoś o następujących narzędziach.
adb: umożliwia uruchamianie poleceń na urządzeniu lub w emulatorze.bmgr: umożliwia wykonywanie różnych operacji tworzenia kopii zapasowych i przywracania danych.logcat: aby wyświetlić dane wyjściowe operacji tworzenia kopii zapasowych i przywracania.
Testowanie kopii zapasowej w chmurze
Wykonując czynności opisane w tej sekcji, można tworzyć i przywracać kopie zapasowe w chmurze na jednym urządzeniu.
Przygotowywanie urządzenia lub emulatora do tworzenia kopii zapasowych w chmurze
Przygotuj urządzenie lub emulator do testowania kopii zapasowej, korzystając 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 zapasowych 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 Ustawienia -> Google -> Kopia zapasowa.
Aby przetestować kopię zapasową w chmurze, aktywuj kopię zapasową w chmurze, a następnie odinstaluj i ponownie zainstaluj aplikację. Aby te czynności były powtarzalne, możesz użyć tego skryptu: test_cloud_backup.sh, który tworzy kopię zapasową aplikacji, pobiera lokalnie plik APK, odinstaluje 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 testu
- Otwórz aplikację, zaloguj się i zmodyfikuj wszystkie ustawienia.
- Uruchom skrypt, podając nazwę pakietu, np.
test_cloud_backup.sh com.example.myapp - Otwórz ponownie aplikację i sprawdź, czy działa prawidłowo, a wszystkie dane są zachowane.
Nie chcesz, aby użytkownicy musieli się logować, a wszystkie ich ustawienia, postępy i dane aplikacji muszą pozostawać bez zmian. Jeśli wyniki testu nie spełniają tych kryteriów, sprawdź, czy kopie zapasowe są skonfigurowane poprawnie, bez pomijania najważniejszych danych i że będziesz odtwarzać wszystkie dane z pamięci podręcznej, które zostały wykluczone z kopii zapasowej. Powtórz kroki 1–3 dla każdej iteracji testu.
Testowanie transferu D2D
Najprostszym sposobem przetestowania transferu D2D jest przeniesienie całej zawartości telefonu na nowe urządzenie, na którym przywrócono ustawienia fabryczne, i sprawdzenie, czy działa ono prawidłowo. Może to być jednak niewygodne i czasochłonne, jeśli trzeba będzie powtarzać ten proces wielokrotnie. Z tego artykułu dowiesz się, jak przeprowadzić symulację przenoszenia na jednym urządzeniu bez ciągłego przywracania ustawień fabrycznych.
Przygotuj urządzenie do testów D2D
Aby przetestować przenoszenie D2D na jednym urządzeniu, przygotuj je w ten sposób:
- Na urządzeniu musi być zainstalowany Android 12 (poziom interfejsu API 31) lub nowszy.
- Aby przetestować najnowszą wersję D2D, ustaw w aplikacji kierowanie na Androida 12 (poziom interfejsu API 31) lub nowszy.
- Utwórz następujący skrypt (
test_d2d.sh), aby umożliwić powtarzanie testu:
#!/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 testu
- 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. - Gdy skrypt będzie gotowy, otwórz aplikację na urządzeniu i sprawdź, czy działa prawidłowo. Wszystkie dane są zachowane.
Nie chcesz, aby użytkownicy musieli się logować, a wszystkie ich ustawienia, postępy i dane aplikacji muszą być wyświetlane w taki sam sposób jak przed uruchomieniem skryptu. Jeśli wyniki testu nie spełniają tych kryteriów, sprawdź, czy przesyłanie zostało prawidłowo skonfigurowane, bez pomijania kluczowych danych oraz że odtwarzasz z pamięci podręcznej dane, 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 zapasowych
Ta sekcja pomoże Ci rozwiązać niektóre typowe problemy.
Przekroczono limit transportu
Poniższe komunikaty w narzędziu Logcat wskazują, że aplikacja przekroczyła limit transportowy:
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 buforujesz dane 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
Komunikat w aplikacji Logcat oznacza, że operacja tworzenia pełnej kopii zapasowej nie powiodła się, ponieważ na urządzeniu nie została jeszcze wykonana żadna operacja tworzenia kopii zapasowej w postaci par klucz-wartość:
I/BackupManagerService: Full backup not currently possible -- key/value backup
not yet run?
Uruchom kopię zapasową pary klucz-wartość poleceniem bmgr run, a potem spróbuj jeszcze raz.
Upłynął limit czasu oczekiwania na agenta
Ten komunikat w narzędziu Logcat oznacza, że uruchomienie aplikacji zajmuje ponad 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ę w sygnaturach czasowych w danych wyjściowych logu. Ten błąd występuje zwykle wtedy, gdy aplikacja korzysta z konfiguracji multidex bez ProGuard.
Niezainicjowane konto kopii zapasowej
Poniższe komunikaty w narzędziu Logcat wskazują, że kopia zapasowa została wstrzymana, ponieważ zapasowy zbiór danych 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 wykonać kopię zapasową.
Niewywołane metody aplikacji
Automatyczna kopia zapasowa uruchamia Twoją aplikację z klasą podstawową Application, dlatego metody konfiguracji aplikacji mogą nie być wywoływane. Automatyczna kopia zapasowa nie uruchamia też żadnych aktywności w aplikacji, więc jeśli aplikacja przeprowadza konfigurację aktywności, możesz zobaczyć błędy. Więcej informacji znajdziesz w artykule o implementowaniu agenta kopii zapasowej.
Natomiast kopia zapasowa par klucz-wartość uruchamia aplikację z dowolną podklasą Application zadeklarowaną w pliku manifestu aplikacji.
Brak danych do utworzenia kopii zapasowej
Następujące komunikaty w usłudze Logcat wskazują, że aplikacja nie ma danych, których kopię zapasową można utworzyć:
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 wdrożysz własną metodę BackupAgent, prawdopodobnie oznacza to, że do kopii zapasowej nie zostały dodane żadne dane ani pliki.