À 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 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'interface micrologicielle extensible unifiée (UEFI). Le micrologiciel doit implémenter et utiliser les protocoles UEFI requis. Il 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 concernant le démarrage validé Android (AVB), ce qui permet à GBL d'authentifier les images de démarrage.
Modes de démarrage Le binaire doit être en mesure de gérer différents modes de démarrage, tels que le démarrage normal, le démarrage en mode de récupération et le démarrage rapide.
Partitionnement dynamique Le micrologiciel de démarrage doit implémenter une logique de sélection d'emplacement afin de pouvoir lire l'emplacement de démarrage A/B approprié et d'être compatible avec les partitions dynamiques et les données utilisateur dans super.
Configuration de l'OS Le micrologiciel doit être en mesure de modifier la ligne de commande du noyau, l'arborescence des appareils (DTB) et la configuration de démarrage avec les personnalisations OEM nécessaires pour démarrer l'appareil.
Chargement de VM protégées Le binaire doit charger correctement le micrologiciel de VM protégée prévalidé avant le noyau Android en présence de VM protégées. Pour en savoir plus, consultez 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 relatives à l'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 FAT de 8 Mo (ou plus) nommées android_esp_a et android_esp_b sur un appareil de stockage en mode bloc accessible par le SOC.
- Un appareil de stockage en mode bloc est un appareil de stockage qui peut être lu ou écrit en unités de blocs. Par exemple, les appareils UFS, eMMC et les cartes SD.
- Le système FAT est utilisé, car il s'agit d'un système de fichiers omniprésent et simple.
- Nous vous recommandons de choisir le système de fichiers FAT adapté à vos besoins parmi FAT12, FAT16 et FAT32.
- Les deux partitions sont requises pour les mises à jour et les rollbacks OTA (Over-The-Air) pendant la période de prise en charge de cette version d'Android.
- GBL est d'environ 2 Mo non compressés. 8 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 GBL, vous devez mettre à jour l'intégralité de la partition android_esp_${SLOT_SUFFIX}. La mise à jour d'Android OTA ne prend pas en charge la mise à jour de GBL uniquement.
- Le GUID de type de partition utilisé pour les deux partitions FAT doit correspondre au GUID de partition système EFI C12A7328-F81F-11D2-BA4B-00A0C93EC93B.
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 de GBL certifiée par Google à l'aide de la solution de signature de votre choix, puis de stocker la version résultante et les métadonnées de signature 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 du développeur est utilisée strictement à des fins de développement et de débogage. La version ne peut pas être expédiée et ne sera pas certifiée par Google.
GBL doit être stocké dans le chemin d'accès /EFI/BOOT/BOOTAA64.EFI au sein de la partition FAT.
Implémentez les protocoles UEFI et Android UEFI requis pour prendre en charge GBL. La version de production de GBL ne démarre pas si ces interfaces ne sont pas compatibles.
- EFI_BLOCK_IO_PROTOCOL ou EFI_BLOCK_IO2_PROTOCOL récupère 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 se connecte par défaut via ce protocole
- GBL_EFI_AVB_PROTOCOL accède aux clés publiques et aux index de rollback pour valider les images de démarrage
- GBL_EFI_BOOT_CONTROL_PROTOCOL acquiert les métadonnées d'emplacement et les raisons de 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. Un projet de bootloader Open Source flexible et largement utilisé qui gagne en compatibilité UEFI pour l'utilisation de GBL.
LittleKernel (LK). Un bootloader Open Source utilisé par certains fournisseurs.

Exécuter GBL

Vous pouvez obtenir un 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 expédiez un appareil basé sur un chipset ARM-64, nous vous recommandons vivement de déployer la dernière version de GBL certifiée par Google et de l'intégrer à votre chaîne de démarrage.

Créer GBL

Pour créer GBL :

Vérifiez que l'outil repo et le bootstrap Bazel sont installés :
```
sudo apt install repo bazel-bootstrap
```
Initialisez votre répertoire actuel pour le contrôle des sources à 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 GBL, accédez au composant Android Generic Bootloader dans Buganizer.

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