A partir de 2026, para alinearnos con nuestro modelo de desarrollo estable de la rama principal y garantizar la estabilidad de la plataforma para el ecosistema, publicaremos el código fuente en AOSP en el segundo y cuarto trimestre. Para compilar AOSP y contribuir a él, te recomendamos que utilices android-latest-release en lugar de aosp-main. La rama del manifiesto android-latest-release siempre hará referencia a la versión más reciente que se envió al AOSP. Para obtener más información, consulta Cambios en AOSP.

Implementa GBL

En esta página, se explica cómo implementar el objeto binario del bootloader genérico (GBL).

Requisitos del firmware de inicio

Para usar GBL, el firmware de inicio debe cumplir con los siguientes requisitos:

Cumplimiento de la interfaz de firmware extensible unificada (UEFI). El firmware debe implementar y usar los protocolos UEFI requeridos. El firmware también debe permitir extensiones específicas del proveedor con protocolos UEFI definidos.
Seguridad El firmware debe implementar todos los requisitos de Android Verified Boot (AVB), lo que permite que GBL autentique imágenes de inicio.
Modos de inicio El objeto binario debe poder controlar varios modos de inicio, como el inicio normal, el inicio de recuperación y el modo fastboot.
Particiones dinámicas El firmware de inicio debe implementar la lógica de selección de ranuras para que admita la lectura de la ranura de inicio A/B correcta y sea compatible con las particiones dinámicas y los datos del usuario en super.
Configuración del SO El firmware debe poder modificar la línea de comandos del kernel, el árbol de dispositivos (DTB) y bootconfig con las personalizaciones del OEM necesarias para iniciar el dispositivo.
Carga de VM protegida El objeto binario debe cargar correctamente el firmware de la VM protegida verificado previamente antes del kernel de Android en presencia de VMs protegidas. Para obtener más información, consulta Secuencia de inicio de Microdroid.
Administración de la memoria El firmware de inicio debe admitir la API de asignación de memoria de UEFI.

Requisitos para la implementación

Para que GBL se implemente correctamente en tu dispositivo, debes cumplir con los siguientes requisitos:

Tu dispositivo debe contener dos particiones FAT de 8 MB (o más) llamadas android_esp_a y android_esp_b en un dispositivo de almacenamiento en bloques al que pueda acceder el SOC.
- Un dispositivo de almacenamiento en bloques es un dispositivo de almacenamiento que se puede leer o escribir en unidades de bloques. Algunos ejemplos son los dispositivos UFS, eMMC y tarjetas SD.
- Se usa FAT porque es un sistema de archivos omnipresente y sencillo.
- Te recomendamos que elijas el sistema de archivos FAT adecuado para tus necesidades entre FAT12, FAT16 y FAT32.
- Se requieren ambas particiones para las actualizaciones y los rollbacks inalámbricos (OTA) durante el período de compatibilidad de esta versión de Android.
- GBL tiene aproximadamente 2 MB sin comprimir. 8 MB son suficientes para tener en cuenta cualquier crecimiento debido a funciones adicionales durante los próximos siete años.
- En caso de una actualización de GBL, debes actualizar toda la partición android_esp_${SLOT_SUFFIX}. Android OTA no admite una actualización solo de GBL.
- El GUID del tipo de partición que se usa para ambas particiones FAT debe corresponder al GUID de la partición del sistema EFI C12A7328-F81F-11D2-BA4B-00A0C93EC93B.
Nota: Es posible que necesitemos actualizaciones importantes de GBL para la funcionalidad crítica.
La versión de GBL implementada debe ser la compilación de producción certificada más reciente de la rama de lanzamiento de GBL correspondiente. Te recomendamos que firmes la copia certificada por Google de GBL con tu solución de firma preferida y almacenes la compilación resultante y los metadatos de firma dentro de la partición android_esp_${SLOT_SUFFIX}.
- La firma del OEM NO debe dejar intacto el certificado GBL, y no debe aplicarse ningún encabezado al objeto binario.
- La compilación de GBL para desarrolladores se usa estrictamente para fines de desarrollo y depuración. La compilación no se puede enviar y Google no la certificará.
GBL debe almacenarse en la ruta de acceso /EFI/BOOT/BOOTAA64.EFI dentro de la partición FAT.
Implementa los protocolos UEFI y Android UEFI requeridos para admitir GBL. La compilación de producción de GBL no se inicia si no se admiten estas interfaces.
- EFI_BLOCK_IO_PROTOCOL o EFI_BLOCK_IO2_PROTOCOL recuperan las imágenes de inicio y las imágenes de pvmfw del disco.
- EFI_RNG_PROTOCOL para canarios de pila, semillas de KASLR y semillas de RNG
- Servicios de asignación de memoria para la asignación de memoria temporal para realizar cálculos de AVB y DICE
- EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL proporciona una opción para implementaciones sin operación, pero GBL registra a través de este protocolo de forma predeterminada.
- GBL_EFI_AVB_PROTOCOL accede a las claves públicas y a los índices de rollback para verificar las imágenes de inicio.
- GBL_EFI_BOOT_CONTROL_PROTOCOL adquiere metadatos de ranura y motivos de inicio del firmware.
- GBL_EFI_AVF_PROTOCOL genera datos de configuración de AVF a partir de la cadena DICE.
Los protocolos UEFI que se recomiendan cuando se integra GBL se documentan en Protocolos UEFI de GBL.

Compatibilidad con el firmware de inicio

Con las modificaciones necesarias para admitir los requisitos de la sección anterior, las siguientes implementaciones de firmware UEFI funcionan con GBL:

EDK2 (Tianocore). EDK2 es una implementación popular de UEFI de código abierto. Se necesita compatibilidad con GBL para los bootloaders basados en EDK2, y la compatibilidad con UEFI ya está presente.
U-Boot. Un proyecto de bootloader de código abierto flexible y ampliamente usado que está obteniendo compatibilidad con UEFI para el uso de GBL.
LittleKernel (LK) Un bootloader de código abierto que usan algunos proveedores.

Ejecuta GBL

Puedes obtener un objeto binario de GBL compilado previamente para ejecutarlo o compilar el tuyo y ejecutarlo.

Obtén y ejecuta el objeto binario de GBL

GBL se distribuye como un solo objeto binario de la app UEFI. Puedes actualizar este objeto binario de forma independiente del firmware base del dispositivo con el mecanismo de actualización estándar de Android.

A partir de Android 16, si envías un dispositivo basado en el chipset ARM-64, te recomendamos que implementes la versión más reciente de GBL certificada por Google y la integres en tu cadena de inicio.

Compila GBL

Para compilar GBL, haz lo siguiente:

Verifica que tengas instaladas la herramienta de repo y la herramienta de bootstrap de Bazel:
```
sudo apt install repo bazel-bootstrap
```
Inicializa tu directorio actual para el control de código fuente con el archivo de manifiesto uefi-gbl-mainline:
```
repo init -u https://android.googlesource.com/kernel/manifest -b uefi-gbl-mainline
repo sync -j16
```

Compila la app UEFI:

tools/bazel run //bootable/libbootloader:gbl_efi_dist

Prueba GBL en el dispositivo virtual de Android

Ejecuta GBL en Cuttlefish:
```
cvd start --android_efi_loader=path_to_the_UEFI_app ...
```
En lugar de iniciar Android directamente, este comando cvd start usa la app UEFI para iniciar Android.

Informa errores y comunícate con el equipo del bootloader

Para informar un error de GBL, navega al componente Android Generic Bootloader en Buganizer.

Si tienes preguntas, comunícate con el equipo de GBL y envía un correo electrónico a android-gbl@google.com.