Android開発環境ひとめぐり

Androidアプリケーション開発上の細かい部分については、ウェブ上にも非常に多くの資料があるが、 開発環境全般についておおまかに把握できるような文書は意外に少ない。 ここでは、Eclipseを使用して日常的にJavaアプリの開発を行っている者向けとして、大雑把にAndroidの開発環境を把握させる目的で記述する。

Android SDK

開発環境としては、基本的にJava環境とAndoid SDKがあればよい。もちろん、Eclipseを使用しないで開発を行うのは困難が伴なうと思われるが、Androidアプリの作成には必ずしも必要では ない。

また、Javaは「コンパイラ」のみが必要と思われる。なぜなら、Androidアプリの実行は（実機であってもエミュレータであって も）DalvikVMという独自のVM上で行われるので、JavaのVMは必要ないからである。実行形式もJava本来のjarファイルではなく、apk という拡張子のファイルになる。apkはjar同様に構造はzipファイルではあるが、jarの中身とは全く異なる。

Android SDKにはエミュレータが含まれており、実機がなくとも作成されたapkをこの中で実行してみることができる。このエミュレータはCPUレベルのエミュレーションを行っており、これはARMプロセッサのようである。つまり、このエミュレータの上に、ARMプロセッサとその上で走行するLinux、さらにその上にDalvikVMが載っているので、非常に動作が遅いが、ほぼ完全に実機と同じ環境を作成できるようである。

APIレベル

androidにはAPIレベルというものがある。これはAPIのバージョンとも言うべきものであるが、当然のことながら時間が経過するにしたがって上がってくる。この一方で、実機の方は簡単には上がらないため、開発環境ではどのAPIレベルをターゲットとするかを指定できるようになっている。

もちろん、古いバージョンをターゲットとすれば、多くの実機で動作するだろうが、これも当然ながら新しい機能を使用することはできない。

AVD

AVDというのは、要するにエミュレータ上で動作する実機のイメージである。androidの実機としては、様々なAPIレベルのほか、様々なデバイス（SDカードメモリを持つか、画面の解像度はいくらかなど）の違いがあるため、これらを定義した実機のイメージを作成しなければならない。

これを先のエミュレータ上で動作させ、その上に開発済みアプリを走行させるということになる。ただし、ほとんど「実機と同じようなイメージ」ではあろうけれども、エミュレータによってその状態を変更できるようなものであるらしい。例えば、エミュレータに対して、ACアダプタが接続状態であるか、あるいは電池での駆動であるか、電池なら残りの容量は何%であるかなどを指定できるようになっており、エミュレータはその状態を作りだしてアプリ側に通知することができる。

ツール

Android SDKには、これだけでAndroidアプリケーションが作成できるだけのツールが付属している。 これは、SDKインストールディレクトリの下のtoolsディレクトリと、platforms\android-?\toolsの下にある。

android-?の?にはAPIレベル番号が入るが、つまりAPIレベルによって使用可能なツールが異なるということらしい。

Eclipse(ADTプラグイン)

上述のようにEclipse無しであっても、SDKがあればAndroidアプリの作成は可能らしいが、Eclipseと(Eclipse用の)ADTプラグインがあれば開発は楽になる。

このADTプラグインには大雑把に二つの役割があると思われる。

• EclipseをAndroid専用のIDEにする。
• Android SDKとの橋渡しを行う。

Androidパースペクティブ

通常、Eclipse上でJavaプログラムの開発を行うには、JavaパースペクティブやJava EEパースペクティブを使うものだが、Androidの開発では、全面的にJavaとXMLを使うにもかかわらず、Androidパースペクティブを使用する。このパースペクティブによって、EclipseはAndroid開発専用のIDEとなる。

このパースペクティブは、ソースコードとしてはJava及びXMLその他画像ファイルなどのリソースを使うものであるので、基本的にはJavaパースペクティブと大差は無いのだが、最大の違いは、リソースを編集すると同時にR.javaファイルを自動的に生成することにあると思われる。

リソースの扱い

Androidでは、表示を国際化するために文字列をリソースとして管理することはもちろんだが、様々なandroidデバイスに対応できるように、デバイスの細かな違いによって異なるリソースを作成しておき、それが実行時に自動的に選択される。

例えば、iPadのアプリによくあるように、縦向きと横向きとで異なる画面レイアウトにすることももちろんandroidでは可能であるが、それもXMLリソースとして静的に定義しておけるようだ。

そして、これらのリソース(XMLファイルや画像ファイル、その他）をJavaプログラム側から参照できる必要があるが、それを簡単にするためにリソースのID情報を持ったR.javaというJavaソースファイルが自動的に作成され、プログラム側ではそれを参照すればよいようになっている。

ただし、androidのリソースの扱いとして問題なのは（仕方が無いのかもしれないが）、リソースには名前空間が無いことである。 生成されるR.javaはもちろんパッケージを持っているのだが、そこに記述されるリソースを名前空間で区別することはできない。

androidの画面遷移はIntentというものを使用して間接的に行うことができる。つまり、画面間の結びつきをゆるく作成できる一方で、一つのプロジェクトの中に含まれるアクティビティをそのリソースと共に外部に出したり、それとは逆に外部からプロジェクトに持ち込むことが難しい。

※何か方法があるのかもしれないが、もし無いとしたらこの部分の仕様はあまりに貧弱だろう。

apkの生成

Javaパースペクティブと同様に、Javaソースファイルを編集してセーブするとその途端にコンパイルされる。 このとき、どうも最終的な配布ファイルであるapkまで作成されてしまうらしい。

この部分もJavaパースペクティブとは大きく異なる。Javaパースペクティブの場合は、コンパイルされて.classファイルは作成されるものの、jarファイルまでは作成されない。なぜなら、.classがあれば実行が可能だからだ。

これに対してandroidの場合には、apkファイルが無いとどうあっても実行はできない。

また、このapkファイルの中に何が含まれるかだが、前提条件としてapkはjarと異なり、実行時のクラスパス等の仕組みよって、別のapkファイルを参照するなどはできないようで、「必要なものすべて」がapkに含められてしまう。つまり、以下のすべてが自動的にapkに含められる（ただし、android-APIは当然省かれる）。

• プロジェクトのビルドパスの「ライブラリ」にて指定されているjarファイル。
• 同じくプロジェクトのビルドパスの「プロジェクト」にて指定されているプロジェクトのソースをコンパイルした内容。