Androidの仕組み

 

 

 

●SurfaceManager
SurfaceManager」は，グラフィックス・レイヤを合成して一つの画面に表示する仕組みをアプリケーションに提供する描画ライブラリだ。グラフィック・レイヤを使うと，アプリケーションを経由しないで画面表示が可能なため，高速に描画できる。アプリケーションからは主に，カメラやGPU（GraphicsProcessingUnit）といったハードウエアからのデータを，高速に描画するために利用する。

 

●MediaFramework
画像の表示や音声・動画のエンコードとデコードの処理を実行するライブラリ。米PacketVideo社のメディア再生用ライブラリ「OpenCORE」をベースに開発されている。対応するフォーマットには，音声では「mp3」や「aac」など，動画では「h.263」や「h.264」などがある。

 

●SQLite
高速なリレーショナル・データベース・エンジン。データ管理の機能を提供する。格納する電話番号を比較するなど，Android用に文字列を処理する機能が追加されている。

 

 

●OpenGLES
ハードウエア・アクセラレータを使った高速な3D描画を実現する3Dグラフィックス・ライブラリ。OpenGLES1.0*に準拠している。

 

●WebKit
HTMLまたはXHTMLの描画を担当するライブラリ。内部に，高速なJavaScriptエンジンである「SquirrelFish」が搭載されている。開発者がアプリケーションの画面にWebページを表示する場合に利用する画面部品（ウィジェット）である「WebView」にも機能を提供している。

 

Android用のCライブラリ。BSDのCライブラリを基に開発されており，x86とARMに対応している。標準規格に沿ったlibcと比べ，ロケール（各国語対応）やマルチバイト文字に対応していない，C++の例外に対応していないなど，最低限の実装のみサポートしている。携帯端末上での動作を最適化するために，「機能を限定してライブラリが肥大化してしまうことを防止する」という方針で開発されている。

◆Android Runtime

次いで，アプリケーションの実行環境「Android Runtime」を解説する。Android Runtimeは，仮想マシン「Dalvik VM」と，基本的なAPIを提供するコア・ライブラリで構成される。

Androidのすべてのアプリケーションは，Dalvik VM上で動作する（図4）。Dalvik VMは，Java VMと同様，メモリー管理をガベージ・コレクタ*が担当している。開発者がメモリーの確保と解放を明示的に実行しないでも，メモリー・リークによる深刻なシステム破壊を防いでいる。
* 【ガベージ・コレクタ】 メモリー上の不要な領域を回収してメモリー領域を広げるプロセス。

加えて，JavaからC/C++を呼び出すAPIのJNI（Java Native Interface）にも対応している。CやC++で書かれたネイティブのコードが実行可能となっている。

Dalvik VMのアーキテクチャは，“レジスタ・ベース”を採用している。レジスタ・ベースは，CPU内部のレジスタにデータを格納して演算処理を実行する。一方，Java VMは“スタック・ベース”である。スタック・ベースは，一時的なデータ格納領域（スタック）にデータを格納して演算処理を実行する。仮想マシン（VM）の場合，スタックは主メモリー上に確保される。

演算処理に主メモリー上のスタックが介在するスタック・ベースと比較して，CPU内部のレジスタのみで実行するレジスタ・ベースのアーキテクチャは，より高速に動作する。また，メモリー上にスタックを確保しないのでメモリーのフットプリント（動作に必要なメモリー量）が小さいとされる。

Dalvik VMが実行するのは，「Dalvik Executable（DEX）」と呼ばれる独自形式のバイナリ・プログラムだ。通常，レジスタ・ベースのバイナリは，スタック・ベースのバイナリに比べて容量が大きくなる。しかし，DEXでは，重複による無駄を極力減らし，Java VMのクラス・ファイルよりも小さいバイナリを実現している*1。重複を減らすために，内部的にクラス名，変数名やメソッド名をJavaバイト・コードのように文字列としてではなく，一意の名前（シンボル）に変換して管理している。
*1 Dalvik VMやDEXの最適化の詳細については下記の動画（英語）が詳しい。 http://www.youtube.com/watch?v=_KBvHqLSAHY&hl=ja

