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

На этой странице показано, как протестировать резервные копии в облаке и процесс передачи с устройства на устройство (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 Transport: этот транспорт используется при миграции 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 локально, удаляет его и переустанавливает 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

Обратите внимание на разницу временных меток в выводе журнала. Эта ошибка обычно возникает, когда ваше приложение использует мультидекс-конфигурацию без 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 , методы установки вашего приложения могут не вызываться. Автоматическое резервное копирование также не запускает никаких действий вашего приложения, поэтому вы можете увидеть ошибки, если ваше приложение выполняет настройку в действии. Дополнительные сведения см. в разделе «Реализация 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 , это, скорее всего, означает, что вы не добавили в резервную копию никаких данных или файлов.