ブートローダーは、次のイメージに依存しています。
ブート。ブートイメージには、未修正の
mkbootimgを使用して、カーネルと RAM ディスクを組み合わされた状態で含める必要があります（実装については、system/core/mkbootimgをご覧ください）。ブートローダーは、mkbootimgによって生成されたbootimg.hヘッダー ファイルを読み取り、カーネルのヘッダーを更新して、RAM ディスクの正確な場所とサイズ、カーネルのベースアドレス、コマンドライン パラメータなどを格納します。続いて、ブートローダーが生成したコマンドラインの末尾に、ブートイメージで指定されたコマンドラインを追加します。カーネル。カーネル イメージは、標準の Linux 形式（
zImage、Image、Image.gzなど）を使用し、独立してフラッシュされるか、RAM ディスク イメージと結合されるか、bootパーティションにフラッシュされるか、またはメモリから起動されます。カーネル イメージを作成する場合、デバイスツリーに別のパーティションを使用するよりも、連結されたデバイスツリー バイナリを使用することをおすすめします。複数のデバイスツリー blob（DTB; device tree blobs）を複数のリビジョンのボードで使用する場合は、ボードのリビジョンの降順に複数の DTB を連結します。RAM ディスク。RAM ディスクのイメージには、
rootfsとしてマウントするのに適したルート ファイル システムを含めます。mkbootfsを使用してカーネル イメージと結合され、ブート パーティションにフラッシュされます。ファイル システム。これらのイメージには
system、userdata、recoveryイメージがあり、Yaffs2 形式またはスパース イメージ形式を使用する必要があります。
イメージの形式
ファイル システム イメージは、Yaffs2 形式またはスパース イメージ形式のいずれかです。
Yaffs2
raw NAND ストレージを使用するデバイスでは、未修正の mkyaffs2image（AOSP 内。external/yaffs2/yaffs2/utils）によって生成された Yaffs2 形式のイメージを使用する必要があります。ブートローダーはこれらのイメージを使用し、yaffs の余分なデータを、指定された NAND ハードウェアの帯域外領域の適切な場所に再配置します。ソフトウェア ECC が必要な場合、ブートローダーはこの時点で計算も行う必要があります。
イメージの形式の詳細については、Yaffs 2 の仕様をご覧ください。
スパース
すべての Android デバイスでスパース イメージ形式がサポートされている必要があります。
詳細については、
system/core/libsparse/sparse_format.hをご覧ください。実装については、
system/core/libsparse/sparse_read.cppをご覧ください。
ブロックベースのストレージを使用するデバイスでは、ext4 または f2fsがサポートされている必要があります。大容量の空の ext4 ファイル システム（userdata など）をすばやく転送してフラッシュするには、ファイル システムの未書き込み領域の情報を含むイメージをスパース形式で格納します。
イメージの形式
スパース イメージ形式には、ファイル ヘッダーが含まれ、一連のチャンクが続きます。ファイル ヘッダー、チャンク ヘッダー、チャンクデータは 4 バイトの倍数で、すべてのフィールドは符号なしリトル エンディアンです。
ファイル ヘッダーの形式は次のとおりです。
- 32 ビットのマジック: 0xed26ff3a
- 16 ビットのメジャー バージョン（0x1） - 上位のメジャー バージョンのイメージを拒否する
- 16 ビットのマイナー バージョン（0x0） - 上位のマイナー バージョンのイメージを許可する
- 16 ビットの、バイト単位のファイル ヘッダーサイズ（v1.0 では 28）
- 16 ビットの、バイト単位のチャンク ヘッダーサイズ（v1.0 では 12）
- 32 ビットの、バイト単位のブロックサイズ（4 の倍数にする必要がある）
- 32 ビットの、出力ファイル内の合計ブロック数
- 32 ビットの、入力ファイル内の合計チャンク数
- 32 ビットの、オリジナル データの CRC32 チェックサムでは、「don't care」を 0 としてカウントします。標準的な 802.3 多項式です（パブリック ドメインのテーブル実装を使用）。
ファイル チャンクは次の形式を使用します。
- 16 ビットのチャンク型:
- 0xCAC1 raw（ブロック単位のサイズ * バイト単位のブロックサイズが後に続く）
- 0xCAC2 fill（4 バイトの fill データが後に続く）
- 0xCAC3 don't care（0 バイトが後に続く）
- 16 ビットは予約済み（0 として書き込み、読み取り時に無視）
- 出力イメージ内の、32 ビットのブロック単位のチャンクサイズ
- チャンク ヘッダーとデータを含む、32 ビットのチャンク入力ファイルの合計サイズ
スパース イメージの作成
mke2fs ユーティリティを使用することで、スパース イメージ形式でイメージを作成できます（これは、ブートローダーが読み取ってフラッシュするイメージの作成に使用されるツールでもあります）。
ライターの実装
mke2fs ユーティリティは、イメージのどの領域に書き込む必要があるかを認識し、それらの領域の間に「don't care」チャンクをエンコードします。もう 1 つのツールである img2simg は、スパース以外のイメージをスパース イメージに変換します。通常のイメージには「don't care」領域に関する情報はありません。変換を行うことで、繰り返しデータのブロックを検索し、最終的なイメージサイズを減らすことができます。
リーダーの実装
リーダーは、不明なメジャー バージョンのイメージを拒否する必要がありますが、不明なマイナー バージョンのイメージは受け入れる必要があります。リーダーは、サポートされていないチャンクサイズのイメージを拒否する場合があります。メジャー バージョンを検証した後、リーダーはタイプ フィールドが不明なチャンクを無視して「chunk size in file」でファイル内のチャンクをスキップし、出力の「chunk size in blocks」ブロックをスキップする必要があります。
ディスクに書き込まれるデータについては、巡回冗長検査（802.3 CRC32）を計算する必要があります。書き込みされていない領域（don't care またはスキップされたチャンク）は、CRC では 0 としてカウントされます。書き込まれた、またはスキップされたブロックの総数は、ヘッダーの「total blocks」フィールドと比較されます。ツール simg2img は、スパース イメージ形式を標準イメージに変換し、これによりスパース情報が失われます。
イメージのフラッシュ
flash コマンドはパーティションを消去しません。ただし、ホストの fastboot ツールが最初に erase コマンドを送信する場合を除きます。このコマンドにより、「スキップ」ブロックで始まる複数のスパース イメージを使用して、複数の小さなチャンクで非常に大きなパーティションをフラッシュし、書き込み済みの領域での検索を実行できるようになります。これらのイメージのオンデマンド作成は、ホスト側の fastboot ツールですでに処理されています。
ロック解除モードでフラッシュする前に、無線イメージとブートローダー イメージでサニティ チェックを行う必要があります。たとえば、ビルドから作成した android-info.txt と比較し、バージョンの一致を確認します。また、ブートローダー イメージの署名をフラッシュ時に確認して、ブート中に検証を通過することを確認します（これには、アンチ ロールバック機能が含まれる場合があります）。
Google ブランドのデバイスでは、最初の商用ブートローダーを含め、古いバージョンのブートローダーへのフラッシュも正常に機能します。fastboot プロトコルの詳細については、system/core/fastboot/README.md をご覧ください。