No es nada nuevo que uno pueda usar múltiples dispositivos Android con una sola cuenta de Google . Al encender un nuevo dispositivo por primera vez, se pregunta si uno desea almacenar sus datos con Google, que luego siempre sincronizaría "algunas cosas" con los servidores de Google, básicamente

• algunos datos de la aplicación (si las aplicaciones lo admiten explícitamente)
• Contraseñas de wifi
• marcadores del navegador
• una lista de las aplicaciones instaladas desde Google Play
• palabras agregadas al diccionario utilizado por el teclado en pantalla
• la mayoría de sus configuraciones personalizadas

Los detalles se pueden encontrar en el Panel de Google . Las preguntas relevantes aquí que cubren esos temas incluyen:

• ¿Qué información respalda Google?
• ¿Qué se sincroniza exactamente con Google?
• ¿Cómo sincroniza Android los perfiles WiFi?

La API de desarrolladores en Google Backup ofrece más información sobre cómo se supone que funcionan las cosas de la copia de seguridad (y varias preguntas aquí muestran cómo funciona realmente, es decir, a veces lo hace, a veces solo en parte y a veces en absoluto). Además de la confiabilidad y el hecho de que no todo el mundo quiere sus datos privados en la nube (e incluso la referencia ^{2 de} API mencionada advierte: Android no garantiza la seguridad de sus datos mientras usa la copia de seguridad. Siempre debe tener cuidado al usar la copia de seguridad para almacenar información confidencial). datos, como nombres de usuario y contraseñas ), mi pregunta principal es:

Habiendo hecho una copia de seguridad de los datos de múltiples dispositivos usando la misma cuenta:

• ¿Qué pasaría con un dispositivo de restablecimiento de fábrica que se usa de esa manera antes? ¿Sería reconocido y solo restauraría las cosas que se han usado antes?
  ^{(la identificación del dispositivo podría, por ejemplo, llevarse a cabo, por ejemplo, a través de IMEI (pero no a través de Android_ID, ya que podría haber desaparecido con un restablecimiento de fábrica ), y esta podría ser la razón del comportamiento descrito en la respuesta de Nalum )}
• ¿Qué se restauraría a un dispositivo (nuevo / restablecido de fábrica) que acaba de inicializar por primera vez con esta cuenta de Google?
  ^{(si los dispositivos se identificaran con copias de seguridad en la cuenta de Google utilizada, esto podría desencadenar una acción especial para "nuevo dispositivo", por ejemplo, "restaurar todo, dispositivo cambiado" o "restaurar todo desde el dispositivo X que ya no está conectado, como ¡probablemente fue reemplazado! ", pero manténgase en" restaurar solo lo que estaba en ese dispositivo "en caso de un restablecimiento de fábrica)}

El trato es: si uno tiene múltiples dispositivos, a menudo se usan para problemas específicos, por lo que no se quiere todo en todos los dispositivos. Como no he visto ninguna forma de elegir qué datos respaldar (por ejemplo, para excluir esos "datos confidenciales" de los que nos han advertido: las contraseñas WiFi pertenecerían a esa categoría), ¿supongo que tampoco hay opción para restaurar? Entonces, ¿cómo se maneja esto?

Hablemos de conjuntos, bebé

El servicio de respaldo de Android tiene un concepto llamado conjunto : el conjunto de todos los datos respaldados desde un dispositivo (en un transporte , pero eso es un detalle). Cada conjunto se identifica mediante una cadena única, como el IMEI en el dispositivo. Cuando se realiza una copia de seguridad de una aplicación (o la lista de aplicaciones instaladas), sus datos de copia de seguridad van al conjunto asociado con el dispositivo desde el que se realiza la copia de seguridad. Todos los conjuntos siguen siendo específicos de la cuenta de Google del usuario. Si limpia su dispositivo y se lo vende a otra persona, no podrá acceder al conjunto de ese dispositivo a menos que pueda iniciar sesión en su cuenta de Google.

Comportamiento predeterminado

