Тестовое резервное копирование и восстановление

На этой странице показано, как протестировать резервное копирование в облаке и процесс переноса данных с устройства на устройство (D2D) для вашего приложения. Важно тестировать оба процесса с каждым основным релизом вашего приложения, чтобы гарантировать, что пользователи смогут продолжать использовать его на новом устройстве. Хотя резервное копирование и перенос данных схожи, между ними есть важные различия в Android 12 (уровень API 31) и выше — в частности, ограничение на размер данных при переносе данных в облаке значительно больше: 2 ГБ по сравнению с 25 МБ для облачного резервного копирования.

В этом руководстве показано, как можно эффективно тестировать резервное копирование и восстановление в облаке, а также передачу D2D на протяжении всего цикла разработки.

Как работает тестирование резервных копий

В этом разделе описываются различные компоненты фреймворка резервного копирования Android и их взаимодействие с приложениями, поддерживающими автоматическое резервное копирование и резервное копирование по ключам и значениям. На этапе разработки приложения большая часть внутренней работы фреймворка абстрагируется, поэтому вам не нужно знать эту информацию. Однако на этапе тестирования понимание этих концепций становится ещё важнее.

На следующей диаграмме показан поток данных во время резервного копирования и восстановления в облаке. Для тестирования можно использовать одно и то же устройство для резервного копирования и восстановления в облаке.

Поток данных фреймворка резервного копирования

На следующей диаграмме показано, как данные перемещаются во время передачи D2D:

Поток данных структуры передачи

В отличие от тестирования резервного копирования и восстановления в облаке, для тестирования D2D требуется исходное устройство и целевое устройство, с которых и на которые выполняется копирование.

Служба диспетчера резервного копирования — это системная служба Android, которая организует и инициирует операции резервного копирования и восстановления. Доступ к службе осуществляется через API Backup Manager .

Во время операции резервного копирования служба запрашивает данные резервной копии из вашего приложения, а затем передаёт их в службу резервного копирования , которая архивирует данные в облаке. Во время операции восстановления служба диспетчера резервного копирования извлекает данные резервной копии из службы резервного копирования и восстанавливает их на устройстве. При передаче данных D2D служба диспетчера резервного копирования запрашивает данные резервной копии из вашего приложения и передаёт их непосредственно службе диспетчера резервного копирования на новом устройстве, которая загружает их в ваше приложение.

Резервные транспорты — это компоненты Android, отвечающие за хранение и извлечение данных вашего приложения. Устройство на базе Android может иметь от нуля до нескольких резервных транспортов, но только один из них может быть помечен как активный. Доступные резервные транспорты различаются в зависимости от устройства из-за настроек, настраиваемых производителями устройств и поставщиками услуг, но большинство устройств с поддержкой Google Play поставляются со следующими транспортами:

  • GMS Transport: активный облачный транспорт резервного копирования на большинстве устройств, входящий в состав Google Mobile Services . Этот транспорт хранит данные в службе резервного копирования Android.
  • Транспорт D2D: этот транспорт используется при миграции D2D для передачи данных напрямую с одного устройства на другое.

Инструменты

Чтобы протестировать операции резервного копирования и восстановления, вам необходимо немного узнать о следующих инструментах.

  • adb : для запуска команд на устройстве или эмуляторе.
  • bmgr : для выполнения различных операций резервного копирования и восстановления.
  • logcat : для просмотра результатов операций резервного копирования и восстановления.

Тестовое резервное копирование в облаке

Резервное копирование и восстановление в облаке можно выполнить с помощью одного устройства, выполнив действия, описанные в этом разделе.

Подготовьте свое устройство или эмулятор для облачного резервного копирования

Подготовьте свое устройство или эмулятор к тестированию резервного копирования, выполнив следующий контрольный список:

  1. Для автоматического резервного копирования убедитесь, что вы используете устройство или эмулятор под управлением Android 6.0 (уровень API 23) или выше.
  2. Для резервного копирования пары «ключ-значение» убедитесь, что вы используете устройство или эмулятор под управлением Android 2.2 (уровень API 8) или выше.
  3. Для тестирования резервного копирования в облаке вам потребуется доступ к Интернету.
  4. Войдите в устройство, используя учетную запись Google, и установите ее в качестве резервной учетной записи в разделе Настройки -> Google -> Резервное копирование .

Чтобы протестировать резервное копирование в облаке, запустите его, а затем удалите и переустановите приложение. Чтобы эти шаги можно было повторять, используйте следующий скрипт test_cloud_backup.sh , который создаст резервную копию приложения, загрузит APK-файл локально, удалит его и переустановит:

#!/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"

