À partir de 2026, pour nous aligner sur notre modèle de développement stable et garantir la stabilité de la plate-forme pour l'écosystème, nous publierons le code source sur AOSP au deuxième et au quatrième trimestre. Pour créer et contribuer à AOSP, nous vous recommandons d'utiliser android-latest-release au lieu de aosp-main. La branche de fichier manifeste android-latest-release fera toujours référence à la version la plus récente envoyée à AOSP. Pour en savoir plus, consultez Modifications apportées à AOSP.

Déployer GBL

Cette page explique comment déployer le fichier binaire Generic Bootloader (GBL).

Exigences concernant le micrologiciel de démarrage

Pour utiliser GBL, le micrologiciel de démarrage doit répondre aux exigences suivantes :

Conformité avec l'UEFI (Unified Extensible Firmware Interface). Le micrologiciel doit implémenter et utiliser les protocoles UEFI requis. Le micrologiciel doit également autoriser les extensions spécifiques au fournisseur à l'aide de protocoles UEFI définis.
Sécurité Le micrologiciel doit implémenter toutes les exigences relatives au démarrage sécurisé Android (AVB), ce qui permet à GBL d'authentifier les images de démarrage.
Modes de démarrage Le binaire doit être capable de gérer différents modes de démarrage, tels que le démarrage normal, le démarrage en mode Recovery et le démarrage en mode Fastboot.
Partitionnement dynamique. Le micrologiciel de démarrage doit implémenter une logique de sélection d'emplacement afin de pouvoir lire le bon emplacement de démarrage A/B et d'être compatible avec les partitions dynamiques et les données utilisateur dans super.
Configuration de l'OS. Le micrologiciel doit être capable de modifier la ligne de commande du noyau, l'arborescence des périphériques (DTB) et la configuration de démarrage avec les personnalisations OEM nécessaires au démarrage de l'appareil.
Chargement de la VM protégée… Le binaire doit charger correctement le micrologiciel de la VM protégée prévalidée avant le noyau Android en présence de VM protégées. Pour en savoir plus, consultez la séquence de démarrage de Microdroid.
Gestion de la mémoire. Le micrologiciel de démarrage doit être compatible avec l'API d'allocation de mémoire UEFI.

Exigences d'implémentation

Pour que GBL soit correctement implémenté sur votre appareil, vous devez répondre aux exigences suivantes :

Votre appareil doit contenir deux partitions FAT32 de 4 Mo (ou plus) nommées android_esp_a et android_esp_b sur un périphérique de bloc accessible par le SOC.
- Un appareil de stockage en mode blocs est un appareil de stockage qui peut être lu ou écrit par unités de blocs. Il peut s'agir, par exemple, d'appareils UFS, eMMC et de cartes SD.
- Le système FAT32 est utilisé, car il s'agit d'un système de fichiers simple et omniprésent.
- Les deux partitions sont requises pour les mises à jour et les retours en arrière Over The Air (OTA) pendant toute la durée de la période d'assistance de cette version d'Android.
- Le fichier GBL non compressé fait environ 2 Mo. 4 Mo suffisent pour tenir compte de toute croissance due à des fonctionnalités supplémentaires au cours des sept prochaines années.
- En cas de mise à jour de la GBL, vous devez mettre à jour l'intégralité de la partition android_esp_${SLOT_SUFFIX}. Une mise à jour GBL uniquement n'est pas compatible avec Android OTA.
Remarque : Nous pouvons exiger des mises à jour majeures de GBL pour les fonctionnalités critiques.
La version de GBL déployée doit être la dernière version de production certifiée de la branche de version GBL correspondante. Nous vous recommandons de signer la copie certifiée par Google de GBL à l'aide de la solution de signature de votre choix, puis de stocker la compilation et les métadonnées de signature résultantes dans la partition android_esp_${SLOT_SUFFIX}.
- Le certificat GBL DOIT être laissé intact par la signature OEM et aucun en-tête ne doit être appliqué au binaire.
- La version GBL pour les développeurs est utilisée strictement à des fins de développement et de débogage. Le build ne peut pas être expédié et ne sera pas certifié par Google.
Le fichier GBL doit être stocké dans le chemin d'accès /EFI/BOOT/BOOTAA64.EFI de la partition FAT32.
Implémentez les protocoles UEFI et Android UEFI requis pour prendre en charge GBL. La compilation de production de GBL ne démarre pas si ces interfaces ne sont pas prises en charge.
- EFI_BLOCK_IO_PROTOCOL ou EFI_BLOCK_IO2_PROTOCOL récupèrent les images de démarrage et les images pvmfw à partir du disque.
- EFI_RNG_PROTOCOL pour les canaris de pile, les valeurs sources KASLR et les valeurs sources RNG
- Services d'allocation de mémoire pour l'allocation de mémoire temporaire afin d'effectuer des calculs AVB et DICE
- EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL fournit une option pour les implémentations no-op, mais GBL enregistre les journaux via ce protocole par défaut.
- GBL_EFI_AVB_PROTOCOL accède aux clés publiques et aux index de restauration pour valider les images de démarrage.
- GBL_EFI_BOOT_CONTROL_PROTOCOL acquiert les métadonnées de l'emplacement et les raisons du démarrage à partir du micrologiciel.
- GBL_EFI_AVF_PROTOCOL génère des données de configuration AVF à partir de la chaîne DICE.
Les protocoles UEFI fortement recommandés lors de l'intégration de GBL sont documentés dans Protocoles UEFI GBL.

