Android init

BeagleBoard-xMの起動はイカのようになっています。

1. CPUがROM内のブートコードを使って起動
2. ROMのローダーがmicroSD内のMLOファイルを読み込みその中のX-LoaderをSoC内のRAMに展開して実行
3. X-LoaderがmicroSD内のu-bootを起動
4. u-boot が 最低限のデバイスを初期化後、uImageをRAMに展開、カーネルを起動
5. カーネルが各種デバイスを初期化後、init を起動

ここまでの挙動は、BeagleBoard-xMの固有の動作であり、アーキテクチャやボードによって異なります。

Linux カーネルが最初に起動するプロセスは init という名前のプロセスですが、一般のLinuxディストリビューションで採用されている init と動作が大きく異なります。

Androidのinitプロセスの役割は、大きく分けて二つあります。

• Boot処理部
• Daemon処理部

Boot処理部は、必要なディレクトリの生成後、rcファイルをパースしてそこに登録された処理を実行していきます。

• init.rc
• init.<hardware>.rc

その後Daemon処理部に移ると、3種類のevent用fdをpollしながら電源断までイベント処理を続けます。

• property_set_fd
• signal_fd
• keychord_fd

実は、このあたりの処理が、froyoまでと異なってまして、froyoまでは init が udevd 的な機能も含んでいました。init.c内には、デバイスファイルを生成するためのルールが直に実装されており、init.rcファイルで追加できるものの基本のデバイスファイルはソースコードを変更してビルドし直さないと作れない状態だったわけです。froyoまではDaemon処理部では、上記の他に、device_fdもpollしてましたが、Gingerbreadからはこれが無くなっています。

今回からは、Android.mkで init が、ueventdとしてシンボリックリンクされるようになっており、udevdとして起動されると、ueventd.rc をパースしてデバイスのリストを保持した後、device_fdをpollするように実装されています。

ueventd 自体は、init.rc にサービスとして登録されており、initプロセスとは異なるプロセスとして起動されることになります。なおこれに伴いfroyoまでinit.rc , init.<hardware>.rc で利用できたdeviceコマンドは使えなくなりました。こちらはueventd.rcファイルに記載しueventdのみが利用することにまります。

アプリ側もAPI Levelが変わるとついて行くのが大変そうなんですが、プラットフォーム側もバージョンが上がると結構追いかけるのが大変なんですよねぇ。