Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

Implementación de Virtual A / B

Para implementar A / B virtual en un nuevo dispositivo, o para actualizar un dispositivo iniciado, debe realizar cambios en el código específico del dispositivo.

Construye banderas

Los dispositivos que utilizan Virtual A / B deben configurarse como un dispositivo A / B y deben poner en marcha con particiones dinámicas .

Para los dispositivos que se inician con A / B virtual, configúrelos para que hereden la configuración básica del dispositivo A / B virtual:

$(call inherit-product, \
    $(SRC_TARGET_DIR)/product/virtual_ab_ota.mk)

Artefactos de lanzamiento con Virtual necesidad A / B sólo la mitad de tamaño del tablero tanto por BOARD_SUPER_PARTITION_SIZE porque las ranuras B ya no están en súper. Esto es, BOARD_SUPER_PARTITION_SIZE debe ser mayor que o igual a la suma (tamaño de los grupos de actualización) + sobrecarga, que, a su vez, debe ser mayor que o igual a la suma (tamaño de las particiones) + sobrecarga.

Para habilitar instantáneas comprimidas con Virtual A / B, herede la siguiente configuración base en su lugar:

$(call inherit-product, \
    $(SRC_TARGET_DIR)/product/virtual_ab_ota/compression.mk)

Control de arranque HAL

El HAL de control de arranque proporciona una interfaz para clientes OTA a ranuras de arranque de control. Virtual A / B requiere una actualización menor de la versión del control de arranque HAL porque se necesitan API adicionales para garantizar que el cargador de arranque esté protegido durante el flasheo / restablecimiento de fábrica. Ver IBootControl.hal y types.hal para la última versión de la definición de HAL.

// hardware/interfaces/boot/1.1/types.hal
enum MergeStatus : uint8_t {
    NONE, UNKNOWN, SNAPSHOTTED, MERGING, CANCELLED };

// hardware/interfaces/boot/1.1/IBootControl.hal
package android.hardware.boot@1.1;
interface IBootControl extends @1.0::IBootControl {
    setSnapshotMergeStatus(MergeStatus status)
        generates (bool success);
    getSnapshotMergeStatus()
        generates (MergeStatus status);
}
// Recommended implementation

Return<bool> BootControl::setSnapshotMergeStatus(MergeStatus v) {
    // Write value to persistent storage
    // e.g. misc partition (using libbootloader_message)
    // bootloader rejects wipe when status is SNAPSHOTTED
    // or MERGING
}

Cambios de fstab

La integridad de la partición de metadatos es esencial para el proceso de arranque, especialmente justo después de que se aplica una actualización OTA. Por lo tanto, la partición de metadatos debe ser comprobado antes first_stage_init lo monta. Para asegurar que esto suceda, añadir el check bandera fs_mgr a la entrada para /metadata . Lo siguiente proporciona un ejemplo:

/dev/block/by-name/metadata /metadata ext4 noatime,nosuid,nodev,discard,sync wait,formattable,first_stage_mount,check

Requisitos del kernel

Para habilitar la copia instantánea, juego CONFIG_DM_SNAPSHOT de true .

Para los dispositivos que utilizan f2fs, incluir los f2fs: exportación bandera FS_NOCOW_FL a usuario parche del kernel a quedar atrapado archivo de solución. Incluir los f2fs: el apoyo alineado clavado archivo de parche para el kernel así.

Un virtual / B se basa en características añadidas en la versión del kernel 4.3: el bit de estado de desbordamiento en las snapshot y snapshot-merge objetivos. Todos los dispositivos que se inician con Android 9 y posteriores ya deberían tener la versión de kernel 4.4 o posterior.

Para habilitar las instantáneas comprimidas, la versión mínima del kernel admitida es 4.19. Set CONFIG_DM_USER=m o CONFIG_DM_USER=y . Si usa el primero (un módulo), el módulo debe cargarse en el disco RAM de la primera etapa. Esto se puede lograr agregando la siguiente línea al archivo Makefile del dispositivo:

BOARD_GENERIC_RAMDISK_KERNEL_MODULES_LOAD := dm-user.ko

Actualización en dispositivos que se actualizan a Android 11

Al actualizar a Android 11, los dispositivos que se lanzaron con particiones dinámicas pueden actualizar opcionalmente A / B virtual. El proceso de actualización es prácticamente el mismo que para los dispositivos que se inician con A / B virtual, con algunas diferencias menores:

  • Ubicación de los archivos COW - Para los dispositivos de lanzamiento, el cliente OTA utiliza todo el espacio vacío disponible en la partición de súper antes de utilizar el espacio en /data . Para los dispositivos de reequipamiento, siempre hay suficiente espacio en la partición súper para que el archivo VACA Nunca se crea en /data .

  • Señalizadores de característica en tiempo de compilación - Para los dispositivos de instalación posterior virtual de A / B, tanto PRODUCT_VIRTUAL_AB_OTA y PRODUCT_VIRTUAL_AB_OTA_RETROFIT se establecen en true , como se muestra a continuación:

    (call inherit-product, \
        (SRC_TARGET_DIR)/product/virtual_ab_ota_retrofit.mk)
    
  • Super Size partición - Dispositivos de puesta a flote con un virtual / B puede cortar BOARD_SUPER_PARTITION_SIZE a la mitad debido a las ranuras B no están en la partición de super. Dispositivos de instalación posterior A virtual / B mantienen el tamaño súper partición edad, por lo BOARD_SUPER_PARTITION_SIZE es mayor que o igual a 2 suma * (tamaño de los grupos de actualización) + sobrecarga, que a su vez es mayor que o igual a 2 * sum (tamaño de las particiones) + sobrecarga.

