深夜3時、ターミナルに流れる何千行ものログを眺めながら、ビルド進捗が99%で止まり FAILED の文字が表示された時の絶望感を知っているでしょうか？あるいは、数時間かけてコンパイルしたイメージを実機に焼こうとした瞬間、fastboot コマンドがデバイスを認識せず、文鎮化（Brick）の恐怖に襲われた経験は？
Android Open Source Project (AOSP) を扱うということは、単にOSをコンパイルすることではありません。それは、Linuxカーネル、ハードウェア抽象化レイヤー (HAL)、そしてJavaフレームワークの巨大な依存関係を管理する戦いです。本記事では、Ubuntu 22.04 LTS環境上で最新のAndroid 14 (Upside Down Cake) をビルドし、Google Pixel 6 (Oriole) 実機に fastboot を用いて安全にフラッシュするまでの、泥臭くも確実なエンジニアリングプロセスを共有します。
ビルド環境の構築と「隠れた落とし穴」
まず、私がこのプロジェクトで使用したマシンスペックと環境を定義します。AOSPのビルドはリソースを食い尽くします。公式ドキュメントには「最小16GB RAM」とありますが、現実はもっと厳しいものです。
OS: Ubuntu 22.04.3 LTS (WSL2ではなくネイティブ推奨)
CPU: AMD Ryzen 9 5950X (16-core)
RAM: 64GB (Swap 32GB追加)
Storage: 1TB NVMe Gen4 SSD (AOSPソースだけで約250GB消費)
初期セットアップで最も重要なのは、適切なパッケージのインストールとPythonバージョンの管理です。Ubuntu 22.04ではデフォルトのPythonが3.x系ですが、AOSPの一部の古いスクリプト（特に古いブランチを扱う場合）はPython 2系に依存していることがあり、ここで最初のつまづきが発生します。しかし、Android 12以降のマスターブランチではPython 3が標準です。
私は最初、ディスク容量を甘く見ていました。「300GBあれば十分だろう」と考えていましたが、repo sync でソースコードを取得し、フルビルドをかけた時点でアウトプットディレクトリ（out/）が肥大化し、ディスク容量不足でビルドがクラッシュしました。これにより、同期からやり直す羽目になり、約4時間のロスが発生しました。
ドライバーバイナリの罠：なぜ起動しないのか
ビルドが成功しても、実機で起動しない（Bootloopする）最大の原因は、プロプライエタリなドライバーバイナリ（Vendor Image）の欠如です。Google Driver Binaries から、ビルドIDに完全に一致するドライバーをダウンロードし、ソースツリーのルートで展開する必要があります。
ビルド実行とFastbootフラッシュの最適解
環境が整ったら、実際のビルドプロセスに入ります。ここで焦って make を叩いてはいけません。環境変数のセットアップとターゲットの選定（Lunch）が重要です。
// 1. 環境設定スクリプトの読み込み
// これにより、lunchやmコマンドがシェルで使えるようになります
source build/envsetup.sh
// 2. ターゲットの選択
// Pixel 6の場合は 'aosp_oriole-userdebug' を選択
// userdebugはrootアクセスやadbデバッグが可能なエンジニア向けビルドです
lunch aosp_oriole-trunk_staging-userdebug
// 3. ビルドの実行
// -jオプションはCPUスレッド数に合わせて自動調整されますが、
// メモリ不足を防ぐためにあえて制限することもあります
mm コマンドを実行した後、マシンスペックによりますが、1時間〜3時間のコンパイル時間が始まります。この間、CPU使用率は100%に張り付きます。PCがフリーズしたように見えても、バックグラウンドでJavaのプロセス（KotlinコンパイラやJackサーバー）が動いているので、強制終了してはいけません。
Fastbootによる書き込みとトラブルシューティング
ビルドが完了すると、out/target/product/oriole/ ディレクトリに .img ファイル群が生成されます。これらをデバイスに焼くために fastboot を使用しますが、ここが最も緊張する瞬間です。
まず、ブートローダーのアンロックが必要です（開発者向けオプションでOEMロック解除を許可しておくこと）。その後、以下の手順で書き込みます。
// 1. Bootloaderモードへ再起動
adb reboot bootloader
// 2. デバイス認識確認
// ここで何も表示されない場合、udevルールの設定ミスかUSBケーブルの問題です
fastboot devices
// 3. 環境変数の再ロード（新しいターミナルの場合）
// ANDROID_PRODUCT_OUT が設定されていないとエラーになります
source build/envsetup.sh
lunch aosp_oriole-trunk_staging-userdebug
// 4. イメージの一括書き込み
// -w オプションはユーザーデータをワイプ（初期化）します。
// 初回起動時やメジャーバージョンアップ時は必須です。
fastboot flashall -wfastboot flashall は非常に強力ですが、環境変数 ANDROID_PRODUCT_OUT に依存しています。もし「could not find images」というエラーが出た場合は、直前に lunch コマンドを実行したか確認してください。
また、Linuxユーザーが頻繁に遭遇するのが no permissions エラーです。これは fastboot コマンドを実行するユーザーにUSBデバイスへのアクセス権がないためです。一時的な解決策として sudo fastboot ... を使う手もありますが、推奨されません。正しい解決策は /etc/udev/rules.d/51-android.rules を設定することです。
| 現象 (Symptom) | 原因 (Root Cause) | 対策 (Solution) |
|---|---|---|
| waiting for device | USBケーブル不良 / udev未設定 | 高品質ケーブルへの交換 / udevルールの追加 |
| FAILED (remote: Not allowed to flash) | Bootloaderがロックされている | fastboot flashing unlock を実行 |
| System UI isn't responding | Vendorイメージの不一致 | ビルドIDに合ったドライバを再抽出してリビルド |
上記の表は、私が過去のプロジェクトで遭遇した主要なエラーとその解決策です。特にPixel 6以降、Google独自のTensorチップセットに関連するセキュリティ要件が厳しくなっており、古いFastbootツールを使用していると書き込みに失敗することがあります。常に platform-tools は最新版を維持してください。
エッジケースと運用上の注意点
カスタムROM開発における「エッジケース」は、デバイス固有のパーティション構成に起因することが多いです。例えば、最近のAndroidデバイスは A/B パーティション（Seamless Update）を採用しています。fastboot で特定のパーティションを手動で焼く場合、--slot all や --slot other を指定しないと、アクティブでないスロットに書き込んでしまい、再起動しても変更が反映されないという事態に陥ります。
また、Windows環境でWSL2を使用してAOSPをビルドしようとする試みは、USBデバイスのパススルー設定（USBIPD）が非常に不安定であるため、私は強く推奨しません。ネイティブのLinux環境、あるいはmacOS環境を用意することが、精神衛生上もプロジェクトの成功率向上にも不可欠です。
結論
AOSPのビルドと fastboot による書き込みは、Androidエコシステムの深淵を覗く行為です。初期設定の複雑さやビルド時間の長さ、そして些細なバージョン不整合によるブート失敗など、多くの障壁があります。しかし、自分でビルドしたOSが画面に表示され、Googleロゴが現れた瞬間の達成感は、エンジニアにとって何物にも代えがたいものです。
この記事で紹介した環境構築の手順、ドライバー管理の重要性、そしてエラーログの読み方を理解すれば、独自のカスタム機能を追加したAndroid OSを世界に公開する第一歩を踏み出せるはずです。文鎮化を恐れず、バックアップを取った上で、ぜひ挑戦してみてください。
Post a Comment