2026 年より、トランク安定版開発モデルに沿ってエコシステムのプラットフォームの安定性を確保するため、第 2 四半期と第 4 四半期に AOSP にソースコードを公開します。AOSP のビルドとコントリビューションには、aosp-main ではなく android-latest-release を使用することをおすすめします。android-latest-release マニフェストブランチは、常に AOSP にプッシュされた最新のリリースを参照します。詳細については、AOSP の変更点をご覧ください。

GBL をデプロイする

このページでは、汎用ブートローダー（GBL）バイナリをデプロイする方法について説明します。

ブートファームウェアの要件

GBL を使用するには、ブートファームウェアが次の要件を満たしている必要があります。

Unified Extensible Firmware Interface（UEFI）への準拠。ファームウェアは、必要な UEFI プロトコルを実装して使用する必要があります。ファームウェアは、定義された UEFI プロトコルを使用したベンダー固有の拡張機能も許可する必要があります。
セキュリティ。ファームウェアは、Android 確認付きブート（AVB）のすべての要件を実装し、GBL がブートイメージを認証できるようにしなければなりません。
起動モード。バイナリは、通常の起動、リカバリ起動、Fastboot など、さまざまな起動モードを処理できる必要があります。
動的パーティショニング。ブートファームウェアは、正しい A/B ブートスロットの読み取りをサポートし、スーパー内の動的パーティションと userdata と互換性があるように、スロット選択ロジックを実装しなければなりません。
OS 構成。ファームウェアは、デバイスの起動に必要な OEM カスタマイズでカーネルコマンドライン、デバイスツリー（DTB）、bootconfig を変更できる必要があります。
保護された VM の読み込み。バイナリは、保護された VM が存在する場合、Android カーネルの前に事前検証済みの保護された VM ファームウェアを正しく読み込む必要があります。詳細については、Microdroid のブートシーケンスをご覧ください。
メモリ管理。ブートファームウェアは、UEFI メモリ割り当て API をサポートする必要があります。

実装の要件

デバイスで GBL を正しく実装するには、次の要件を満たす必要があります。

デバイスは、SOC からアクセス可能なブロックデバイス上に、android_esp_a と android_esp_b という名前の 4 MB（以上）の FAT32 パーティションを 2 つ含まなければなりません。
- ブロックデバイスは、ブロック単位で読み取りまたは書き込みが可能なストレージデバイスです。たとえば、UFS、eMMC、SD カードデバイスなどがあります。
- FAT32 は、ユビキタスでシンプルなファイルシステムであるため使用されます。
- 両方のパーティションは、この Android バージョンのサポート期間中の無線（OTA）アップデートとロールバックに必要です。
- GBL は非圧縮で約 2 MB です。4 MB は、今後 7 年間にわたって追加機能による増加を考慮するのに十分なサイズです。
- GBL の更新が発生した場合は、android_esp_${SLOT_SUFFIX} パーティション全体を更新する必要があります。Android OTA では GBL のみのアップデートはサポートされていません。
注: 重要な機能については、GBL のメジャーアップデートが必要になる場合があります。
デプロイされる GBL のバージョンは、対応する GBL リリースブランチの最新の認定済み本番環境ビルドでなければなりません。お好みの署名ソリューションを使用して GBL の Google 認定コピーに署名し、結果として得られたビルドと署名メタデータを android_esp_${SLOT_SUFFIX} パーティション内に保存することをおすすめします。
- GBL 証明書は OEM 署名によってそのまま残されなければならず、バイナリにヘッダーが適用されていてはなりません。
- デベロッパー GBL ビルドは、開発とデバッグのみを目的として使用されます。このビルドは出荷できず、Google の認定も受けられません。
GBL は、FAT32 パーティション内のパス /EFI/BOOT/BOOTAA64.EFI に保存する必要があります。
GBL をサポートするために、必要な UEFI プロトコルと Android UEFI プロトコルを実装します。これらのインターフェースがサポートされていない場合、GBL の本番環境ビルドは起動に失敗します。
- EFI_BLOCK_IO_PROTOCOL または EFI_BLOCK_IO2_PROTOCOL は、ブートイメージと pvmfw イメージをディスクから取得します。
- スタックカナリア、KASLR シード、RNG シードの EFI_RNG_PROTOCOL
- AVB と DICE の計算を行うためのスクラッチメモリの割り当てを行うメモリ割り当てサービス
- EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL は no-op 実装のオプションを提供しますが、GBL はデフォルトでこのプロトコルを介してログを記録します。
- GBL_EFI_AVB_PROTOCOL は、ブートイメージを検証するために公開鍵とロールバックインデックスにアクセスします
- GBL_EFI_BOOT_CONTROL_PROTOCOL は、ファームウェアからスロットメタデータと起動理由を取得します。
- GBL_EFI_AVF_PROTOCOL は DICE チェーンから AVF 構成データを生成します
GBL を統合する際に強く推奨される UEFI プロトコルについては、GBL UEFI プロトコルで説明しています。

ブートファームウェアのサポート

前のセクションの要件をサポートするために必要な変更を加えると、次の UEFI ファームウェア実装は GBL で動作します。

EDK2（Tianocore）。EDK2 は、人気のオープンソース UEFI 実装です。EDK2 ベースのブートローダーには GBL サポートが必要ですが、UEFI サポートはすでに存在します。
U-Boot。柔軟で広く使用されているオープンソースのブートローダープロジェクト。GBL での使用に向けて UEFI 互換性を獲得しています。
LittleKernel（LK）。一部のベンダーで使用されているオープンソースのブートローダー。

GBL を実行する

事前構築済みの GBL バイナリを取得して実行することも、独自にビルドして実行することもできます。

GBL バイナリを取得して実行する

GBL は単一の UEFI アプリバイナリとして配布されます。このバイナリは、Android の標準の更新メカニズムを使用して、デバイスのベースファームウェアとは別に更新できます。

Android 16 以降で ARM-64 チップセットをベースにしたデバイスをリリースする場合、Google 認定の最新バージョンの GBL をデプロイし、起動チェーンに統合することを強く推奨します。

GBL をビルドする

GBL をビルドするには:

repo ツールと Bazel ブートストラップがインストールされていることを確認します。
```
sudo apt install repo bazel-bootstrap
```
uefi-gbl-mainline マニフェストファイルを使用して、ソースコントロールの現在のディレクトリを初期化します。
```
repo init -u https://android.googlesource.com/kernel/manifest -b uefi-gbl-mainline
repo sync -j16
```

UEFI アプリをビルドします。

tools/bazel run //bootable/libbootloader:gbl_efi_dist

Android Virtual Device で GBL をテストする

Cuttlefish 内で GBL を実行します。
```
cvd start --android_efi_loader=path_to_the_UEFI_app ...
```
この cvd start コマンドは、Android を直接起動するのではなく、UEFI アプリを使用して Android を起動します。

バグを報告してブートローダーチームに連絡する

GBL のバグを報告するには、Buganizer の Android 汎用ブートローダーコンポーネントに移動します。

ご不明な点がございましたら、GBL チーム（android-gbl@google.com）にお問い合わせください。