Cuando se instala una aplicación, o un dispositivo tiene su lista de aplicaciones restauradas, el sistema de respaldo primero busca en el conjunto de ese dispositivo los datos de respaldo para ese paquete. Si no encuentra ninguno (ya sea porque es un dispositivo completamente nuevo sin datos respaldados, o porque ese paquete nunca se ha instalado en ese dispositivo), expandirá la búsqueda a otros conjuntos. (Si hay una opción, usará el último conjunto que se usó para una restauración completa del dispositivo).

Por lo tanto, cuando configura un nuevo dispositivo, restaurará la lista de aplicaciones de la copia de seguridad de un dispositivo antiguo y restaurará cada aplicación desde la copia de seguridad del dispositivo anterior. Si tenía una aplicación instalada en un dispositivo y la instala en otro dispositivo, la aplicación se restaurará con sus datos del dispositivo anterior. En cualquier caso, los datos ahora están respaldados en el conjunto del nuevo dispositivo, lo que significa que los datos de respaldo de los dos dispositivos están separados de ahora en adelante.

Después de restablecer de fábrica un dispositivo, se restaurará desde la última copia de seguridad de ese dispositivo si hay una, y en su defecto, desde la copia de seguridad de otro dispositivo si hay una, pero comenzará a crear su propio conjunto a partir de ese momento. Es por eso que los dos dispositivos de Nalum no ven las aplicaciones respaldadas de los demás: están restaurando desde sus últimas copias de seguridad.

Fuente

Este mecanismo no tiene ninguna documentación orientada al usuario, ya que se supone que hace automáticamente lo correcto, pero el código está disponible .

bmgr: uso básico

Como descubrió Izzy, la bmgrherramienta le da cierto control sobre este proceso. Su objetivo es ayudar a los programadores a probar y depurar la integración de copias de seguridad en sus aplicaciones. Puede usar esta herramienta adb shellpara activar copias de seguridad y restauraciones de paquetes elegidos, borrar los datos respaldados de los paquetes e incluso una restauración de todo el dispositivo.

No intente usarlo en un shell del dispositivo, excepto como root : necesita el nivel del sistema android.permission.BACKUPpara hacer algo interesante con él.

Puede hacer que una aplicación actualice sus datos respaldados inmediatamente:

bmgr backup com.shadowburst.showr
bmgr run

(o cualquiera que sea el nombre del paquete de la aplicación). Normalmente no hay necesidad de hacer esto, ya que las aplicaciones solicitan sus propias copias de seguridad cada vez que cambian sus datos, pero esto le permite evitar una aplicación mal escrita. Para restaurar un paquete de los datos respaldados, elegiría de manera predeterminada:

bmgr restore com.shadowburst.showr

pero nuevamente, esto solo hará lo que el dispositivo haría por sí mismo, por lo que no debería necesitar usarlo. Tenga en cuenta también que el dispositivo ya necesita estar instalado para que esto funcione.

Mas control

Ahora para las cosas que el sistema de copia de seguridad no hará en sí. Para ver qué conjuntos de datos respaldados están disponibles:

bmgr list sets

y obtendrás algunos resultados como este:

  3ff7800e963f25c5 : manta
  3f0e5c90a412cca7 : manta
  3dd65924a70e14c8 : TF101
  3baa67e9ce029355 : m0

El número hexadecimal de 64 bits a la izquierda es un token . Necesitarás esto en un minuto. Lo que está a la derecha es un nombre (relativamente) amigable para el dispositivo que posee el conjunto. Por ejemplo, manta es el nombre en clave del nexus-10 ; TF-101 se refiere al transformador original asus-eee-pad . Una vez que haya descubierto qué conjunto desea, puede restaurar una aplicación desde ese conjunto utilizando su token:

bmgr restore 3ff7800e963f25c5 com.shadowburst.showr

Puede agregar más nombres de paquetes al final del comando para restaurar varios paquetes a la vez, o puede especificar ningún nombre de paquete (solo el token) para restaurar cada aplicación con datos en ese conjunto (es decir, hace un sistema completo restaurar).

Finalmente, puede borrar los datos de una aplicación del conjunto actual:

bmgr wipe com.shadowburst.showr

