年始めに Android init

とりあえず新年の三日間の更新に挑戦中の三日坊主な隠者でございます。
新年あけましておめでとうございます。

初日なのでinit・・・といいつつ、実は昨年の勉強会を振り返っての内容なのですが、initに関してもGingerbreadで若干追加変更もありましたので、追加情報を記載しようかと思います。

最初は横浜PF部第三回で@pakquiさんがBeagleBoard-xMでAndroidの起動処理を発表してくださった後、第四回の勉強会で隠者が init.rc 周りについての発表を、@pakquiさんが udev的な動作についての発表を @tetsu_koba さんが、ICEを使ってデバイス認識の部分のライブデバッグの実演をして下さり、当日は init祭りと呼ばれる勉強会となりました。

その後、@tetsu_koba さんの方では追加で解析を続けられており、initの動作についてもう少し掘り下げて下さいました。

• 横浜PF部 第三回勉強会 
• 横浜PF部 第四回勉強会
• KMC Staff Blog 「Androidのinit」

とりあえず、薄〜く内容を復習です。第三回で@pakquiさんが話して下さった内容ですが、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プロセスの役割は、KMCの @tetsu_koba さんが blog の中で記されているように大きく分けて二つあります。

• Boot処理部
• Daemon処理部

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

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

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

• property_set_fd
• signal_fd
• keychord_fd

実は、このあたりの処理が、froyoまでと異なってまして、第四回の勉強会で@pakuchi さんが語られた通り、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が変わるとついて行くのが大変そうなんですが、プラットフォーム側もバージョンが上がると結構追いかけるのが大変なんですよねぇ。