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 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, la comprensión de estos conceptos se vuelve más importante.
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 la copia de seguridad y el restablecimiento en la nube.
En el siguiente diagrama, se ilustra cómo fluyen los datos durante una transferencia D2D:
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 D2D, el servicio del Administrador de copias de seguridad consulta los datos de copia de seguridad de 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 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: el transporte activo de copia de seguridad en la nube en la mayoría de los dispositivos, 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 emulador.bmgr: Se usa para realizar distintas operaciones de copia de seguridad y restablecimiento.logcat: Para ver el resultado de las operaciones de copia de seguridad y restablecimiento
Cómo 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 mediante la siguiente lista de tareas:
- 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.
- Para la copia de seguridad de par clave-valor, comprueba que estés usando un dispositivo o emulador con Android 2.2 (nivel de API 8) o versiones posteriores.
- Debes tener acceso a Internet para probar la copia de seguridad en la nube.
- Accede al dispositivo con una Cuenta de Google y establécela como la cuenta para 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 sean repetibles, puedes usar la siguiente secuencia de comandos, test_cloud_backup.sh, que crea una copia de seguridad de la 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
- Abre la app, accede y modifica todos los parámetros de configuración.
- Ejecuta la secuencia de comandos y pasa el nombre de tu paquete, como
test_cloud_backup.sh com.example.myapp. - Vuelve a abrir la app y valida que funcione correctamente, con todos los datos retenidos.
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 la prueba no cumplen con estos criterios, asegúrate de haber configurado las copias de seguridad de forma correcta, sin omitir datos clave, y de que también controlas la recreación de cualquier dato almacenado 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 D2D en un solo dispositivo, prepáralo de la siguiente manera:
- Tu dispositivo debe ejecutar Android 12 (nivel de API 31) o una versión posterior.
- Para probar la versión más reciente de D2D, orienta tu app a Android 12 (nivel de API 31) o versiones posteriores.
- 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
- Instala la app que quieras probar en el dispositivo.
- Abre tu app, accede y modifica su configuración.
- Ejecuta la secuencia de comandos en tu dispositivo y pasa el nombre del paquete, como
test_d2d.sh com.example.myapp. - Cuando se complete la secuencia de comandos, abre la app en el dispositivo y verifica que funcione correctamente, con todos los datos retenidos.
No quieres que los usuarios deban acceder, y toda su configuración, progreso y datos de la app deben aparecer como lo hacían 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 2 a 4 para cada iteración de prueba.
Cómo solucionar problemas de copia de seguridad y 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
En los siguientes mensajes de Logcat, se indica que se detuvo la copia de seguridad porque no se inicializó el conjunto de datos correspondiente:
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 de los que 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.