Na tej stronie dowiesz się, jak przetestować tworzenie kopii zapasowych aplikacji w chmurze i proces przenoszenia aplikacji z urządzenia na urządzenie. Ważne jest, by przetestować obie te metody w każdej głównej wersji aplikacji, by użytkownicy mogli nadal z niej korzystać na nowym urządzeniu. Chociaż tworzenie kopii zapasowych i przenoszenie danych są podobne, w Androidzie 12 (poziom interfejsu API 31) i nowszych występują między nimi ważne różnice. Najważniejsze jest to, że transfer ma znacznie większy limit rozmiaru danych (2 GB) niż tworzenie kopii zapasowej w chmurze (25 MB).
Z tego przewodnika dowiesz się, jak skutecznie testować kopiowanie zapasowe i przywracanie w chmurze oraz przesyłanie D2D w całym cyklu programowania.
Jak działa testowanie kopii zapasowych
W tej sekcji opisano różne elementy systemu kopii zapasowej Androida oraz ich interakcje z aplikacjami, które obsługują automatyczną kopię zapasową i kopię zapasową par klucz-wartość. Podczas fazy tworzenia aplikacji większość wewnętrznych elementów frameworku jest zaciemniona, więc nie musisz znać tych informacji. Jednak na etapie testów ważniejsza staje się znajomość tych koncepcji.
Na diagramie poniżej widać, jak dane przepływają podczas tworzenia kopii zapasowej w chmurze i przywracania danych. Do celów testowych to samo urządzenie może służyć do tworzenia i przywracania kopii zapasowej w chmurze.
Poniższy diagram przedstawia przepływ danych podczas przenoszenia D2D:
W przeciwieństwie do testowania kopii zapasowej i przywracania w chmurze testowanie kopiowania z urządzenia na urządzenie wymaga urządzenia źródłowego i docelowego, z którego i na które mają być kopiowane dane.
Usługa Menedżer kopii zapasowych to usługa systemowa Androida, która administruje oraz 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 Twojej aplikacji zapytanie o dane kopii zapasowej, a potem przekazuje je do transportu kopii zapasowej, który archiwizuje dane w chmurze. Podczas operacji przywracania usługa Backup Manager Service pobiera dane kopii zapasowej z transportu kopii zapasowej i przywraca je na urządzenie. W przypadku przenoszenia D2D usługa menedżera kopii zapasowych wysyła do aplikacji zapytanie o dane z kopii zapasowej i przekazuje je bezpośrednio do usługi menedżera kopii zapasowych na nowym urządzeniu, która wczytuje je do aplikacji.
Transporty zapasowe to komponenty Androida, które odpowiadają za przechowywanie i pobieranie danych aplikacji. Urządzenie z Androidem może mieć 0 lub więcej kopii zapasowych, ale tylko jedna z nich może być oznaczona jako aktywna. Ze względu na specyfikę u producentów urządzeń i dostawców usług, dostępne dane przesyłania kopii zapasowych różnią się w zależności od urządzenia. Jednak większość urządzeń z Google Play udostępnia te elementy:
- Transport GMS: aktywny transport kopii zapasowej w chmurze na większości urządzeń, część Usług mobilnych Google. Ta usługa transportu przechowuje dane w usłudze Android Backup Service.
- Transport D2D: ten transport jest używany podczas migracji D2D do przenoszenia danych bezpośrednio z jednego urządzenia na drugie.
Narzędzia
Aby przetestować operacje tworzenia kopii zapasowej i przywracania, musisz wiedzieć coś o tych narzędziach.
adb: do uruchamiania poleceń na urządzeniu lub w emulatorze.bmgr: do wykonywania różnych operacji tworzenia kopii zapasowych i przywracania danych.logcat: aby wyświetlić dane wyjściowe operacji tworzenia kopii zapasowej i przywracania.
Testowanie kopii zapasowej w chmurze
Kopie zapasowe w chmurze i przywracanie można wykonać na jednym urządzeniu, wykonując czynności opisane w tej sekcji.
Przygotowanie urządzenia lub emulatora do tworzenia kopii zapasowych w chmurze
Przygotuj urządzenie lub emulator do testowania kopii zapasowych, wykonując czynności z poniższej listy kontrolnej:
- W przypadku automatycznego tworzenia kopii zapasowych sprawdź, czy używasz urządzenia lub emulatora z Androidem 6.0 (poziom interfejsu API 23) lub nowszym.
- Aby utworzyć kopię zapasową 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 na konto Google i ustaw je jako konto zapasowe w sekcji Ustawienia -> Google -> Kopia zapasowa.
Aby przetestować tworzenie kopii zapasowej w chmurze, aktywuj kopię zapasową w chmurze, a następnie odinstaluj i ponownie zainstaluj aplikację. Aby te czynności były powtarzalne, możesz skorzystać z 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"
Kroki testowania
- Otwórz aplikację, zaloguj się i zmodyfikuj 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 są zachowane.
Nie chcesz, aby użytkownicy musieli się logować, a wszystkie ich ustawienia, postępy i dane aplikacji muszą być takie same jak wcześniej. Jeśli wyniki testu nie spełniają tych kryteriów, sprawdź, czy kopie zapasowe są prawidłowo skonfigurowane, bez pominięcia kluczowych danych, oraz czy uwzględniasz odtworzenie 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.
Test przesyłania D2D
Najlepszym sposobem na przetestowanie przesyłania D2D jest przeniesienie wszystkich danych z telefonu na nowe urządzenie z przywróconymi ustawieniami fabrycznymi i sprawdzenie, czy wszystko działa prawidłowo. Może to jednak być niewygodne i czasochłonne, jeśli trzeba powtórzyć proces wiele razy. Z tych instrukcji dowiesz się, jak symulować przeniesienie na jednym urządzeniu bez wielokrotnego przywracania ustawień fabrycznych.
Przygotowanie 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 (poziom API 31) lub nowszego.
- Aby powtórzyć test, utwórz 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"
Kroki testowania
- Zainstaluj na urządzeniu aplikację, którą chcesz przetestować.
- Otwórz aplikację, zaloguj się i zmień jej ustawienia.
- Uruchom skrypt na urządzeniu, przekazując nazwę pakietu, np.
test_d2d.sh com.example.myapp. - Gdy skrypt się zakończy, otwórz aplikację na urządzeniu i sprawdź, czy działa prawidłowo i czy wszystkie dane zostały zachowane.
Nie chcesz, aby użytkownicy musieli się logować. Wszystkie ich ustawienia, postępy i dane aplikacji muszą być takie same jak przed uruchomieniem skryptu. Jeśli wyniki testu nie spełniają tych kryteriów, sprawdź, czy transfer został prawidłowo skonfigurowany, czy nie pominięto kluczowych elementów danych, a także czy dane w pamięci podręcznej, które zostały wykluczone z transferu, są ponownie tworzone. Powtórz kroki 2–4 w przypadku każdej iteracji testu.
Rozwiązywanie problemów z tworzeniem i przywracaniem kopii zapasowych
Ta sekcja zawiera informacje pomocne 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ą przechowywane 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łnego tworzenia kopii zapasowej zakończyła się niepowodzeniem, ponieważ na urządzeniu nie została jeszcze wykonana operacja tworzenia kopii zapasowej klucza i wartości:
I/BackupManagerService: Full backup not currently possible -- key/value backup
not yet run?
Utwórz kopię zapasową par klucz-wartość poleceniem bmgr run i spróbuj jeszcze raz.
Limit czasu oczekiwania na połączenie z obsługą klienta
Ten komunikat w Logcat oznacza, że uruchomienie aplikacji w celu utworzenia kopii zapasowej trwa 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ę sygnatury czasowej w danych wyjściowych logu. Ten błąd występuje zwykle, gdy aplikacja korzysta z konfiguracji multidex bez ProGuarda.
Nieinicjalizowane konto zapasowe
Te komunikaty w Logcat wskazują, że tworzenie kopii zapasowej zostało wstrzymane, ponieważ nie udało się zainicjować zbioru danych kopii zapasowej:
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ą.
Nie wywoływane metody aplikacji
Ponieważ automatyczna kopia zapasowa uruchamia aplikację za pomocą klasy podstawowej Application, metody konfiguracji aplikacji mogą nie zostać wywołane. Automatyczna kopia zapasowa nie uruchamia żadnych działań aplikacji, więc jeśli aplikacja przeprowadzi konfigurację w ramach działania, mogą pojawić się błędy. Więcej informacji znajdziesz w artykule Wdrażanie BackupAgent.
Natomiast kopia zapasowa par klucz-wartość uruchamia aplikację z dowolną podklasą Applicationdeklarowaną w pliku manifestu aplikacji.
Brak danych do tworzenia kopii zapasowej
Te komunikaty w 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 wdrożyłeś/wdrożyłaś własną kopię zapasowąBackupAgent, prawdopodobnie nie dodano do niej żadnych danych ani plików.