Androidのアーキテクチャ図を描いてみる

まだまだ初学者な隠者が、同じくこれから勉強をと思う方に初回らしく示せるものが無いかなと色々考えた末、これから、どこを学んでいきたいか、その指針の一助にでもなればと、Androidのアーキテクチャ構成について、簡単に説明してみようかなと考えています。ま、そんなわけで、まずはお手軽に図からということで、アーキテクチャ図を描いてみました。

Androidのアーキテクチャといえば、大方の人が思い浮かべるのが以下の図でしょう。公式のWebページで公開されているアーキテクチャ図はこんな感じです。あ、まだサイズ調整等はしていないので、いまいち見難いのは勘弁してください。

アプリケーション、アプリケーションフレームワーク、ライブラリ、アンドロイドランタイム、Linuxカーネルの５つの層から成り立っています。ところで、実は2008年のGoogle IOで公開されたアーキテクチャ図には、もう
一層あって、なお且つ、ポーティング等下周りに着目する人にはそれこそ重要な層なわけです。その層を足した図が、以下のような感じになります。

その層は、Hardware Abstruction Layer - 通称HAL です。まぁ、そのまま、ハードウェア抽象レイヤですね。Dalvik　VMより上の層からハードウェアを利用する場合に、直接カーネルにアクセスするのではなく、ユーザー空間に一層設けて、そこでハードウェアへのアクセスを吸収しています。

私見ですが、このような層が設けられている理由としては

・Linud DriverではGPLになるが、HAL部分はカーネルとリンクしないのでGPLに縛られない
・Linuxへの依存をここで吸収することで、上位の層をLinux Kernelに依存しすぎないようにする

等が考えられるかなと思っています。実際、LinuxのドライバだとGPLなの、いやだなぁ・・・と思うベンダーさんもまだいるのではないかと思います。まぁ、隠者はハード屋ではないので、ドライバのコード読まれる事のリスクがどれほどのものなのかはわかりませんが。
何か、特殊な技術が読み取られかねないというなら、ドライバは、至極一般的な作りにして、本当に守りたいアルゴリズムは、ユーザー空間に置く事も可能なのかもしれません。
まぁ、ユーザー空間だけに、パフォーマンス的な制約が気になるところですけど。

ところで、このHAL、ソースコード上では、libhardware.so等になり、Dalvik VMにロードされます。まぁ、つまり一般的な動的ライブラリです。そして、libcはライブラリの中でも少し特殊な立場にあるわけなのは、プログラマな方ならお分かりの事かと思います。ソースコードを調べると、libcはbionicというディレクトリにまとめられています。他にはローダーであるLinkerや、pthread等、Nativeのライブラリ、アプリケーションを作るときに必要なライブラリ群はBionic の下にまとめられているわけです。

というわけで、どうせなので、アーキテクチャ図もちょっと変えてみました。

うーん、どうでしょう。やっぱりいまいちですかねぇ。まぁ、隠者は、HALの部分に大分興味があったりするので、心の声を反映してHALがかなり大きくなってしまってますし。バランスも悪いですね。なかなかどうして難しいものです。まぁ、プラットフォーム関係者向けの資料としては、これくらいの大きさを占めておいてもよいかもしれません。

実際、Androidのポーティングというと、実は、いくつかの段階を踏む事になります。

(1) Android向けドライバの入ったLinux Kernelをターゲット上で動作するようにする

(2) ターゲットのアーキテクチャ向けにAndroidをビルドする。
(3) init.rc等各種設定ファイルをターゲット向けに書き換える

ちなみに、動作実績があまりない環境だと
(4) Dalvik VMのパフォーマンスチューニング
等も必要になるかもしれませんけど。

で、ここまでで最低限の動作はしますが、これに、
(5) 接続するセンサーやGPS,カメラ等のHALを用意する
まで行わないと、各種デバイスがAndroidのアプリケーションから動かない状態になってしまいます。ついでにいうと、HAL層のグラフィック向けの処理を描かないと、すべてがCPUで処理されるためパフォーマンスがグンと落ちるという事になったりもします。真面目に動くAndroid機器を作るとなると、どうしてもこのHALをきちんと実装する必要がでてくるわけです。