Тестовые шаги

  1. Откройте приложение, войдите в систему и измените все настройки.
  2. Запустите скрипт, передав ему имя вашего пакета, например test_cloud_backup.sh com.example.myapp
  3. Откройте приложение еще раз и убедитесь, что оно работает правильно и все данные сохранены.

Вам не нужно, чтобы ваши пользователи входили в систему, а все их настройки, прогресс и данные приложения должны быть такими же, как и раньше. Если результаты вашего теста не соответствуют этим критериям, убедитесь, что вы правильно настроили резервное копирование, не пропуская ключевые фрагменты данных, и что вы также обрабатываете все кэшированные данные, которые вы исключили из резервной копии. Повторяйте шаги 1–3 для каждой итерации теста.

Тестовая передача D2D

Самый полный способ протестировать D2D-перенос — это перенести все содержимое телефона на новое устройство, сброшенное до заводских настроек, и проверить его корректность. Однако это может быть неудобно и долго, если вам приходится повторять процесс несколько раз. Эти шаги покажут, как смоделировать перенос данных на одном устройстве, не выполняя повторный сброс настроек до заводских.

Подготовьте свое устройство к тестированию D2D

Чтобы протестировать передачу D2D на одном устройстве, подготовьте его следующим образом:

  1. Ваше устройство должно работать под управлением Android 12 (уровень API 31) или выше.
  2. Чтобы протестировать последнюю версию D2D, используйте в своем приложении Android 12 (уровень API 31) или выше.
  3. Создайте следующий скрипт 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"

Тестовые шаги

  1. Установите на устройство приложение, которое вы хотите протестировать.
  2. Откройте приложение, войдите в систему и измените настройки приложения.
  3. Запустите скрипт на своем устройстве, указав имя своего пакета, например, test_d2d.sh com.example.myapp .
  4. После завершения скрипта откройте приложение на устройстве и убедитесь, что оно работает правильно, а все данные сохранены.

Вам не нужно, чтобы ваши пользователи входили в систему, а все их настройки, прогресс и данные приложения должны отображаться в том же виде, что и до запуска скрипта. Если результаты теста не соответствуют этим критериям, убедитесь, что вы правильно настроили перенос, не пропуская ключевые фрагменты данных, и что вы также обрабатываете все кэшированные данные, которые вы исключили из переноса. Повторяйте шаги 2–4 для каждой итерации теста.

Устранение неполадок при резервном копировании и восстановлении

Этот раздел поможет вам устранить некоторые распространенные проблемы.

Превышена транспортная квота

Следующие сообщения в Logcat указывают на то, что ваше приложение превысило транспортную квоту:

I/PFTBT: Transport rejected backup of <PACKAGE>, skipping

--- or ---

I/PFTBT: Transport quota exceeded for package: <PACKAGE>

Уменьшите объём данных резервного копирования и повторите попытку. Например, убедитесь, что данные кэшируются только в каталоге кэша вашего приложения. Каталог кэша не включается в резервные копии.

Полное резервное копирование невозможно

Следующее сообщение в Logcat указывает на то, что операция полного резервного копирования не удалась, поскольку на устройстве еще не выполнялась операция резервного копирования пары «ключ-значение»:

I/BackupManagerService: Full backup not currently possible -- key/value backup
not yet run?

Запустите резервное копирование пары «ключ-значение» с помощью команды bmgr run и повторите попытку.

Тайм-аут ожидания агента

Следующее сообщение в Logcat указывает на то, что запуск вашего приложения для резервного копирования занимает более 10 секунд:

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

Обратите внимание на разницу во времени в выводе журнала. Эта ошибка обычно возникает, когда ваше приложение использует конфигурацию multidex без ProGuard.

Неинициализированная резервная учетная запись

Следующие сообщения в Logcat указывают на то, что резервное копирование было остановлено, поскольку набор данных резервной копии не был инициализирован:

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

Запустите менеджер резервного копирования с помощью команды adb shell bmgr run , а затем попробуйте выполнить резервное копирование еще раз.

Методы приложения не вызываются

Поскольку Auto Backup запускает ваше приложение с базовым классом Application , методы настройки вашего приложения могут не вызываться. Auto Backup также не запускает никакие активности вашего приложения, поэтому вы можете столкнуться с ошибками, если ваше приложение запускается в активности. Подробнее см. в статье «Реализация BackupAgent » .

Напротив, резервное копирование «ключ-значение» запускает ваше приложение с любым подклассом Application , который вы объявляете в файле манифеста вашего приложения.

Нет данных для резервного копирования

Следующие сообщения в Logcat указывают на то, что в вашем приложении нет данных для резервного копирования:

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.

Если вы реализовали собственный BackupAgent , это, скорее всего, означает, что вы не добавили никаких данных или файлов в резервную копию.