Starting March 27, 2025, we recommend using android-latest-release instead of aosp-main to build and contribute to AOSP. For more information, see Changes to AOSP.
Stay organized with collections
Save and categorize content based on your preferences.
This page explains how to deploy the GBL binary.
Boot firmware requirements
To use GBL, the boot firmware must meet the following requirements:
UEFI compliance. The firmware must implement and use the
required UEFI protocols. The firmware must also allow for vendor-specific
extensions using defined UEFI protocols.
Security. The firmware must implement all aspects of Android
Verified Boot (AVB), ensuring only authenticated images are loaded.
Boot modes. The binary should be able to handle various boot modes, such as normal boot, recovery boot, and fastboot.
Dynamic partitioning. The boot firmware must implement slot selection logic so
that it supports reading the correct A/B boot slot and is compatible with
dynamic partitions and userdata in super.
OS configuration. The firmware must be capable of modifying the kernel
command line, device tree (DTB), and bootconfig with OEM customizations
needed to boot the device.
Protected VM loading. The binary should correctly load preverified protected
VM firmware before the Android kernel in the presence of protected VMs. For
further information, see Microdroid boot sequence.
Memory management. The boot firmware must support the UEFI memory allocation
API.
Compatibility and backward compatibility. The firmware should work on devices
with different vendor, SOCs, and maintain backward compatibility with the
corresponding Android version.
Boot firmware support
With the modifications necessary to support requirements in the previous
section, the following UEFI firmware implementations work with the GBF:
EDK2 (Tianocore). A EDK2 is a popular
open-source UEFI implementation. GBL support is needed for EDK2-based
bootloaders, and UEFI support is already present.
U-Boot. A flexible and widely used
open-source bootloader project that is gaining UEFI compatibility for GBL usage.
You can obtain a prebuilt GBL binary to run or build your own and run it.
Obtain and run the GBL binary
GBL is distributed as a single EFI app binary. You can update this
binary independently from the device's base firmware using Android's standard
update mechanism.
Beginning with Android 16, if you ship a device based
on ARM-64 chipset, we strongly recommend that you deploy the latest
Google-signed version of GBL and integrate it into your boot chain.
Build and run the GBL
To build and run the GBL:
Verify that you have the repo tool and Bazel bootstrap installed:
sudo apt install repo bazel-bootstrap
Initialize your current directory for source control using the uefi-gbl-mainline manifest file:
For questions, contact the GBL team, send an email to android-gbl@google.com.
Content and code samples on this page are subject to the licenses described in the Content License. Java and OpenJDK are trademarks or registered trademarks of Oracle and/or its affiliates.
Last updated 2025-08-29 UTC.
[null,null,["Last updated 2025-08-29 UTC."],[],[],null,["# Deploy GBL\n\nThis page explains how to deploy the GBL binary.\n\nBoot firmware requirements\n--------------------------\n\nTo use GBL, the boot firmware must meet the following requirements:\n\n- UEFI compliance. The firmware must implement and use the\n required UEFI protocols. The firmware must also allow for vendor-specific\n extensions using defined UEFI protocols.\n\n- Security. The firmware must implement all aspects of Android\n Verified Boot (AVB), ensuring only authenticated images are loaded.\n\n- Boot modes. The binary should be able to handle various boot modes, such as normal boot, recovery boot, and fastboot.\n\n- Dynamic partitioning. The boot firmware must implement slot selection logic so\n that it supports reading the correct A/B boot slot and is compatible with\n dynamic partitions and userdata in super.\n\n- OS configuration. The firmware must be capable of modifying the kernel\n command line, device tree (DTB), and bootconfig with OEM customizations\n needed to boot the device.\n\n- Protected VM loading. The binary should correctly load preverified protected\n VM firmware before the Android kernel in the presence of protected VMs. For\n further information, see Microdroid [boot sequence](/docs/core/virtualization/microdroid#boot-sequence).\n\n- Memory management. The boot firmware must support the UEFI memory allocation\n API.\n\n- Compatibility and backward compatibility. The firmware should work on devices\n with different vendor, SOCs, and maintain backward compatibility with the\n corresponding Android version.\n\n### Boot firmware support\n\nWith the modifications necessary to support requirements in the previous\nsection, the following UEFI firmware implementations work with the GBF:\n\n- [EDK2 (Tianocore)](https://github.com/tianocore/edk). A EDK2 is a popular open-source UEFI implementation. GBL support is needed for EDK2-based bootloaders, and UEFI support is already present.\n- [U-Boot](https://docs.u-boot.org/en/latest/). A flexible and widely used open-source bootloader project that is gaining UEFI compatibility for GBL usage.\n- [LittleKernel (LK)](https://github.com/littlekernel/lk). An open-source bootloader used by some vendors.\n\nRun GBL\n-------\n\nYou can obtain a prebuilt GBL binary to run or build your own and run it.\n\n### Obtain and run the GBL binary\n\nGBL is distributed as a single EFI app binary. You can update this\nbinary independently from the device's base firmware using Android's standard\nupdate mechanism.\n\nBeginning with Android 16, if you ship a device based\non ARM-64 chipset, we strongly recommend that you deploy the [latest\nGoogle-signed version](https://dl.google.com/android-gbl/android16/20250703/signed-gbl-img-13709664.zip) of GBL and integrate it into your boot chain.\n\n### Build and run the GBL\n\nTo build and run the GBL:\n\n1. Verify that you have the repo tool and Bazel bootstrap installed:\n\n sudo apt install repo bazel-bootstrap\n\n2. Initialize your current directory for source control using the `uefi-gbl-mainline` manifest file:\n\n repo init -u https://android.googlesource.com/kernel/manifest -b uefi-gbl-mainline\n repo sync -j16\n\n3. Build the EFI app:\n\n ./tools/bazel run //bootable/libbootloader:gbl_efi_dist --extra_toolchains=@gbl//toolchain:all\n\n4. Run the EFI app within Cuttlefish:\n\n cvd start --android_efi_loader=\u003cvar translate=\"no\"\u003e\u003cspan class=\"devsite-syntax-n\"\u003epath_to_the_EFI_app\u003c/span\u003e\u003c/var\u003e ...\n\n Instead of booting Android directly, this `cvd start` command uses the EFI\n app to boot Android.\n\n| **Note:** For x86 platform, use the EFI image built for x86_64.\n\nFile bugs and contact the bootloader team\n-----------------------------------------\n\nTo report a bug for the GBL, navigate to the\n[Android Generic Bootloader component in Buganizer](https://issuetracker.google.com/issues/new?component=1602063&template=2011730).\n\nFor questions, contact the GBL team, send an email to `android-gbl@google.com`."]]
