Cómo probar copias de seguridad y restablecimiento

En esta página, se muestra cómo probar las copias de seguridad en la nube y el proceso de transferencia de dispositivo a dispositivo (D2D) para tu app. Es importante que pruebes ambos con cada versión principal de tu app para asegurarte de que los usuarios puedan seguir usándola en un dispositivo nuevo. Si bien la copia de seguridad y la transferencia son similares, existen diferencias importantes entre ambas en Android 12 (nivel de API 31) y versiones posteriores. En particular, esa transferencia tiene un límite de tamaño de datos mucho mayor de 2 GB en comparación con las copias de seguridad en la nube de 25 MB.

En esta guía, se muestra cómo puedes probar el restablecimiento y la copia de seguridad en la nube y la transferencia D2D de manera eficiente durante todo el ciclo de desarrollo.

Cómo funcionan las pruebas de copias de seguridad

En esta sección, se describen varias partes del framework de copia de seguridad de Android y cómo interactúan con las apps que admiten la copia de seguridad automática y la copia de seguridad de clave-valor. Durante la fase de desarrollo de la app, se abstrae la mayor parte del trabajo interno del framework, por lo que no es necesario que conozcas esta información. Sin embargo, durante la fase de prueba, es más importante comprender estos conceptos.

En el siguiente diagrama, se ilustra cómo fluyen los datos durante la copia de seguridad y el restablecimiento en la nube. Para realizar pruebas, se puede usar el mismo dispositivo para el restablecimiento y las copias de seguridad en la nube.

Flujo de datos del framework de copia de seguridad

En el siguiente diagrama, se muestra cómo fluyen los datos durante una transferencia D2D:

Flujo de datos del framework de transferencia

A diferencia de las pruebas de copia de seguridad y restablecimiento en la nube, las pruebas D2D requieren un dispositivo de origen y un dispositivo de destino para copiar desde y hacia.

El servicio del administrador de copias de seguridad es un servicio del sistema Android que organiza e inicia las operaciones de copia de seguridad y restablecimiento. Se puede acceder al servicio a través de la API de Backup Manager.

Durante una operación de copia de seguridad, el servicio busca datos de copia de seguridad en tu app y, luego, se los pasa al transporte alternativo, que luego archiva los datos en la nube. Durante una operación de restablecimiento, el servicio del administrador de copias de seguridad recupera los datos de copia de seguridad del transporte alternativo y restablece los datos en el dispositivo. Para una transferencia D2D, el servicio del administrador de copias de seguridad busca datos de copia de seguridad en tu app y los pasa directamente al servicio del administrador de copias de seguridad en el dispositivo nuevo, que los carga en tu app.

Los transportes alternativos son componentes de Android responsables de almacenar y recuperar los datos de tu app. Un dispositivo con Android puede tener cero o más transportes de copia de seguridad, pero solo uno de esos transportes se puede marcar como activo. Los transportes alternativos disponibles difieren de un dispositivo a otro debido a las personalizaciones que realizan los fabricantes de dispositivos y los proveedores de servicios, pero la mayoría de los dispositivos compatibles con Google Play se envían con los siguientes transportes:

  • Transporte de GMS: Es el transporte alternativo activo en la nube para la mayoría de los dispositivos y parte de Servicios de Google para dispositivos móviles. Este transporte almacena datos en Android Backup Service.
  • Transporte D2D: Este transporte se usa en la migración D2D para transferir datos directamente de un dispositivo a otro.

Herramientas

Para probar tus operaciones de copia de seguridad y restablecimiento, necesitas algo de información sobre las siguientes herramientas.

  • adb: Se usa para ejecutar comandos en el dispositivo o el emulador.
  • bmgr: Se usa para realizar varias operaciones de copia de seguridad y restablecimiento.
  • logcat: Para ver el resultado de las operaciones de copia de seguridad y restablecimiento.

Probar la copia de seguridad en la nube

Para realizar la copia de seguridad y el restablecimiento en la nube con un solo dispositivo, sigue los pasos que se indican en esta sección.

Prepara tu dispositivo o emulador para las copias de seguridad en la nube

Prepara tu dispositivo o emulador para las pruebas de copia de seguridad mediante la siguiente lista de tareas:

  1. Para la copia de seguridad automática, comprueba que estés usando un dispositivo o emulador que ejecute Android 6.0 (nivel de API 23) o versiones posteriores.
  2. Para crear una copia de seguridad de los pares clave-valor, comprueba que estés usando un dispositivo o emulador que ejecute Android 2.2 (nivel de API 8) o versiones posteriores.
  3. Debes tener acceso a Internet para probar las copias de seguridad en la nube.
  4. Accede al dispositivo con una Cuenta de Google y configúrala como la cuenta para la copia de seguridad en Configuración -> Google -> Copia de seguridad.

Para probar la copia de seguridad en la nube, activa una copia de seguridad en la nube y, luego, desinstala y vuelve a instalar la app. Para que estos pasos se puedan repetir, puedes usar la siguiente secuencia de comandos, test_cloud_backup.sh, que crea una copia de seguridad de tu app, descarga el APK de forma local, lo desinstala y reinstala el 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"

