Descripción general de A/B virtual

Android tiene dos mecanismos de actualización: actualizaciones A/B (fluidas) y actualizaciones que no son A/B. Para reducir la complejidad del código y mejorar el proceso de actualización, en Android 11, la dos mecanismos se unifican mediante una prueba A/B virtual para ofrecer actualizaciones fluidas a todos con un costo de almacenamiento mínimo. Android 12 ofrece la opción de compresión A/B virtual para comprimir particiones con instantáneas. Tanto en Android 11 como en Android 12, lo siguiente aplicar:

  • Las actualizaciones A/B virtuales son perfectas, al igual que las actualizaciones A/B. Actualizaciones de A/B virtuales minimizar el tiempo que el dispositivo permanece inutilizable y sin conexión.
  • Las actualizaciones A/B virtuales se pueden revertir. Si el SO nuevo no se inicia, los dispositivos se reviertan automáticamente a la versión anterior.
  • Las actualizaciones A/B virtuales usan un espacio adicional mínimo, ya que duplican solo o particiones que usa el bootloader. Otras particiones actualizables son las instantánea.

Información general y terminología

En esta sección, se define la terminología y se describe la tecnología que respalda A/B virtual.

Asignador de dispositivos

Device-mapper es una capa de bloque virtual de Linux que se usa con frecuencia en Android. Con particiones dinámicas, como las siguientes: /system son una pila de dispositivos en capas:

  • En la parte inferior de la pila se encuentra la partición super física (por ejemplo, /dev/block/by-name/super).
  • En el medio hay un dispositivo dm-linear que especifica qué bloques de la de la partición en cuestión. Aparece como /dev/block/mapper/system_[a|b] en un dispositivo A/B /dev/block/mapper/system en un dispositivo que no es A/B.
  • En la parte superior, se encuentra un dispositivo dm-verity creado para particiones verificadas. Este dispositivo verifica que estén firmados los bloqueos en el dispositivo dm-linear correctamente. Aparece como /dev/block/mapper/system-verity y es la fuente del punto de activación /system.

En la Figura 1, se muestra cómo se ve la pila debajo del punto de activación /system.

Apilamiento de particiones debajo
sistema

Figura 1: Pila debajo del punto de activación /system

instantánea de m

El A/B virtual se basa en dm-snapshot, un módulo de asignación de dispositivos para tomar instantáneas de la estado de un dispositivo de almacenamiento. Cuando usas dm-snapshot, hay cuatro dispositivos en reproducir:

  • El dispositivo base es el dispositivo del que se toma la instantánea. En esta página, la base siempre es una partición dinámica, como sistema o proveedor.
  • El dispositivo de copia en escritura (COW), para registrar cambios en el dispositivo de base. Integra puede ser de cualquier tamaño, pero debe ser lo suficientemente grande como para admitir todos los cambios en la dispositivo base.
  • El dispositivo snapshot se crea con el destino snapshot. Escribe en el de instantáneas se escriben en el dispositivo COW. Lee de la instantánea lee desde el dispositivo base o el dispositivo COW, según si la instantánea cambió los datos a los que accede.
  • El dispositivo de origen se crea con el destino snapshot-origin. Lee para que el dispositivo de origen lea directamente desde el dispositivo base. Escribe en el origen El dispositivo escribe directamente en el dispositivo base, pero se crea una copia de seguridad de los datos originales. escribiéndole al dispositivo COW.

Asignación de dispositivos para
instantánea de m

Figura 2: Asignación de dispositivos para dm-snapshot

Instantáneas comprimidas

En Android 12 y versiones posteriores, como los requisitos de espacio la partición /data puede ser alta, puedes habilitar instantáneas comprimidas en tu Compila para abordar los requisitos de espacio más altos de la partición /data.

Las instantáneas comprimidas A/B virtuales se compilan sobre los siguientes componentes que están disponibles en Android 12 y versiones posteriores:

  • dm-user, un módulo de kernel similar a FUSE que permite que el espacio del usuario para implementar dispositivos de almacenamiento en bloques.
  • snapuserd, un daemon de espacio de usuario para implementar una instantánea nueva de un conjunto de datos tengan un formato común.

Estos componentes permiten la compresión. Los demás cambios necesarios que se realizan en las capacidades de las instantáneas comprimidas se proporcionan en las siguientes secciones: Formato COW para instantáneas comprimidas, dm-user y Snapuserd.

Formato COW para instantáneas comprimidas

