Ab 2026 werden wir den Quellcode im 2. und 4. Quartal in AOSP veröffentlichen, um unser trunk-stable-Entwicklungsmodell zu unterstützen und die Plattformstabilität für das Ökosystem zu gewährleisten. Für die Entwicklung und das Beitragen zu AOSP empfehlen wir die Verwendung von android-latest-release anstelle von aosp-main. Der Manifestzweig android-latest-release verweist immer auf das neueste Release, das an AOSP übertragen wurde. Weitere Informationen finden Sie unter Änderungen an AOSP.

GBL bereitstellen

Auf dieser Seite wird beschrieben, wie Sie die Binärdatei des generischen Bootloaders (Generic Bootloader, GBL) bereitstellen.

Anforderungen an die Boot-Firmware

Damit GBL verwendet werden kann, muss die Boot-Firmware die folgenden Anforderungen erfüllen:

UEFI-Konformität (Unified Extensible Firmware Interface). Die Firmware muss die erforderlichen UEFI-Protokolle implementieren und verwenden. Die Firmware muss auch herstellerspezifische Erweiterungen über definierte UEFI-Protokolle ermöglichen.
Sicherheit Die Firmware muss alle Anforderungen für Android Verified Boot (AVB) erfüllen, damit GBL Boot-Images authentifizieren kann.
Bootmodi Das Binärprogramm muss verschiedene Startmodi unterstützen, z. B. Normalstart, Wiederherstellungsstart und Fastboot.
Dynamische Partitionierung. Die Boot-Firmware muss eine Logik zur Auswahl von Slots implementieren, damit der richtige A/B-Boot-Slot gelesen werden kann und sie mit dynamischen Partitionen und Nutzerdaten in „super“ kompatibel ist.
Betriebssystemkonfiguration Die Firmware muss in der Lage sein, die Kernel-Befehlszeile, den Gerätebaum (Device Tree, DTB) und die Bootkonfiguration mit OEM-Anpassungen zu ändern, die zum Starten des Geräts erforderlich sind.
Geschützte VM wird geladen. Das Binärprogramm sollte die vorab bestätigte geschützte VM-Firmware korrekt laden, bevor der Android-Kernel bei Vorhandensein geschützter VMs geladen wird. Weitere Informationen finden Sie unter Boot-Sequenz für Microdroid.
Speicherverwaltung Die Boot-Firmware muss die UEFI-API für die Speicherzuweisung unterstützen.

Implementierungsanforderungen

Damit GBL auf Ihrem Gerät korrekt implementiert werden kann, müssen Sie die folgenden Anforderungen erfüllen:

Ihr Gerät muss zwei FAT32-Partitionen mit einer Größe von mindestens 4 MB enthalten, die auf einem vom SOC zugänglichen Blockgerät die Namen android_esp_a und android_esp_b haben.
- Ein Blockgerät ist ein Speichergerät, von dem in Einheiten von Blöcken gelesen oder auf das in Einheiten von Blöcken geschrieben werden kann. Beispiele sind UFS-, eMMC- und SD-Karten.
- FAT32 wird verwendet, weil es ein weitverbreitetes und unkompliziertes Dateisystem ist.
- Beide Partitionen sind für OTA-Updates und Rollbacks während des Supportzeitraums dieser Android-Version erforderlich.
- Die GBL-Datei ist unkomprimiert etwa 2 MB groß. 4 MB reichen aus, um das Wachstum aufgrund zusätzlicher Funktionen in den nächsten sieben Jahren zu berücksichtigen.
- Bei einer GBL-Aktualisierung müssen Sie die gesamte android_esp_${SLOT_SUFFIX}-Partition aktualisieren. Ein reines GBL-Update wird von Android OTA nicht unterstützt.
Hinweis: Möglicherweise sind größere Updates für GBL für wichtige Funktionen erforderlich.
Die bereitgestellte Version von GBL muss der aktuelle zertifizierte Produktions-Build aus dem entsprechenden GBL-Release-Branch sein. Wir empfehlen, die von Google zertifizierte Kopie von GBL mit Ihrer bevorzugten Signaturlösung zu signieren und den resultierenden Build und die Signaturmetadaten in der android_esp_${SLOT_SUFFIX}-Partition zu speichern.
- Das GBL-Zertifikat MUSS durch die OEM-Signatur intakt bleiben UND es darf kein Header auf das Binärprogramm angewendet werden.
- Der GBL-Build für Entwickler wird ausschließlich für Entwicklungs- und Debugging-Zwecke verwendet. Der Build kann nicht ausgeliefert werden und wird nicht von Google zertifiziert.
Die GBL muss auf der FAT32-Partition unter dem Pfad /EFI/BOOT/BOOTAA64.EFI gespeichert werden.
Implementieren Sie die erforderlichen UEFI- und Android-UEFI-Protokolle, um GBL zu unterstützen. Der Produktions-Build von GBL kann nicht gestartet werden, wenn diese Schnittstellen nicht unterstützt werden.
- EFI_BLOCK_IO_PROTOCOL oder EFI_BLOCK_IO2_PROTOCOL ruft die Boot-Images und pvmfw-Images von der Festplatte ab.
- EFI_RNG_PROTOCOL für Stack-Canaries, KASLR-Seeds und RNG-Seeds
- Memory Allocation Services für die Zuweisung von Scratch-Arbeitsspeicher für AVB- und DICE-Berechnungen
- EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL bietet eine Option für No-Op-Implementierungen, aber GBL protokolliert standardmäßig über dieses Protokoll.
- GBL_EFI_AVB_PROTOCOL greift auf öffentliche Schlüssel und Rollback-Indizes zu, um Boot-Images zu überprüfen.
- GBL_EFI_BOOT_CONTROL_PROTOCOL ruft Slot-Metadaten und Boot-Gründe aus der Firmware ab.
- GBL_EFI_AVF_PROTOCOL generiert AVF-Konfigurationsdaten aus der DICE-Kette.
Die UEFI-Protokolle, die bei der Integration von GBL dringend empfohlen werden, sind in GBL UEFI Protocols dokumentiert.