開発者はDEXの作成を意識しないでよい。アプリケーション開発では，Javaのクラス・ファイル（.class）を作成するが，Androidが提供している開発ツール「dx変換ツール」で，Javaのクラス・ファイルからDEXに自動で変換する。　コア・ライブラリは，Java 1.5 SEと互換性を持つライブラリだ。アプリケーション開発者は，Java言語での開発と同じ感覚でコア・ライブラリを扱える。

◆アプリケーション・フレームワーク

アプリケーション・フレームワーク層では主に，アプリケーションの起動から終了までの流れ，すなわちライフサイクルの管理を実施する。加えて，ユーザー・インタフェースの表示やユーザーによる操作など携帯端末で起こるさまざまな状態の変化を，各アプリケーションに伝える手段も提供している。
また，Java言語からCやC＋＋などのプログラム（ネイティブ・コード）を利用できるように“ラッピング”した各種プログラム（ラッパー・クラス*）を用意している。これにより，アプリケーションから端末の状態を取得したり，ハードウエアにアクセスしたりする。アプリケーションの開発者は，ネイティブ・コードやカーネルを意識する必要がない。
* 【ラッパー・クラス】 あるライブラリが備えるAPIから別のAPIを使えるように“包み込む”クラスのこと。
　以下に代表的なフレームワークを解説する。

●Activity Manager
「Activity Manager」は，各アプリケーションのアクティビティのライフサイクルを管理する役割を持っているフレームワークだ。アクティビティの開始から割り込みによる中断と再開，終了にかかわる一連の流れを，Androidでは「アクティビティのライフサイクル」と呼ぶ（図5）。

アクティビティは，ユーザーが操作可能な画面と，操作に対応する処理を持つ。Androidアプリケーションの設計指針では，アクティビティを画面遷移の最小要素と位置付けている。つまり，1つの画面に1つのアクティビティがある。画面の切り替えを伴うアプリケーションは，複数のアクティビティで構成され，アクティビティ同士が相互に呼び出し合って画面遷移が実行される。

Androidは，マルチタスクで複数の処理を同時に実行できるが，画面（フォアグラウンド）に表示されるアプリケーションは，常に1つと定められている。トランプのカードが重なっている様子を想像すると理解しやすいだろう。カードの1枚ずつがアクティビティで，呼び出されたアクティビティが一番上（フォアグラウンド）に表示されるのである。

携帯端末上で動作するアプリケーションは，さまざまな要因で割り込みが発生し，その都度中断される。例えば，電話が着信すれば着信画面に切り替わり，ユーザーが一定時間操作しなければ端末が“スリープ・モード”になる。

割り込みの要因が終了した場合，例えば電話が終わったり，ユーザーが操作してスリープ・モードを解除したりした際には，元のアクティビティを中断前の状態から再開する必要がある。ゲームのアプリケーションの場合，電話の着信のタイミングで一時停止しておかなければ，電話が終わった時にゲームオーバーの画面が表示されているという悲劇は避けられない。

Activity Managerは，カーネル上の各種ドライバ，例えば，電源管理ドライバや電話機能管理ドライバの状態変化に応じて，現在起動中のアプリケーション（正確にはアクティビティ）にライフサイクルの変化を通知する。

これにより，表示中のアクティビティは，フレームワーク層より下（カーネルやドライバ，ハードウエア）を意識せずに，割り込みによる中断や再開，終了など，さまざまなタイミングで必要となる前処理を実行できるのだ。

●Content Provider
「Content Provider」は，アプリケーション同士がデータを共有する際に使う非常に重要なフレームワークだ。アプリケーションから利用する共有データの定義と入出力のインタフェースを提供する。

Content Providerを利用したアプリケーションに，標準でインストールされている電話帳（Contact）がある。電話帳は，それ自身でデータを保存せず，別途定義したContent Provider経由で連絡先データを管理している。そのデータは，ユーザーが認めた他のアプリケーションからも参照できる。

例えば，メール・アプリケーションから電話帳のデータにアクセスして，新しく受信したメールの差出人の情報を登録できる。逆に，SMS（ショート・メッセージ・サービス）アプリケーションから電話帳のデータを検索し，メッセージの送信先の電話番号を取得することも可能だ。

標準以外の電話帳を使いたい場合でも，新しい電話帳アプリケーションが古い電話帳のContent Providerに対応していれば，わざわざ連絡先データを移行する必要はない。