Pasos de la prueba

  1. Abre la app, accede y modifica todos los parámetros de configuración.
  2. Ejecuta la secuencia de comandos y pasa el nombre de tu paquete, como test_cloud_backup.sh com.example.myapp.
  3. Vuelve a abrir la app y valida que funcione correctamente y que se conserven todos los datos.

No quieres que los usuarios deban acceder a una cuenta; además, la configuración, el progreso y los datos de app deben estar como antes. Si los resultados de tu prueba no cumplen con estos criterios, asegúrate de haber configurado las copias de seguridad de forma correcta, sin omitir datos clave, y de controlar la recreación de los datos almacenados en caché que excluiste de la copia de seguridad. Repite los pasos 1 a 3 para cada iteración de prueba.

Probar transferencia D2D

La forma más completa de probar la transferencia D2D es transferir todo el contenido del teléfono a un dispositivo nuevo que tenga restablecido la configuración de fábrica y validar que funcione correctamente. Sin embargo, esto puede ser inconveniente y demandar mucho tiempo si necesitas repetir el proceso varias veces. En estos pasos, se muestra cómo simular una transferencia con un solo dispositivo sin realizar un restablecimiento de la configuración de fábrica en el dispositivo de forma reiterada.

Prepara tu dispositivo para la prueba D2D

Para probar la transferencia D2D en un solo dispositivo, prepárala de la siguiente manera:

  1. Tu dispositivo debe ejecutar Android 12 (nivel de API 31) o una versión posterior.
  2. Para probar la versión más reciente de D2D, oriéntate a Android 12 (nivel de API 31) o una versión posterior en tu app.
  3. Crea la siguiente secuencia de comandos, test_d2d.sh, para admitir la repetición de la prueba:
#!/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"

Pasos de la prueba

  1. Instala la app que quieras probar en el dispositivo.
  2. Abre la app, accede y modifica su configuración.
  3. Ejecuta la secuencia de comandos en tu dispositivo y pasa el nombre de tu paquete, como test_d2d.sh com.example.myapp.
  4. Cuando se complete la secuencia de comandos, abre la app en el dispositivo y valida que funcione correctamente y que se retengan todos los datos.

No quieres que los usuarios deban acceder a sus cuentas, y todos los datos de configuración, progreso y app deben aparecer como lo hacían antes de ejecutar la secuencia de comandos. Si los resultados de tu prueba no cumplen con estos criterios, asegúrate de haber configurado la transferencia de forma correcta, sin omitir datos clave, y de estar controlando la recreación de los datos almacenados en caché que excluiste de la transferencia. Repite los pasos 2 a 4 para cada iteración de prueba.

Soluciona problemas relacionados con las copias de seguridad y el restablecimiento

En esta sección, encontrarás ayuda para solucionar algunos problemas habituales.

Se superó la cuota de transporte

Los siguientes mensajes en Logcat indican que tu app excedió la cuota de transporte:

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

--- or ---

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

Reduce la cantidad de datos de copia de seguridad y vuelve a intentarlo. Por ejemplo, verifica que estés almacenando datos solo en el directorio de caché de tu app. El directorio de caché no está incluido en las copias de seguridad.

No es posible crear una copia de seguridad completa

El siguiente mensaje de Logcat indica que la operación de copia de seguridad completa falló porque aún no se realizó ninguna operación de copia de seguridad de clave-valor en el dispositivo:

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

Activa una copia de seguridad de pares clave-valor con el comando bmgr run y vuelve a intentarlo.

Se agotó el tiempo de espera del agente

El siguiente mensaje de Logcat indica que tu app tarda más de 10 segundos en iniciar la copia de seguridad:

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

Observa la diferencia de marca de tiempo en el resultado del registro. Por lo general, este error ocurre cuando tu app usa una configuración multidex sin ProGuard.

La cuenta de copia de seguridad no inicializa

Los siguientes mensajes en Logcat indican que la copia de seguridad se detuvo porque no se inicializó el conjunto de datos de la copia de seguridad:

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

Ejecuta el administrador de copias de seguridad con el comando adb shell bmgr run y, luego, intenta realizar la copia de seguridad nuevamente.

No se llama a los métodos de la app

Debido a que la copia de seguridad automática inicia tu app con una clase base de Application, es posible que no se llame a los métodos de configuración de tu app. Además, la copia de seguridad automática no inicia ninguna de las actividades de tu app, por lo que es posible que veas errores si tu app se configura para una actividad. Para obtener más información, consulta Cómo implementar BackupAgent.

Por el contrario, la copia de seguridad de clave-valor inicia tu app con cualquier subclase Application que declares en el archivo de manifiesto de la app.

No hay datos para crear una copia de seguridad

Los siguientes mensajes en Logcat indican que tu app no tiene datos para crear una copia de seguridad:

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.

Si implementaste tu propio BackupAgent, es probable que no hayas agregado ningún dato ni archivo a la copia de seguridad.