Esto hará que su próxima operación de respaldo comience desde cero. Esto podría ser útil después de desinstalar una aplicación, si un error en la aplicación corrompió sus datos de respaldo y no desea que se restaure.

No puede hacer que un dispositivo comience a escribir en un conjunto diferente, ni puede borrar un conjunto completo.

Lo siguiente no es una respuesta a la pregunta, pero podría arrojar algo de luz sobre algunos detalles:

Algunas piezas extraídas de la API de respaldo

Aunque la API está dirigida principalmente a los desarrolladores, hay algunos hechos que podríamos extraer para nuestro caso. En la siguiente lista, las cursivas marcan citas de la documentación de la API.

• Android realiza automáticamente una operación de restauración cuando su aplicación está instalada y existen datos de respaldo asociados con el usuario.
  → esto puede significar dos cosas:
  • Si una aplicación es compatible con la API de copia de seguridad de Google y el usuario tiene habilitada la Copia de seguridad de Google, los datos de copia de seguridad disponibles se restaurarán automáticamente en la instalación. Es bueno cuando instala una aplicación utilizada en un solo dispositivo en un segundo dispositivo por primera vez.
  • las copias de seguridad solo están asociadas con la cuenta de Google, no con el dispositivo ( y existen datos de copia de seguridad asociados con el usuario ), o el otro hecho simplemente se ignoró como irrelevante para este caso especial ("la aplicación está instalada")
• El transporte de respaldo es el componente del lado del cliente del marco de respaldo de Android, que el fabricante del dispositivo y el proveedor de servicios pueden personalizar. El transporte de respaldo puede diferir de un dispositivo a otro [...]
  → esto podría explicar la falta de confiabilidad cuando se trata de diferentes dispositivos (o diferentes versiones de Android).
  ^{(énfasis mío)}
• No se garantiza que la copia de seguridad de datos esté disponible en todos los dispositivos con Android.
  (sin comentarios)
• Google proporciona un transporte de respaldo con el Servicio de respaldo de Android para la mayoría de los dispositivos con Android que ejecutan Android 2.2 o superior.
  → aquí tenemos la versión mínima de Android requerida para que Google Backup esté disponible: Froyo, AKA Android 2.2
• Para obtener su clave de servicio de respaldo, regístrese en el servicio de respaldo de Android. [...]
  → cada aplicación debe tener su propia clave. No se describe el "por qué", pero es una buena suposición: aislar las copias de seguridad para que ninguna aplicación pueda leer las copias de seguridad de otra aplicación (clave incorrecta; en cuanto a las copias de seguridad de otro usuario: cuenta incorrecta)
• Mientras desarrolla su aplicación, puede iniciar una operación de respaldo inmediata desde el Administrador de respaldo con la herramienta bmgr.
  → parece que hay una manera de activar manualmente las copias de seguridad? Vamos a profundizar en eso más tarde. ↓
• Cuando llega el momento de restaurar los datos de su aplicación, Backup Manager llama al onRestore()método de su agente de respaldo .
  → esto subraya nuevamente el primer elemento de esta lista: primero se debe instalar la aplicación, luego se utilizan sus propias implementaciones para restaurar sus datos. En una segunda mirada: si falla la restauración de la aplicación, no habrá una restauración de datos para las aplicaciones fallidas, hasta que las instale manualmente a través de Google Play. Luego, como mostró el primer elemento, los datos deben restaurarse automáticamente a través de Google Backup en las condiciones explicadas (debe haber sido respaldado con él, la misma cuenta, etc.)
• Copia de seguridad de otros archivos
  → perdóneme no citando el contenido (técnico) de ese capítulo, pero en resumen: solo los archivos del almacenamiento interno pueden ser respaldados de acuerdo con él.

Algunas piezas extraídas de la API de bmgr

• Proporciona comandos para inducir operaciones de copia de seguridad y restauración [...]
  → parece que aquí hay una forma de activar acciones manualmente si el "automatismo" falla
• Se accede a estos comandos a través del adb shell.
  → esto no necesita ninguna explicación :)
• adb shell bmgr backup <package>
  → OK, por lo que esta acción está vinculada a las aplicaciones. Supongo que si conoce el nombre del paquete del proveedor de datos, esto también debería funcionar (por ejemplo, com.android.providers.settingspara la configuración del sistema, o com.android.providers.telephonypara SMS / MMS, etc.)