このようなデータ共有手段がフレームワークで用意されているのは，Androidのファイル・セキュリティに関連している。通常のLinuxディストリビューションでは，ユーザーにアクセス権さえあれば，あるソフトウエアが保存したデータは，別のソフトウエアから読み込める。しかし，Androidの場合は，原則として1つのアプリケーションで保存したデータは，他のアプリケーションから読み込めない。

Androidアプリケーションは，インストールの際に，それぞれ固有のユーザーIDを割り当てられる。その割り当てられたユーザーIDが所有者となり，プロセスが実行される。アプリケーションから保存されたファイルは，標準では他のユーザーIDからは読めないパーミッション（権限）に設定される。そのため，別のユーザー IDを持つ他のアプリケーションから自由に読み込めないのだ（図6）。

また，Androidアプリケーションの設計指針には「データは独自で管理せず，Content Providerで管理すべき」というものがある。すべてのアプリケーションを同じ所有者にし，携帯端末に保存しているデータすべてに無制限のアクセスを許せば，悪意のあるアプリケーションがデータを破壊したり，情報を漏えいさせたりする危険性がある。しかし，各アプリケーションが独自形式で管理し，他のアプリケーションから参照できなければ，本来起こるかもしれないアプリケーション同士の連携の機会を失ってしまう。

Androidのファイル・セキュリティとContent Providerは，アプリケーションによる共通データの独占を防止しながら複数のアプリケーションからセキュアなデータ操作を実現する携帯端末向けプラットフォームならではの仕組みといえる。

●View System
「View System」は，画面に表示する各種部品やユーザーの操作に関する各種機能をアプリケーションに提供するフレームワークだ。例えば，ある画面に「ボタン」を表示する場合，そのボタンが四角いのか丸いのか，ボタンの表面には画像が表示されるのか，などを操作できる。さらに，画面の部品が複数あった場合，それらをどのように表示するか，縦に並べるか横に並べるかなど，それら一切を管理する。アプリケーション開発者に提供する“GUIツールキット”といえる。

View Systemが提供する画面の部品には，ボタンやテキスト・ボックス，ラジオ・ボタン，といった基本的なものがある。さらに，ライブラリを使って高度な機能を提供するものまで，豊富な部品がそろっている。例えば，ライブラリ層のWebkitを利用してユーザー・インタフェースに埋め込んでWebサイトを表示できる「WebView」や，ライブラリ層のSurface Managerを使って画面への高速な描画を実現する「SurfaceView」だ。アプリケーション開発者が，これらを拡張して新しい部品を作ることも可能である。

●Package Manager
「Package Manager」は，Android上のパッケージ管理機能をアプリケーションに提供するフレームワークだ。

Androidの実行環境であるDalvik VMで実行されるバイナリは，DEXと呼ぶAndroidの独自形式を採る。アプリケーションとして配布されるパッケージは，「.apk」という拡張子を持っている。

.apkファイルは，ZIPで圧縮された複数のファイルで構成される（図7）。Javaのパッケージ形式である「.jar」ファイルと同じ構造を持ち，署名用ツール「jarsigner」での署名が可能。実際，アプリケーションを配布するためには，開発者が自身の証明書で.apkに署名する必要がある。

ユーザーがAndroidアプリケーションをインストールする場合，Package Managerは，まずインストールする対象の.apkファイルを展開して，AndroidManifest.xmlファイルを読み取る（図8）。次に，AndroidManifest.xmlに記載されているパッケージ名から，同じアプリケーションが既にインストールされているかを確認する。

もし，同じパッケージ名のアプリケーションが登録されていなければ，そのままインストールの工程に進むが，同じアプリケーションがインストールされている場合は，上書きしてもよいかを確認する。

上書きインストールの場合において，ユーザーが上書きを認めれば，Package Managerは基からあるアプリケーションと新しくインストールする.apkファイルの「署名に使われた証明書」が一致するかを確認する。

2つの証明書が一致すれば上書きインストールを実行するが，一致しない場合は，インストールを中止する。これは，本来の開発者とは別の開発者が，改ざんしたアプリケーションを不正な目的で流通させたり，乗っ取ったりすることを防ぐ目的で設けられているセキュリティ機構である。

問題なくインストールされる場合，Package Managerは，インストールするアプリケーションが携帯端末のどの機能を使うかを表示して，ユーザーの承諾を求める（写真1）。AndroidManifest.xmlには，そのアプリケーションがAndroidのどの機能を利用するのかが列記されている。

