Na tej stronie znajdziesz informacje o testowaniu kopii zapasowych w chmurze i procesu przesyłania danych z urządzenia na urządzenie w aplikacji. Ważne jest, aby testować oba te procesy przy każdej dużej aktualizacji aplikacji, aby zapewnić użytkownikom możliwość dalszego korzystania z aplikacji 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. W fazie testowania znajomość tych pojęć staje się jednak bardziej istotna.
Na diagramie poniżej widać, jak dane przepływają podczas tworzenia kopii zapasowej w chmurze i przywracania danych. Do celów testowych można użyć tego samego urządzenia do tworzenia kopii zapasowej w chmurze i przywracania z niej danych.
Ten diagram pokazuje, jak dane przepływają podczas przesyłania 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żera kopii zapasowej to usługa systemu Androida, która inicjuje i koordynuję 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 menedżera kopii zapasowych pobiera dane kopii zapasowej z transportu kopii zapasowej i przywraca je na urządzenie. W przypadku transferu D2D usługa menedżera kopii zapasowej wysyła zapytanie do Twojej aplikacji o dane kopii zapasowej i przekazuje je bezpośrednio do usługi menedżera kopii zapasowej na nowym urządzeniu, która wczyta je w aplikacji.
Transporty kopii zapasowych to komponenty Androida odpowiedzialne 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. Dostępne metody tworzenia kopii zapasowych różnią się w zależności od urządzenia ze względu na ich dostosowanie przez producentów i dostawców usług, ale większość urządzeń z Google Play obsługuje te metody:
- 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.
- D2D Transport: ten transport jest używany w ramach migracji D2D do przesyłania danych bezpośrednio z jednego urządzenia na drugie.
Narzędzia
Aby przetestować operacje tworzenia i przywracania kopii zapasowych, musisz znać poniższe narzędzia.
adb: do uruchamiania poleceń na urządzeniu lub w emulatorze.bmgr: do wykonywania różnych operacji tworzenia kopii zapasowych i przywracania.logcat: aby wyświetlić dane wyjściowe operacji tworzenia kopii zapasowej i przywracania.
Testowanie kopii zapasowej w chmurze
Tworzenie i przywracanie kopii zapasowych w chmurze 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 zapasowej, wykonując czynności z tej 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ć tworzenie kopii zapasowej w chmurze, musisz mieć dostęp do internetu.
- Zaloguj się na urządzeniu za pomocą konta Google i ustaw je jako konto kopii zapasowej, klikając Ustawienia -> Google -> Kopia zapasowa.
Aby przetestować kopię zapasową w chmurze, uruchom kopię zapasową w chmurze, a następnie odinstaluj i ponownie zainstaluj aplikację. Aby te czynności były powtarzalne, możesz użyć tego skryptutest_cloud_backup.sh, który tworzy kopię zapasową aplikacji, pobiera plik APK lokalnie, odinstalowuje go i ponownie go 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 - 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ć. Wszystkie ich ustawienia, postępy i dane w 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 (poziom interfejsu API 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"
Etapy testu
- 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ć, a wszystkie ich ustawienia, dane o postępach i dane aplikacji muszą być wyświetlane tak samo jak przed uruchomieniem skryptu. Jeśli wyniki testu nie spełniają tych kryteriów, upewnij się, że przesyłanie danych zostało prawidłowo skonfigurowane, nie pomijając kluczowych elementów, oraz że odtwarzasz również wszystkie dane przechowywane w pamięci podręcznej, które zostały wykluczone z transferu. Powtórz kroki 2–4 w przypadku każdej iteracji testu.
Rozwiązywanie problemów z kopiami zapasowymi i przywracaniem
Ta sekcja pomoże Ci rozwiązać niektóre typowe problemy.
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 narzędziu Logcat oznacza, że operacja pełnej kopii zapasowej nie powiodła się, ponieważ na urządzeniu nie została jeszcze utworzona żadna operacja tworzenia kopii zapasowej pary klucz-wartość:
I/BackupManagerService: Full backup not currently possible -- key/value backup
not yet run?
Utwórz kopię zapasową par klucz-wartość za pomocą polecenia bmgr run, a potem spróbuj ponownie.
Oczekiwanie na odpowiedź pracownika obsługi 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ę w sygnaturze czasowej w danych wyjściowych logu. Ten błąd występuje zwykle, gdy aplikacja korzysta z konfiguracji multidex bez ProGuarda.
Niezainicjowane konto kopii zapasowej
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 narzędziu Logcat wskazują, że aplikacja nie ma danych, których można utworzyć kopię zapasową:
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.