Compatibilidad con actualizaciones de OTA

Para admitir las actualizaciones inalámbricas (OTA) , el gestor de arranque debe poder acceder a un disco RAM de recuperación durante el arranque. Si el dispositivo usa una imagen de recuperación AOSP sin modificar, el cargador de arranque lee los primeros 32 bytes en la partición misc ; si los datos allí coinciden boot-recovery , el gestor de arranque se inicia en la imagen de recovery . Este método permite que cualquier trabajo de recuperación pendiente (por ejemplo, aplicar una OTA o eliminar datos) continúe hasta completarse.

Para obtener detalles sobre el contenido de un bloque en flash utilizado para las comunicaciones entre la recuperación y el cargador de arranque, consulte bootable/recovery/bootloader_message/bootloader_message.h .

Dispositivos con actualizaciones A/B

Para admitir actualizaciones OTA en dispositivos que usan actualizaciones A/B , asegúrese de que el cargador de arranque del dispositivo cumpla con los siguientes criterios.

Criterios generales

• Todas las particiones actualizadas a través de una OTA deben poder actualizarse mientras se inicia el sistema principal (y no se actualizan en la recuperación).

• Para arrancar la partición del system , el gestor de arranque pasa el siguiente valor en la línea de comando del kernel: ro root=/dev/[node] rootwait init=/init .

• Es responsabilidad del marco de trabajo de Android llamar a markBootSuccessful desde HAL. El cargador de arranque nunca debe marcar una partición como arrancada correctamente.

Soporte para control de arranque HAL

El cargador de arranque debe ser compatible boot_control HAL como se define en hardware/libhardware/include/hardware/boot_control.h ). El actualizador consulta la HAL de control de arranque , actualiza la ranura de arranque que no está en uso actualmente, cambia la ranura activa usando la HAL y reinicia en el sistema operativo actualizado. Para obtener más información, consulte Implementación del control de arranque HAL .

Soporte para tragamonedas

El cargador de arranque debe admitir la funcionalidad relacionada con las particiones y las ranuras, que incluyen:

• Los nombres de las particiones deben incluir un sufijo que identifique qué particiones pertenecen a una ranura en particular en el gestor de arranque. Para cada una de estas particiones, hay una variable correspondiente has-slot: partition base name con un valor de yes . Las ranuras se nombran alfabéticamente como a, b, c, etc. correspondientes a las particiones con el sufijo _a , _b , _c , etc. El cargador de arranque debe informar al sistema operativo qué ranura se inició usando la propiedad de línea de comando androidboot.slot_suffix . Esta propiedad se establece a través de bootconfig para dispositivos que se inician con Android 12 o posterior.

• El valor slot-retry-count se restablece a un valor positivo (generalmente 3 ), ya sea mediante el control de arranque HAL a través de la devolución de llamada setActiveBootSlot o mediante el comando fastboot set_active . Al modificar una partición que forma parte de una ranura, el cargador de arranque borra "arrancado con éxito" y restablece el recuento de reintentos para la ranura.

El cargador de arranque también debe determinar qué ranura cargar. La figura muestra un proceso de decisión de ejemplo.

1. Determine qué ranura intentar. No intente cargar una ranura marcada como slot-unbootable . Esta ranura debe ser coherente con los valores devueltos por fastboot y se denomina ranura actual.

2. Si el slot actual no está marcado como slot-successful y tiene un slot-retry-count = 0 , marque el slot actual como slot-unbootable . Luego, seleccione una ranura diferente que no esté marcada como no unbootable y que esté marcada como slot-successful ; esta ranura es ahora la ranura seleccionada. Si no hay una ranura actual disponible, inicie la recuperación o muestre un mensaje de error significativo al usuario.

3. Seleccione el boot.img apropiado e incluya la ruta a la partición del sistema correcta en la línea de comando del kernel.

4. Rellene el parámetro slot_suffix de la línea de comandos del kernel.

5. Bota. Si no está marcado slot-successful , disminuya slot-retry-count .

La utilidad fastboot determina qué partición flashear cuando se ejecuta cualquier comando flash. Por ejemplo, ejecutar el fastboot flash system system.img primero consulta la variable current-slot luego concatena el resultado al sistema para generar el nombre de la partición que debe actualizarse ( system_a , system_b , etc.).

Al configurar la ranura actual con el comando fastboot set_active o el comando de control de arranque HAL setActiveBootSlot , el gestor de arranque debe actualizar la ranura actual, borrar slot-unbootable y slot-successful , y restablecer el conteo de reintentos (esta es la única forma de borrar slot-unbootable ).

Dispositivos sin actualizaciones A/B

Para admitir actualizaciones OTA en dispositivos que no usan actualizaciones A/B (consulte Dispositivos no actualizables A/B ), asegúrese de que el cargador de arranque del dispositivo cumpla con los siguientes criterios.

• La partición de recovery debe contener una imagen que sea capaz de leer una imagen del sistema desde alguna partición compatible ( cache , datos de userdata ) y escribirla en la partición del system .

• El cargador de arranque debería admitir el reinicio directamente en modo de recuperación.

• Si se admiten actualizaciones de imagen de radio, la partición de recovery también debería poder actualizar la radio. Esto se puede lograr de una de dos maneras:

  • El gestor de arranque parpadea la radio. En este caso, debería ser posible reiniciar desde la partición de recuperación al gestor de arranque para completar la actualización.

  • La imagen de recuperación parpadea la radio. Esta funcionalidad se puede proporcionar como una utilidad o biblioteca binaria.