En Android 12 y versiones posteriores, las instantáneas comprimidas usan un COW. Es similar al formato integrado del kernel que se usa para aplicaciones el formato COW para las instantáneas comprimidas tiene secciones alternadas de metadatos y datos. Los metadatos del formato original solo están permitidos para replace Operaciones: Reemplaza el bloque X en la imagen base por el contenido del bloque Y. en la instantánea. El formato COW de instantáneas comprimidas es más expresivo y admite las siguientes operaciones:

  • Copiar: El bloque X en el dispositivo base debe reemplazarse por el bloque Y en el dispositivo base.
  • Reemplazar: el bloque X en el dispositivo base debe reemplazarse por el contenido. del bloque Y en la instantánea. Cada uno de estos bloques está comprimido en gz.
  • Cero: El bloque X del dispositivo base debe reemplazarse por ceros.
  • XOR: El dispositivo COW almacena bytes comprimidos XOR entre el bloque X y el bloque Y. (Disponible en Android 13 y versiones posteriores).

Las actualizaciones OTA completas consisten únicamente en operaciones de reemplazo y cero. Incremental Las actualizaciones OTA también pueden tener operaciones de copia.

dm-user en Android 12

El módulo de kernel dm-user permite que userspace implemente el bloque device-mapper dispositivos. Una entrada de la tabla dm-user crea un dispositivo variado en /dev/dm-user/<control-name> Un proceso userspace puede sondear el dispositivo para recibir solicitudes de lectura y escritura del kernel. Cada solicitud tiene un para que el espacio del usuario se propague (para una lectura) o se propague (para una escritura).

El módulo de kernel dm-user proporciona una nueva interfaz visible para el usuario al kernel que no forma parte de la base de código ascendente de kernel.org. Hasta que lo esté, Google se reserva el derecho de modificar la interfaz dm-user en Android.

Snapuserd

El componente de espacio de usuario snapuserd para dm-user implementa A/B virtual. compresión.

En la versión sin comprimir de A/B virtual (ya sea en Android 11 y versiones anteriores, o en Android 12 sin la opción de instantánea comprimida) el dispositivo COW es un archivo sin procesar. Cuando se habilita la compresión, las funciones COW en su lugar, como un dispositivo dm-user, que está conectado a una instancia de la Daemon de snapuserd.

El kernel no usa el nuevo formato COW. Por lo tanto, el componente snapuserd traduce las solicitudes entre el formato COW de Android y el kernel formato:

El componente de Snapuserd traduce solicitudes entre el formato COW de Android y el kernel
integrado
formato

Figura 3: Diagrama de flujo de Snapuserd como traductor entre Android y el kernel Formatos COW

Esta traducción y descompresión nunca ocurren en el disco. El snapuserd El componente intercepta las operaciones de lectura y escritura de COW que ocurren en el kernel. las implementa con el formato Android COW.

Compresión XOR

En el caso de los dispositivos que se lanzan con Android 13 y versiones posteriores, la La función de compresión XOR, habilitada de forma predeterminada, habilita el espacio del usuario para almacenar bytes comprimidos XOR entre bloques antiguos y nuevos. Cuándo solo se modifican unos pocos bytes en un bloque en una actualización de A/B virtual, el operador XOR El esquema de almacenamiento por compresión usa menos espacio que el esquema de almacenamiento predeterminado porque las instantáneas no almacenan 4,000 bytes completos. Esta reducción del tamaño de la instantánea es posible porque los datos XOR contienen muchos ceros y son más fáciles de comprimir que los sin procesar de datos en bloque. En dispositivos Pixel, la compresión XOR reduce el tamaño de las instantáneas en un 25% a 40%

Para dispositivos que se actualizan a Android 13 y versiones posteriores, XOR la compresión debe estar habilitada. Para obtener más información, consulta XOR compresión.

Procesos de compresión A/B virtual

Esta sección proporciona información acerca del proceso de compresión A/B virtual que se utiliza en Android 13 y Android 12

Lee metadatos (Android 12)

Un daemon snapuserd construye los metadatos. Los metadatos son, ante todo, un asignación de dos IDs, de 8 bytes cada uno, que representen los sectores que se combinarán. En dm-snapshot se llama disk_exception.

struct disk_exception {
    uint64_t old_chunk;
    uint64_t new_chunk;
};

Se usa una excepción de disco cuando se reemplaza un fragmento de datos antiguo por uno nuevo.

Un daemon snapuserd lee el archivo COW interno a través de la biblioteca COW y construye los metadatos para cada una de las operaciones de COW presentes en el archivo COW.

Las lecturas de metadatos se inician desde dm-snapshot en el kernel cuando se crea el dispositivo dm- snapshot.

En la siguiente figura, se proporciona un diagrama de secuencias de la ruta de E/S para los metadatos la construcción.

Diagrama de secuencias, ruta de E/S para los metadatos
construcción