ユーザーがインストールに同意した場合，それが新規インストールであれば，アプリケーションに固有のユーザーIDを割り当て，同時に，ファイル・システム上に，アプリケーション用のデータ保存用フォルダを作成する。

Package Managerは，それらに加えて，AndroidManifest.xmlに登録されているアプリケーションの構成要素を内部に記録する処理を実行する。記録する内容は，具体的にはアプリケーション名やアイコンをはじめ，アプリケーションを構成する要素にはどのようなアクティビティ（画面）やサービスがあるか，などだ。

Package Managerが記録したこれらの情報は，他のアプリケーションから取得できる。例えば，Androidでは待ち受け画面もアプリケーションだが，インストールされているすべてのアプリケーションの一覧を待ち受け画面が表示できるのも，Package Managerから取得しているからだ。

また，アプリケーションが依存するアプリケーションの有無を調べることもできる。QRコードの読み込みに使う「QRコードスキャナー」を呼び出すアプリケーションの場合，QRコードスキャナーがインストールされているかを事前に確認しなければならない。そのような場合にもPackage Managerを利用できる。

つまり，アプリケーションの追加と削除がすべて，Package Managerを通じて実行される。これにより，ユーザーや開発者は，ファイル・システム上にどのようにアプリケーションが配置されているかを特別意識することなく，アプリケーションを配布したり，アプリケーションが使う機能を事前に確認したりして，安全にインストールできるのだ。

●Resource Manager
「Resource Manager」は，画面に使う画面デザインや画像データ，文字データを「リソース」としてプログラムから分離し，アプリケーションから動的に参照する機能を提供するフレームワークだ。

Androidアプリケーションは，ユーザー・インタフェースの中で画像を表示したり，操作に応じて音声ファイルを再生したりすることがある。代表的なものとしてアプリケーションのアイコンが挙げられる。

これらのリソースはアプリケーションのコードに組み込まない。例えば，画像ではPNGやJPEG，音声ならばWAVやMP3といった単体のファイル形式でアプリケーション・パッケージに組み込む。ユーザー・インタフェースの設計情報はXML（拡張マークアップ言語）形式で記述し，コードとは別に保持できる。これにより，保守性を高めている。

通常のLinuxディストリビューションであれば，パッケージのソフトウエアがインストールされる過程で，これらのファイルはファイル・システム上に配置される。その所在を設定ファイル内で示せば，必要なファイルを読み込める。

しかし，Androidでは，アプリケーション・パッケージがファイル・システム上でどのように配置されるのかはPackage Managerが管理している。そのため，プログラムのコード上で特定のファイルやディレクトリを指定できない。

このような外部ファイルをプログラム上から識別して扱うための仕組みをResource Managerが提供する。各リソースの識別名について，一意なID（リソースID）を割り当てて，アプリケーションが参照できる仕組みとなっている。

リソースIDは，アプリケーション開発の過程でリソースの追加に応じて割り当てられる。アプリケーションのコード上からはリソースの識別名やリソースIDを指定するだけで，そのリソースを指し示せる。リソースから他のリソースの参照も可能だ。

Resource Managerには，アプリケーションの各国語対応（ローカライズ）を自動化する役割もある。

Androidはさまざまな国で使われる想定で，各国語対応の仕組みを備えている。アプリケーション開発者が，1つのパッケージの中に各言語のリソース（文字や音声情報など）を内包できる。Resource Managerは，アプリケーションが実行される際に，システムの言語設定に応じて，どの言語のリソースを表示するかを決定する。

最後に，アプリケーションが実行されるときのAndroidの内部的な動きを解説しよう。電話帳，カメラ，カレンダなど，Android携帯のユーザーが実際に操作するプログラムは，すべてこのアプリケーション層に入る。

Androidでは，特別扱いのアプリケーションはない*2。つまり，フレームワークが提供するAPIはすべて第3者に公開されている。開発者はどんなアプリケーションでも開発でき，多くの開発者がさまざまなアプリケーションをリリースしている。

*2 ただし，製品版の携帯電話では，電話機能を制御するアプリケーションについては保護されている。

ここでは，Android用のアプリケーション配信サービスである「Android Market」から入手できる2つのアプリケーションを紹介する。これらのアプリケーションがAndroid内部で具体的にどのように動作しているのかを説明する。