Unterstützung der Boot-Firmware

Mit den erforderlichen Änderungen zur Unterstützung der Anforderungen im vorherigen Abschnitt funktionieren die folgenden UEFI-Firmware-Implementierungen mit GBL:

EDK2 (Tianocore): EDK2 ist eine beliebte Open-Source-UEFI-Implementierung. GBL-Unterstützung ist für EDK2-basierte Bootloader erforderlich und UEFI-Unterstützung ist bereits vorhanden.
U-Boot. Ein flexibles und weit verbreitetes Open-Source-Bootloader-Projekt, das UEFI-Kompatibilität für die GBL-Nutzung erhält.
LittleKernel (LK). Ein Open-Source-Bootloader, der von einigen Anbietern verwendet wird.

GBL ausführen

Sie können ein vorgefertigtes GBL-Binärprogramm abrufen, um es auszuführen, oder ein eigenes erstellen und ausführen.

GBL-Binärdatei abrufen und ausführen

GBL wird als einzelne UEFI-App-Binärdatei bereitgestellt. Sie können dieses Binärprogramm unabhängig von der Basis-Firmware des Geräts über den standardmäßigen Android-Aktualisierungsmechanismus aktualisieren.

Wenn Sie ein Gerät mit einem ARM-64-Chipsatz ausliefern, empfehlen wir dringend, ab Android 16 die neueste von Google zertifizierte Version von GBL bereitzustellen und in Ihre Boot-Chain zu integrieren.

GBL erstellen

So erstellen Sie GBL:

Prüfen Sie, ob das Repo-Tool und Bazel Bootstrap installiert sind:
```
sudo apt install repo bazel-bootstrap
```
Initialisieren Sie Ihr aktuelles Verzeichnis für die Quellcodeverwaltung mit der Manifestdatei uefi-gbl-mainline:
```
repo init -u https://android.googlesource.com/kernel/manifest -b uefi-gbl-mainline
repo sync -j16
```

UEFI-App erstellen:

tools/bazel run //bootable/libbootloader:gbl_efi_dist

GBL auf dem virtuellen Android-Gerät testen

GBL in Cuttlefish ausführen:
```
cvd start --android_efi_loader=path_to_the_UEFI_app ...
```
Anstatt Android direkt zu starten, verwendet dieser cvd start-Befehl die UEFI-App, um Android zu starten.

Fehler melden und das Bootloader-Team kontaktieren

Wenn Sie einen Fehler für den GBL melden möchten, rufen Sie die Android Generic Bootloader-Komponente in Buganizer auf.

Wenn Sie Fragen haben, wenden Sie sich an das GBL-Team. Senden Sie dazu eine E-Mail an android-gbl@google.com.