Figura 4: Flujo de secuencias para la ruta de acceso de IO en la construcción de metadatos

Combinación (Android 12)

Una vez que se completa el proceso de inicio, el motor de actualización marca la ranura como inicio. de forma correcta e inicia la combinación cambiando el destino dm-snapshot al Objetivo de dm-snapshot-merge.

dm-snapshot revisa los metadatos y, luego, inicia una E/S de combinación para cada disco. excepción. A continuación, se muestra una descripción general de alto nivel de la ruta de E/S de combinación.

Combinar ruta de E/S

Figura 5: Descripción general de la ruta de E/S de combinación

Si se reinicia el dispositivo durante el proceso de combinación, la combinación se reanudará en la siguiente reinicio, y se completará la combinación.

Capas del asignador de dispositivos

En el caso de los dispositivos que se lanzan con Android 13 y versiones posteriores, la Se realizan procesos de combinación de instantáneas y instantáneas en la compresión A/B virtual. por el componente de espacio de usuario snapuserd Para dispositivos que se actualizan a Android 13 y versiones posteriores, se debe habilitar esta función. Para consulta Espacio de usuario combinarla.

A continuación, se describe el proceso de compresión A/B virtual:

  1. El framework activa la partición /system a partir de un dispositivo dm-verity. que se apila sobre un dispositivo dm-user. Es decir, todas las operaciones de E/S del sistema de archivos raíz se enruta a dm-user.
  2. dm-user enruta la E/S al daemon snapuserd del espacio de usuario, que controla la solicitud de E/S.
  3. Cuando se completa la operación de combinación, el framework contrae dm-verity en en la parte superior de dm-linear (system_base) y quita dm-user.

Compresión A/B virtual
proceso

Figura 6: Proceso de compresión A/B virtual

El proceso de combinación de instantáneas puede interrumpirse. Si el dispositivo se reinicia durante el proceso de combinación, este se reanuda después del reinicio.

Iniciar transiciones

Cuando se inicia con instantáneas comprimidas, el init de primera etapa debe comenzar snapuserd para activar particiones. Esto plantea un problema: cuando se carga sepolicy. y se aplica, snapuserd se coloca en el contexto equivocado y sus solicitudes de lectura con denegaciones de selinux.

Para solucionar este problema, snapuserd realiza una transición en el paso de bloqueo con init, de la siguiente manera:

  1. En la primera etapa, init inicia snapuserd desde el ramdisk y guarda un file-descriptor en una variable de entorno.
  2. El init de primera etapa cambia el sistema de archivos raíz a la partición del sistema. Luego, ejecuta la copia del sistema de init.
  3. La copia del sistema de init lee la política combinada en una cadena.
  4. Init invoca a mlock() en todas las páginas respaldadas por ext4. Luego, desactiva todas Device-mapper para dispositivos de instantáneas y detiene snapuserd. Después de esto no está permitido leer particiones, ya que se genera un interbloqueo.
  5. Usando el descriptor abierto para la copia de ramdisk de snapuserd, init vuelve a iniciar el daemon con el contexto de selinux correcto. Tablas del asignador de dispositivos para dispositivos de instantáneas.
  6. Init invoca a munlockall(). Es seguro volver a ejecutar IO.

Uso del espacio

En la siguiente tabla, se muestra una comparación del uso del espacio de diferentes dispositivos inalámbricos de seguridad con tamaños inalámbricos y de SO de Pixel.

Impacto del tamaño no A/B A/B A/B virtual A/B virtual (comprimido)
Imagen de fábrica original Superficie de 4.5 GB (imagen de 3.8 GB + 700 millones de recursos reservados)1 9 GB de almacenamiento super (3.8 G + 700 M reservados, para dos ranuras) 4.5 GB de Super (imagen de 3.8 GB + 700 millones reservados) 4.5 GB de Super (imagen de 3.8 GB + 700 millones reservados)
Otras particiones estáticas /cache Ninguno Ninguno Ninguno
Almacenamiento adicional durante OTA (espacio que se devuelve después de aplicar OTA) 1,4 GB en /data 0 3.8 GB2 en /data 2.1 GB2 en /data
Almacenamiento total necesario para aplicar la tecnología inalámbrica 5.9 GB3 (super y datos) 9 GB (súper) 8.3 GB3 (super y datos) 6.6 GB3 (super y datos)

1 Indica el diseño adoptado en función de la asignación de píxeles.

2 Se supone que la imagen del sistema nueva tiene el mismo tamaño que la original.

3 El requisito de espacio será transitorio hasta el reinicio.

Para implementar una A/B virtual o usar capacidades de instantáneas comprimidas, consulta Implementa un A/B virtual