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 probar ambas con cada versión principal de tu app para garantizar 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, que la transferencia tiene un límite de tamaño de datos mucho mayor de 2 GB, en comparación con los 25 MB de la copia de seguridad en la nube.

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

Cómo funcionan las pruebas de copias de seguridad

En esta sección, se describen varias piezas 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 pares clave-valor. Durante la fase de desarrollo de la app, la mayor parte del trabajo interno del framework se abstrae, por lo que no es necesario que conozcas esta información. Sin embargo, durante la fase de prueba, es 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. Con fines de prueba, se puede usar el mismo dispositivo para crear copias de seguridad y restablecer datos en la nube.

Flujo de datos del framework de copia de seguridad

En el siguiente diagrama, se ilustra 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 desde el que copiar y al que copiar.

El servicio del administrador de copias de seguridad es un sistema de servicios de 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 activa los datos. 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 del dispositivo. Para una transferencia de D2D, el servicio de administrador de copias de seguridad busca datos de copia de seguridad en tu app y los pasa directamente al servicio de administrador de copias de seguridad en el dispositivo nuevo, que lo 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 alternativos, 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 de los fabricantes de dispositivos y proveedores de servicios, pero la mayoría de los dispositivos habilitados para Google Play se envían con los siguientes transportes:

  • Transporte de GMS: Es el transporte alternativo activo de copia de seguridad en la nube en 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 utiliza en la migración de 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 copias de seguridad y restablecimientos en la nube, sigue los pasos que se indican en esta sección con un solo dispositivo.

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 con la siguiente lista de tareas:

  1. Para la copia de seguridad automática, comprueba que estés usando un dispositivo o emulador con Android 6.0 (nivel de API 23) o versiones posteriores.
  2. Para la copia de seguridad de clave-valor, comprueba que estés usando un dispositivo o emulador con Android 2.2 (nivel de API 8) o una versión posterior.
  3. Debes tener acceso a Internet para probar la copia de seguridad en la nube.
  4. Accede al dispositivo con una Cuenta de Google y configúrala como la cuenta de 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 reinstala 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 lo reinstala:

#!/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 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, verifica que funcione correctamente y se retengan todos los datos.

No quieres que los usuarios deban acceder, y toda su configuración, progreso y datos de la app deben ser como antes. Si los resultados de las pruebas no cumplen con estos criterios, asegúrate de haber configurado las copias de seguridad correctamente, sin omitir datos clave, y de que también estés controlando la recreación de los datos almacenados en caché que excluiste de la copia de seguridad. Repite los pasos del 1 al 3 para cada iteración de prueba.

Cómo probar la transferencia D2D

La forma más completa de probar la transferencia D2D es transferir todo el contenido del teléfono a un dispositivo nuevo con la configuración de fábrica restablecida y validar que funcione correctamente. Sin embargo, esto puede resultar 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 restablecer la configuración de fábrica de forma reiterada.

Prepara tu dispositivo para las pruebas D2D

Para probar la transferencia de D2D en un solo dispositivo, prepáralo 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, orienta tu app a Android 12 (nivel de API 31) o versiones posteriores.
  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 tu app, accede y modifica su configuración.
  3. Ejecuta la secuencia de comandos en tu dispositivo y pasa el nombre del paquete, como test_d2d.sh com.example.myapp.
  4. Cuando se complete la secuencia de comandos, abre la app en el dispositivo y verifica que funcione correctamente, con todos los datos retenidos.

No querrás que tus usuarios deban acceder y que toda la configuración, el progreso y los datos de la app deben aparecer como antes de ejecutar la secuencia de comandos. Si los resultados de la prueba no cumplen con estos criterios, asegúrate de haber configurado la transferencia de forma correcta, sin omitir fragmentos de datos clave, y de que también controlas la recreación de cualquier dato almacenado en caché que excluiste de la transferencia. Repite los pasos del 2 al 4 para cada iteración de prueba.

Soluciona problemas relacionados con la copia de seguridad y el restablecimiento

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

Se excedió 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 en Logcat indica que la operación de copia de seguridad completa falló porque aún no se ha realizado ninguna operación de copia de seguridad de par clave-valor en el dispositivo:

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

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

Se agotó el tiempo de espera del agente

El siguiente mensaje en 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 otra vez.

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. La copia de seguridad automática tampoco 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 par 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 signifique que no agregaste ningún dato ni archivo a la copia de seguridad.