Compatibilité avec le micrologiciel de démarrage

Avec les modifications nécessaires pour répondre aux exigences de la section précédente, les implémentations de micrologiciel UEFI suivantes fonctionnent avec GBL :

EDK2 (Tianocore) : EDK2 est une implémentation UEFI Open Source populaire. La compatibilité avec GBL est nécessaire pour les bootloaders basés sur EDK2, et la compatibilité avec UEFI est déjà présente.
U-Boot Projet de bootloader open source flexible et largement utilisé, qui gagne en compatibilité UEFI pour l'utilisation de GBL.
LittleKernel (LK). Chargeur de démarrage Open Source utilisé par certains fournisseurs.

Exécuter GBL

Vous pouvez obtenir un fichier binaire GBL prédéfini à exécuter ou créer le vôtre et l'exécuter.

Obtenir et exécuter le binaire GBL

GBL est distribué sous la forme d'un seul binaire d'application UEFI. Vous pouvez mettre à jour ce binaire indépendamment du micrologiciel de base de l'appareil à l'aide du mécanisme de mise à jour standard d'Android.

À partir d'Android 16, si vous commercialisez un appareil basé sur un chipset ARM-64, nous vous recommandons vivement de déployer la dernière version certifiée par Google de GBL et de l'intégrer à votre chaîne de démarrage.

Compiler le GBL

Pour compiler GBL :

Vérifiez que vous avez installé l'outil repo et le bootstrap Bazel :
```
sudo apt install repo bazel-bootstrap
```
Initialisez votre répertoire actuel pour le contrôle du code source à l'aide du fichier manifeste uefi-gbl-mainline :
```
repo init -u https://android.googlesource.com/kernel/manifest -b uefi-gbl-mainline
repo sync -j16
```

Créez l'application UEFI :

tools/bazel run //bootable/libbootloader:gbl_efi_dist

Tester GBL sur l'appareil virtuel Android

Exécutez GBL dans Cuttlefish :
```
cvd start --android_efi_loader=path_to_the_UEFI_app ...
```
Au lieu de démarrer Android directement, cette commande cvd start utilise l'application UEFI pour démarrer Android.

Signaler des bugs et contacter l'équipe du bootloader

Pour signaler un bug concernant le GBL, accédez au composant Android Generic Bootloader dans Buganizer.

Pour toute question, contactez l'équipe GBL en envoyant un e-mail à l'adresse android-gbl@google.com.