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 dispositivodm-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
.
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.
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:
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.
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.
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:
- El framework activa la partición
/system
a partir de un dispositivodm-verity
. que se apila sobre un dispositivodm-user
. Es decir, todas las operaciones de E/S del sistema de archivos raíz se enruta adm-user
. dm-user
enruta la E/S al daemonsnapuserd
del espacio de usuario, que controla la solicitud de E/S.- Cuando se completa la operación de combinación, el framework contrae
dm-verity
en en la parte superior dedm-linear
(system_base
) y quitadm-user
.
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:
- En la primera etapa,
init
iniciasnapuserd
desde el ramdisk y guarda un file-descriptor en una variable de entorno. - El
init
de primera etapa cambia el sistema de archivos raíz a la partición del sistema. Luego, ejecuta la copia del sistema deinit
. - La copia del sistema de
init
lee la política combinada en una cadena. Init
invoca amlock()
en todas las páginas respaldadas por ext4. Luego, desactiva todas Device-mapper para dispositivos de instantáneas y detienesnapuserd
. Después de esto no está permitido leer particiones, ya que se genera un interbloqueo.- 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. - 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