Lo que sigue no es, de lejos, 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, cursiva marcar las citas de la documentación de la API.

• Android realiza automáticamente una operación de restauración cuando se instala la aplicación y existe una copia de seguridad de los datos asociados al usuario.
  → esto puede significar dos cosas:
  • si una aplicación es compatible con el API de Google Backup y el usuario tiene habilitado Google Backup, los datos de copia de seguridad disponibles se restaurarán automáticamente en la instalación. Lo bueno es que cuando se instala por primera vez una aplicación usada en un solo dispositivo, se instala en un segundo dispositivo.
  • Las copias de seguridad sólo están asociadas a la cuenta de Google, no al dispositivo ( y existe una copia de seguridad de los datos asociados con el usuario ) -- o el otro hecho fue simplemente ignorado 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 es personalizadas por el fabricante del dispositivo y el proveedor de servicios. El transporte de reserva puede diferir de un dispositivo a otro [...]
  → esto podría explicar la falta de fiabilidad cuando se trata de diferentes dispositivos (o diferentes versiones de Android).
  (énfasis mío)
• No se garantiza que la copia de seguridad de los 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 funcionan con Android 2.2 o superior.
  → aquí tenemos la versión mínima de Android necesaria para que Google Backup esté disponible: Froyo, alias 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 hay un "por qué" descrito, pero 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 equivocada; en cuanto a las copias de seguridad de otro usuario: cuenta equivocada)
• Durante el desarrollo de su aplicación, puede iniciar una operación de copia de seguridad inmediata desde el Administrador de Copias de Seguridad con la herramienta bmgr.
  → parece que hay una forma de activar manualmente las copias de seguridad? Excavemos en eso más tarde. ↓
• Cuando llega el momento de restaurar los datos de la aplicación, el Administrador de Copias de Seguridad llama a su agente de copias de seguridad onRestore() método.
  → esto subraya de nuevo el primer elemento de esta lista: primero debe instalarse la aplicación, luego se utilizan sus propias implementaciones para restaurar sus datos. En una segunda mirada: si el app-restore falla, no habrá un data-restore para las aplicaciones fallidas -- hasta que las instale manualmente a través de Google Play. Entonces, como se muestra en el primer punto, los datos deben ser restaurados automáticamente a través de Copia de seguridad de Google bajo las condiciones explicadas (debe haber sido respaldado con él, la misma cuenta, etc.)
• Hacer una copia de seguridad de otros archivos
  → perdóneme no citar el contenido (técnico) de ese capítulo, pero en resumen: sólo los archivos del almacenamiento interno pueden ser respaldados de acuerdo a él.

Algunas piezas extraídas de la bmgr API

• Proporciona comandos para inducir el respaldo y restaurar las operaciones [...]
  → parece que aquí hay una forma de desencadenar acciones manualmente si el "automatismo" falla
• Estos comandos se acceden a través del shell adb.
  → esto no necesita ninguna explicación :)
• adb shell bmgr backup <package>
  → OK, así que esta acción está ligada a las aplicaciones. Supongo que si conoces el nombre del paquete del proveedor de datos, esto debería funcionar también (por ejemplo. com.android.providers.settings para la configuración del sistema, o com.android.providers.telephony para SMS/MMS, etc.)
• puedes forzar todas las operaciones de respaldo pendientes para que se ejecuten inmediatamente usando el bmgr run comando
  → el primer comando sólo "programa" copias de seguridad. Habiendo disparado todos los paquetes, esto puede ser usado para ejecutarlos inmediatamente.
• adb shell bmgr restore <package>
  → esto parece demasiado bueno para ser verdad, ¿verdad? Exactamente, porque: El Administrador de Copias de Seguridad instanciará inmediatamente el agente de copia de seguridad de la aplicación y lo invocará para su restauración. Sólo datos, ya que la aplicación ya necesita estar ahí (como se llaman sus rutinas).

Así que en resumen: bmgr puede utilizarse para activar las copias de seguridad de las aplicaciones compatibles con Google Backup, que has instalado, y puede activar la restauración de datos para las mismas. 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 flasheé un firmware personalizado no restauró las aplicaciones como esperaba. En Configuración -> Copia de seguridad y restablecimiento estaba mostrando "Copia de seguridad de la caché privada de depuración", y bmgr list sets no dio ningún resultado.
Resolví mi problema haciendo estos pasos en adb shell :
$ bmgr transport com.google.android.backup/.BackupTransportService
$ bmgr list sets 3a0a00a516a1daf1 : LT22i
Sin embargo, esto no fue suficiente. No empezó a instalar aplicaciones. Esto mostró la razón del porqué:
$ bmgr list sets 3179e4ab08d74930 : LT22i 3a0a00a516a1daf1 : LT22i
Había creado un nuevo conjunto, aunque el IMEI obviamente era el mismo. De todos modos, este era el arreglo:
$ bmgr restore 3a0a00a516a1daf1 (la identificación que mostró la primera vez)
$ bmgr run (para estar seguros)
Entonces empezó a descargar las aplicaciones.

Mi experiencia ha sido que cada dispositivo tiene su propio respaldo. Esto lo consigo por jugar con mi Nexus 7 y mi Galaxy S II. Aparte de eso, no lo sé.

Aplicaciones:

Mi Nexus 7 tiene estas aplicaciones Cáustico , DC Comics y Comidas de 20 minutos que al reiniciar la fábrica de mi Galaxy S II no están instalados en la Galaxy S II.

Mi Galaxy S II tiene estas aplicaciones DriveDroid y Los japoneses humanos que al reiniciar de fábrica mi Nexus 7 no están instalados en el Nexus 7.

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

Data:

En cuanto a la Wifi y otros datos no estoy seguro ya que cada vez que he configurado la Wifi en cada dispositivo durante la configuración inicial de Android. En cuanto a otras cuentas de Google que puedas tener, parece que no se copian en cada dispositivo y lo mismo ha ocurrido con las cuentas de Skype y GitHub en cada dispositivo.

Hice una copia de seguridad de las cosas usando la copia de seguridad incorporada de Google y la copia de seguridad de Helio antes de borrar e instalar la ROM personalizada de Carbono en un Nexus 4 (de las existencias de KitKat). Esperaba que Google restaurara aplicaciones, configuraciones, etc. como lo ha hecho antes cuando he restaurado este teléfono, pero no fue así.

Probé el helio también, pero tampoco me gustó, incluso con las restauraciones manuales de "Descarga de PC", dijo "restaurado" pero el Wifi y los datos de la aplicación todavía no están ahí.

Corriendo bmgr restore <xxx> restauración completa y bmgr run como se detalló anteriormente, activó la restauración completa de Google y funcionó de maravilla, ¡me salvó la vida!

Google podría hacer un mejor esfuerzo, especialmente si quieren competir con la idea de Apple de "sólo funciona"... Aún así, me encanta la capacidad de hacking de Android a pesar de sus dificultades.