Cambios en el cargador de arranque

Durante la etapa de fusión de una actualización, /data sólo posee toda la instancia del sistema operativo Android. Una vez que las aperturas de migración, el nativo system , vendor y product particiones son incompletos hasta que finalice la copia. Si el dispositivo se restablece a los valores de fábrica durante este proceso, ya sea mediante la recuperación o mediante el cuadro de diálogo de configuración del sistema, el dispositivo no podrá arrancar.

Antes de borrar /data , terminar la fusión en la recuperación o rollback dependiendo del estado del dispositivo:

  • Si la nueva compilación se inició correctamente antes, finalice la migración.
  • De lo contrario, retroceda a la ranura anterior:
    • Para particiones dinámicas, retroceda al estado anterior.
    • Para particiones estáticas, establezca la ranura activa en la ranura anterior.

Tanto el cargador de arranque y fastbootd puede borrar los /data partición si se desbloquea el dispositivo. Mientras fastbootd puede forzar la migración para completar, el gestor de arranque no se puede. El gestor de arranque no sabe si es o no una fusión está en curso, o lo bloquea en /data constituyen las particiones del sistema operativo. Los dispositivos deben evitar que el usuario inutilice el dispositivo sin saberlo (ladrillos) haciendo lo siguiente:

  1. Implementar la HAL de control de arranque para que el gestor de arranque puede leer el valor establecido por el setSnapshotMergeStatus() método.
  2. Si el estado de combinación es MERGING , o si el estado de combinación es SNAPSHOTTED y la ranura ha cambiado a la ranura recién actualizado, entonces solicita a borrar userdata , metadata , o la partición de almacenar el estado de mezcla debe ser rechazada en el gestor de arranque.
  3. Implementar el fastboot snapshot-update cancel comando de modo que los usuarios pueden indicar al gestor de arranque que se desea anular este mecanismo de protección.
  4. Modificar herramientas o scripts en el tema de parpadear a medida fastboot snapshot-update cancel cuando parpadea todo el dispositivo. Esto es seguro para emitir porque flashear todo el dispositivo elimina la OTA. Las herramientas pueden detectar este comando en tiempo de ejecución mediante la implementación de fastboot getvar snapshot-update-status . Este comando ayuda a diferenciar las condiciones de error.

Ejemplo

struct VirtualAbState {
    uint8_t StructVersion;
    uint8_t MergeStatus;
    uint8_t SourceSlot;
};

bool ShouldPreventUserdataWipe() {
    VirtualAbState state;
    if (!ReadVirtualAbState(&state)) ...
    return state.MergeStatus == MergeStatus::MERGING ||
           (state.MergeStatus == MergeStatus::SNAPSHOTTED &&
            state.SourceSlot != CurrentSlot()));
}

Cambios en las herramientas de Fastboot

Android 11 realiza los siguientes cambios en el protocolo fastboot:

  • getvar snapshot-update-status - Devuelve el valor que la HAL de control de arranque comunicada al cargador de arranque:
    • Si el estado es MERGING , el gestor de arranque debe devolver merging .
    • Si el estado se SNAPSHOTTED , el gestor de arranque debe devolver snapshotted .
    • De lo contrario, el gestor de arranque debe devolver none .
  • snapshot-update merge - completa una operación de fusión, el arranque de la recuperación / fastbootd si es necesario. Este comando es válido sólo si snapshot-update-status está merging , y sólo se admite en fastbootd.
  • snapshot-update cancel - estado de fusión Establece el control de arranque de HAL a CANCELLED . Este comando no es válido cuando el dispositivo está bloqueado.
  • erase o wipe - Un erase o wipe de metadata , userdata , o una partición que tiene el estado de mezcla para la HAL de control de arranque debe comprobar el estado de mezcla instantánea. Si el estado es MERGING o SNAPSHOTTED , el dispositivo debe abortar la operación.
  • set_active - Un set_active comando que cambia la ranura activa debe comprobar el estado de mezcla instantánea. Si el estado es MERGING , el dispositivo debe abortar la operación. La ranura de seguridad se puede cambiar en el SNAPSHOTTED estado.

Estos cambios están diseñados para evitar que un dispositivo no pueda arrancar accidentalmente, pero pueden ser perjudiciales para las herramientas automatizadas. Cuando se utilizan los comandos como un componente de parpadear todas las particiones, como la ejecución fastboot flashall , se recomienda utilizar el siguiente flujo:

  1. Consulta getvar snapshot-update-status .
  2. Si merging o snapshotted , emisión snapshot-update cancel .
  3. Continúe con los pasos de flasheo.

Reducir los requisitos de almacenamiento

Los dispositivos que no tienen el almacenamiento A / B total asignado en el súper, y están esperando a su uso /data cuando sea necesario, se recomienda encarecidamente el uso de la herramienta de mapeo de bloques. La herramienta de mapeo de bloques mantiene la asignación de bloques consistente entre compilaciones, lo que reduce las escrituras innecesarias en la instantánea. Esto está documentado en virtud de Reducción de Tamaño de OTA .