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 utiliza una imagen de recuperación AOSP no modificada, el gestor de arranque lee los primeros 32 bytes en la partición misc ; si los datos allí coinciden con boot-recovery , el gestor de arranque arranca en la imagen recovery . Este método permite que cualquier trabajo de recuperación pendiente (por ejemplo, aplicar una OTA o eliminar datos) continúe hasta su finalización.

Para obtener detalles sobre el contenido de un bloque en flash utilizado para las comunicaciones entre la recuperación y el gestor 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 actualizarse durante la recuperación).

• Para iniciar 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 Android llamar markBootSuccessful desde HAL. El gestor de arranque nunca debe marcar una partición como iniciada correctamente.

Soporte para control de arranque HAL

El gestor de arranque debe admitir boot_control HAL como se define en hardware/libhardware/include/hardware/boot_control.h ). El actualizador consulta el control de arranque HAL , actualiza la ranura de arranque que no está en uso actualmente, cambia la ranura activa usando 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 gestor de arranque debe admitir funciones relacionadas con particiones y ranuras, que incluyen:

• Los nombres de las particiones deben incluir un sufijo que identifique qué particiones pertenecen a una ranura 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 particiones con el sufijo _a , _b , _c , etc. El gestor de arranque debe informar al sistema operativo qué ranura se inició utilizando 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 (normalmente 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 gestor de arranque borra "arrancado exitosamente" y restablece el recuento de reintentos para la ranura.

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

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

2. Si la ranura actual no está marcada como slot-successful y tiene un slot-retry-count = 0 , márquela como slot-unbootable . Luego seleccione una ranura diferente que no esté marcada unbootable y que esté marcada como slot-successful ; esta ranura es ahora la ranura seleccionada. Si no hay ninguna 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 correcta del sistema en la línea de comando del kernel.

4. Complete el parámetro slot_suffix de la línea de comando 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 comando fastboot flash system system.img primero consulta la variable current-slot y 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 usando el comando fastboot set_active o el comando HAL setActiveBootSlot de control de arranque, el gestor de arranque debe actualizar la ranura actual, borrar slot-unbootable y slot-successful y restablecer el recuento de reintentos (esta es la única manera de borrar slot-unbootable ).

Dispositivos sin actualizaciones A/B

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

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

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

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

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

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