• puede forzar que todas las operaciones de copia de seguridad pendientes se ejecuten inmediatamente usando el bmgr runcomando
  → el primer comando solo "programa" las copias de seguridad. Habiendo activado todos los paquetes, esto se puede usar para ejecutarlos inmediatamente.
• adb shell bmgr restore <package>
  → esto parece agradable para ser verdad, ¿verdad? Exactamente, porque: El Administrador de copia de seguridad creará una instancia inmediata del agente de copia de seguridad de la aplicación y lo invocará para su restauración. Solo datos, ya que la aplicación ya necesita estar allí (como se llaman sus rutinas).

En resumen: bmgrse puede utilizar para activar copias de seguridad de aplicaciones compatibles con Google Backup, que ha instalado, y puede activar la restauración de datos para el mismo. No se puede usar para activar una restauración completa, al menos eso no está documentado aquí.

Más información sobre la copia de seguridad de Google. Cuando presenté un firmware personalizado, no restauró las aplicaciones como esperaba. En Configuración -> Copia de seguridad y restablecer , mostraba "Copia de seguridad en caché privada solo de depuración", y bmgr list setsno dio resultados.
Resolví mi problema siguiendo estos pasos adb shell:
$ bmgr transport com.google.android.backup/.BackupTransportService
$ bmgr list sets 3a0a00a516a1daf1 : LT22i
Sin embargo, esto no fue suficiente. No comenzó a instalar aplicaciones. Esto demostró el motivo:
$ bmgr list sets 3179e4ab08d74930 : LT22i 3a0a00a516a1daf1 : LT22i
había creado un nuevo conjunto, aunque el IMEI obviamente era el mismo. De todos modos, esta fue la solución:
$ bmgr restore 3a0a00a516a1daf1(la identificación que mostró la primera vez)
$ bmgr run(para estar seguro)
Luego comenzó a descargar las aplicaciones.

Mi experiencia con él ha sido que cada dispositivo tiene su propia copia de seguridad. Obtengo esto jugando con mi Nexus 7 y mi Galaxy S II. Aparte de eso, no lo sé.

Aplicaciones:

Mi Nexus 7 tiene estas aplicaciones Caustic , DC Comics y 20 Minute Meals que, tras el restablecimiento de fábrica de mi Galaxy S II, no están instaladas en el Galaxy S II.

Mi Galaxy S II tiene estas aplicaciones DriveDroid y Human Japanese que tras el restablecimiento de fábrica de mi Nexus 7 no están instaladas en el Nexus 7.

Las aplicaciones son compatibles con ambos dispositivos, por lo que la incompatibilidad no puede ser la razón para que no se instalen en el otro dispositivo respectivo.

Datos:

En cuanto a Wifi y otros datos, no estoy seguro ya que cada vez que configuré el Wifi en cada dispositivo durante la configuración inicial de Android. En cuanto a otras cuentas de Google que pueda tener, no parecen estar copiadas en cada dispositivo y lo mismo ha sucedido con las cuentas de Skype y GitHub en cada dispositivo.

Realicé una copia de seguridad de las cosas usando la copia de seguridad de Google incorporada y la copia de seguridad de Helium antes de limpiar e instalar la ROM personalizada de Carbon en un Nexus 4 (del stock de KitKat). Se esperaba que Google restaurara aplicaciones, configuraciones, etc. como lo ha hecho antes cuando restauré este teléfono, pero no me alegro.

También probé Helium, tampoco fue un placer, incluso con las restauraciones manuales de 'Descarga de PC', dijo 'restaurado' pero los datos de Wifi y de la aplicación aún no están allí.

Ejecutar bmgr restore <xxx>la restauración completa y, bmgr runcomo se detalla anteriormente, activó la restauración completa de Google y funcionó de maravilla.

Google podría hacer un mejor esfuerzo, especialmente si quieren competir con la idea de Apple 'simplemente funciona' ... ¡Sin embargo, me encanta la piratería de Android a pesar de sus dificultades!