À 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 dans AOSP, utilisez android-latest-release. 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.

Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

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.
ou de la sécurité. Le micrologiciel doit implémenter toutes les exigences relatives au démarrage validé Android (AVB), ce qui permet à GBL d'authentifier les images de démarrage.
Modes de démarrage Le binaire doit pouvoir 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 FAT de 8 Mo (ou plus) nommées android_esp_a et android_esp_b sur un périphérique de stockage en mode bloc accessible par le SOC.
- Un périphérique de stockage en mode blocs est un périphérique 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 FAT est utilisé, car il s'agit d'un système de fichiers simple et omniprésent.
- Nous vous recommandons de choisir le système de fichiers FAT qui correspond à vos besoins parmi FAT12, FAT16 et FAT32.
- Les deux partitions sont requises pour les mises à jour et les retours en arrière OTA (Over-The-Air) 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. 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 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.
- 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 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 strictement réservée au développement et au débogage. La version ne peut pas être expédiée et ne sera pas certifiée par Google.
Le fichier GBL doit être stocké dans le chemin d'accès /EFI/BOOT/BOOTAA64.EFI de la partition FAT.
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 redémarrage à partir du micrologiciel.
- GBL_EFI_AVF_PROTOCOL génère des données de configuration AVF à partir de la chaîne DICE.
Le micrologiciel doit fournir des variables UEFI à GBL. Ces variables doivent être définies avec la valeur GBL_EFI_VENDOR_GUID 5a6d92f3-a2d0-4083-91a1-a50f6c3d9830.
- gbl_fw_api_level doit être défini sur le niveau d'API du micrologiciel de la plate-forme, ce qui indique le niveau d'API du logiciel du fournisseur. Cette variable doit avoir la même valeur que la propriété système ro.board.api_level.
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.

Pour déboguer cette compilation GBL, vous pouvez télécharger l'un de ces artefacts pour vous aider à déboguer :

La table des symboles utilise un débogueur matériel et GDB pour la version GBL certifiée par Google.
Le manifeste apporte des modifications à la version signée en recréant cette version GBL à partir de la source à l'aide de repo.
La version développeur GBL correspondante est utile pour le démarrage ou pour un débogage moins sophistiqué d'un problème ayant un impact sur la version de production signée.
La table des symboles est utile pour la version développeur GBL avec un débogueur matériel et GDB.

Pour afficher les binaires et les symboles certifiés pour toutes les versions, consultez Versions GBL.

Créer un GBL

Pour compiler 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 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.