●ポケットスケッチ
ポケットスケッチは，タッチパネルを使い，指でなぞるだけで絵が描ける簡易ペイント・アプリケーションだ（写真2）。登録名「EMOTIONPLUS」が公開している。見た目は地味だが，描画領域を無段階に拡大・縮小できるなど，有用な機能が搭載されている。

 

ユーザーの操作に応じてアプリケーションがどのようにして画面に線を描画するのかを見てみよう。

まず，端末のタッチパネルにユーザーが触れると，カーネル上のデバイス・ドライバがその入力を受け取る。これはキーボード・ドライバやマウス・ドライバと同じ，入力用のデバイス・ドライバである。

ドライバは，ユーザーのタッチする操作を，パネルがタッチされた瞬間，タッチされている間，離された瞬間という3種類の入力情報としてプロセスに伝える。その他にも，タッチパネルの精度や圧力などの情報が含まれる場合もある。

このプロセス上で動作しているのはアプリケーションの実行環境（Dalvik VM）である。ドライバからプロセスに渡された入力情報は，最終的にはDalvik VMを通してアプリケーションに入力される。

アプリケーションがタッチパネルの入力を受け取る方法は，アプリケーション・フレームワークがAPIとして提供している。従って，開発者は，フレームワーク層以下を意識する必要はなく，タッチパネルのイベントに対してどのような処理を実行するのかをJavaで実装すればよい。

このようにして，ポケットスケッチは，ユーザーがパネルをタッチして離すまでの間，タッチされている座標上に色を描画し続け，線や図形を描く機能を実現している。

また，ライブラリ層に位置するMedia Frameworkは，キャンバスに描いた絵を圧縮して保存する機能を提供している。ポケットスケッチは，描画したデータをPNG形式で保存する。その出力にもMedia Frameworkを利用している。Media Frameworkを使って画像を変換するAPIをフレームワーク層が提供しており，開発者はこのAPIを利用して高速なネイティブ・ライブラリによる画像変換などをJavaから処理できるのである。

 ●No Signal Alert
「No Signal Alert」は，電波が入らない場所に来ると音や振動で知らせてくれるアプリケーションだ（写真3）。登録者名「Smart Android Apps」が公開している。

このアプリケーションの特徴は，ユーザーの操作が必要なのは設定画面だけで，1度設定すれば，実際の電波状態の監視はサービスが実行していることだ。設定は画面（アクティビティ）で実施し，その内容を既に起動しているNo Signal Alertのサービスに反映するために，Binderドライバを利用している。

No Signal Alertのサービスは，電波の状況を確認し，電波が圏外であった場合には警告を表示するという，簡単な仕組みだ（図9）。

まずはハードウエアが電波状態を受け取る。受け取った情報はカーネルのTelephonyドライバに送られる。

フレームワーク層のTelephony Managerは，ドライバとアプリケーションをつなぎ，電波状態の変化をアプリケーションに都度通知するAPIを提供している。電波状況を受け取ったアプリケーションは，圏外であれば，あらかじめユーザーの設定した方法で通知する。

通知の手段としてバイブレーションやオーディオなどを使う。No Signal Alertは端末を振動させたり，音声ファイルを再生したりする。これらを利用するためのAPIもフレームワークが提供している。

音声ファイルの再生には，ライブラリ層のMedia Frameworkを利用している。圧縮された音声データを復号（デコード）して再生するためにフレームワーク層の内部から自動的にMedia Frameworkを呼び出している。

電波状況やバイブレーション，オーディオなど，ハードウエアと関連するAPIでは，フレームワークの内部でネイティブ・コードが実行されている。これは JNIにより，Dalvik VMを通じて実行されている。そのため，アプリケーション開発者はネイティブ・コードの存在を意識することなく，アプリケーションを開発できる。

☆　　　☆　　　☆

Linuxをベースとした携帯端末プラットフォームは「LiMo Platform」が既にあり，Androidが初めてではない。また，機種に依存しない実行環境とフレームワークという点では，Javaがある。細かな違いや工夫はあるが，一つひとつを見れば，Androidには特に目新しい点がないと思われるかもしれない。しかし，それら「すべて」を兼ね備えているプラットフォームはAndroidが初めてだ。Linuxカーネルをベースに，アプリケーション実行環境とフレームワークを備える携帯端末に最適化されたプラットフォームが，オープンソースで入手できることこそが，Androidの最大の特徴といえるだろう。