B2G OSのビルド過程の概要

B2G OSをビルド、インストールすることは特にたくさんの時間、ネットワーク帯域、演算能力が必要になります。その上、不幸なことに、失敗してしまう傾向もあります。このページはビルド過程の目標を概説した後、個々の過程の中のステップを概説し、ユーザがやり方に添って行えることを意図します。それぞれのステップの詳細はリンク先のページで議論します。

記: B2G OSのビルド過程は'B2G'または'Boot2Gecko'の全リファレンスです。'Boot2Gecko'は元々B2G OSプロジェクトのコードネームでした。

ビルドの目標: 3つの'image'ファイル

ビルド過程の最上位の目標は、B2G OS互換の端末にインストールできる3つのファイルを作ることです。

boot.img	Linuxカーネルとルートファイルシステムのイメージで、後者は基本的なUnixツールの使用可能なセットを提供します。
system.img	Gonkの一部、移植されたGecko、そしてb2g実行環境を含むB2G OSのコア（中心）です。
recovery.img	Linuxカーネルとルートファイルシステムのイメージの他、ユーザが間違ったインストールを修復できるような簡易ツールです。

3つのイメージが出来次第、端末にインストールできます。

B2G OS は Android Open Source Project (AOSP) の上に構築されています。AOSP のツールである adb と fastboot は端末にアクセスするための強力な手段を提供します。とりわけ adb reboot-bootloader のコマンドは接続された端末をリブートさせブートローダの初期段階で一時停止させることができます。そして fastboot flash $partition $image でイメージを端末へコピーすることができます。

ブートイメージ

ブートイメージ(boot.img) は Linuxカーネルと、初期化スクリプト・コアユーティリティソフトウエアを提供するルートパーティションの組み合わせです。後者は端末によって効率的に使用するため "ramdisk" と呼ばれる端末メモリへコピーされます。ブートイメージは端末上の 'boot' パーティションにコピーされ、adb shell 等の実行によって端末のファイルシステムがアクセスされる時、ramdisk の内容がルートディレクトリに反映されはじめます。

ブートイメージは、ルートディレクトリ上の default.prop ファイル内のルートユーザのパーミッションを設定します。

ブートイメージは kernel と ramdiskイメージに分割してramdiskイメージの内容を抽出し、修正することが可能です。修正後、ramdiskイメージを再組み立てして boot.img を再構築することで既存のブートイメージを変更することができます。たとえば Alcatel One Touch Fire Hacking (Mini) Guide が参考になります。

ブートイメージは 'サイドローディング' によってインストール前にテストできます。端末が起動してブートローダで一時停止させた後、fastbootで次のようなコマンドを用いて、インストールすることなくブートイメージを使用することができます。
fastboot boot /some/path/to/boot.img

システムイメージ

システムイメージ(system.img)は、B2G OSのコア部分を提供します:

Gonk: OSの低レベルコンポーネント
Gecko: B2GのHTML表示とJavaScriptエンジンの移植
B2G: OSのコアとなる実行プロセス
Gaia: ユーザが利用できる web アプリケーション

プラットフォームアーキテクチャについてはB2G OS プラットフォームに詳しい情報があります。

システムイメージは端末上のsystemパーティションへコピーされ、端末のファイルシステムが実行時にアクセスされる時には/system/ディレクトリとして可視化されます。

記: システムイメージは端末によって使用されるバイナリーブロブを提供します。特にRIL (Radio Interface Layer) ブロブは端末のセルラー電波を制御します。

リカバリイメージ

リカバリイメージ (recovery.img) にはブートイメージパーティションに存在するのと同じカーネルとramdiskが含まれます。しかしながらリカバリイメージは異なる初期化スクリプトを使用し、それによって、ユーザは端末のハードウェアボタンを用いてリカバリコマンドにアクセスできます。

リカバリイメージは端末のrecoveryパーティションへコピーされ、通常実行時にはマウントされません。

ビルドの過程: セットアップ・構成・ビルド・インストール

B2G OSをビルド、インストールする最上位プロセスは、4つのステップを含みます:

セットアップ	ビルドプロセスで使われる全プログラム、例えば適切なコンパイラやライブラリ、のコピーを取得します。
構成	ビルドされるソースコードをダウンロードし、ビルド時に使われるパスや他の値を指定する環境変数を定義する `.configure` ファイルを作成します。
ビルド	ユーザのGeckoプロファイルや、端末用のGaia webアプリケーションをビルドします。
インストール	端末にファイルをインストールします。

セットアップ

ビルドの最中に必要となる全部のソフトウェアが実行されているということをコンパイラに保証するために、最初のセットアップは必ず完了させます。

このステップは手動でもスクリプトでも行うことができます。詳細は B2G OSビルドの必要条件ページで議論されています。

記: UNIXやUNIXライクなマシンでは、unixコマンドの which にプログラム名をパラメータに付けることで必要なソフトウェアをチェックできます。

構成

実際のビルドプロセスは、B2G OS (またはB2G)ソフトウェアを取得することから始まります。通常それはB2GプロジェクトのGitクローンを作成することです。ビルド構成では、ビルドする全てのソースコード取得と、ビルド用の変数を指定する.configファイル作成との両方を行います。

これはconfig.shスクリプトで実行されます。詳細は初回 B2G ビルドの準備ページで議論されています。

構成スクリプトは、ビルドする端末タイプを指定するパラメータが必要です。ビルド名は特定端末よりは、CPUアーキテクチャに関連したコード名です。現状はどの物理端末にどのビルドが動作するかを確立する方法はありません。利用できるコード名一覧はこちらにあります。

構成ステップでは ASOP の repo ツールもまた、ビルドで使う全コードのコピーをダウンロード(または更新)するために使われます。こうしたコピーは .repo/projects ディレクトリに保管されます。この動作のため、構成ステップでは多くの時間と、大量のデータダウンロードが発生することがあります。

ビルド

ビルドステップでは実際にソースコードをコンパイルして出力イメージを作成します。

これはbuild.shスクリプトで実行されます。詳細はB2G OSのビルドページで議論されています。

デフォルトでは、ビルドステップはモノリシックで、ASOPツールからLinux kernelやGaia webアプリケーションをまで一度にビルドしようとします。ビルドが失敗すると、どのステップが失敗したのか不明なことが時々あります。

全B2Gスタックの一部をビルドすることが可能です。例えばgeckoパラメータをつけてビルドすることで、Geckoシステムのみをビルドできます。同様に、Gaiaだけビルドするのにgaiaパラメータを使用します。次に説明するように、これらの部品は端末に別々にインストールされます。

このページの最初で述べたようなイメージをビルドすることも可能です。例えば./build.sh out/platform/$target/system.img でシステムイメージをビルドでき、ここで $target パラメータは構成ステップと同様になります。

インストール

インストールステップでは新しくコンパイルされたコードを端末に配置します。これはflash.shスクリプトで実行されます。

flash スクリプトにパラメータをつけることで個々のビルド部品をインストールできます。例えばGaia webアプリケーションは./flash.sh gaiaと指定することで単独でインストールできます。