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?
Respuestas:
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ásicoComo descubrió Izzy, la
bmgr
herramienta 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 herramientaadb shell
para 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.BACKUP
para hacer algo interesante con él.Puede hacer que una aplicación actualice sus datos respaldados inmediatamente:
(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:
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:
y obtendrás algunos resultados como este:
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:
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:
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.
fuente
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.
→ esto puede significar dos cosas:
→ esto podría explicar la falta de confiabilidad cuando se trata de diferentes dispositivos (o diferentes versiones de Android).
(énfasis mío)
(sin comentarios)
→ aquí tenemos la versión mínima de Android requerida para que Google Backup esté disponible: Froyo, AKA Android 2.2
→ 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)
→ parece que hay una manera de activar manualmente las copias de seguridad? Vamos a profundizar en eso más tarde. ↓
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.)
→ 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
→ parece que aquí hay una forma de activar acciones manualmente si el "automatismo" falla
→ 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.settings
para la configuración del sistema, ocom.android.providers.telephony
para SMS / MMS, etc.)bmgr run
comando→ 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:
bmgr
se 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í.fuente
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 sets
no 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.
fuente
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.
fuente
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 run
como 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!
fuente