ご存知かもしれませんが、Android ツールチェーンはいくつかの単純なアイデアに基づいています。
- コードはプレーンな古い Java コンパイラを使用してコンパイルされ、システム ライブラリとのリンクのために Android スタブ (android.jar) とリンクされます。
- コンパイル後、コードは dex 形式に変換されます。実際にこれを自分で実行できます
dx --help
。このツールの仕事は、dx
Java クラス ファイルを取得し、それらを dex コードに変換することです。これは、スタック ベースからレジスタ ベースの vm への移行を含む非常に簡単なコンパイルと、その他のいくつかの変更です。
- これを配置した後、一連の apk ツールを使用して apk を構築します。以前
apkbuilder
は でしたが、これは非推奨になりました。実際にこれを自分で実行することもできます。APK はすべて、マニフェスト、リソース、および dex 形式のすべてのコードの 1 つのファイルの単なるコレクションです。(つまり、多くの .class ファイルは、ラップされたポインターの Web のためにかなり小さい単一の .dex にコンパイルされます)。
したがって、Android ツールチェーンはそれほど複雑ではありません。build.xml
カスタム ビルド プロセスは、platform-tools/
ディレクトリ (iirc)にある SDK 全体で定義されている ant ビルド ルールによって処理されます。ただし、このカスタム ビルド環境を使用して新しいベースライン プロジェクトを生成するには、android update project
コマンドを使用するだけです。
これがあなたが望んでいた反応かどうかはわかりませんが、ビルド プロセスの曖昧さが解消されることを願っています。ツールチェーンはそれほど複雑ではなく、その大部分は市販の Java であり、Android 固有のものではありません (Android 固有のものは、動的にリンクされたシステム コードのライブラリ固有のスタブだけです)。さらに、一連のクラスを取得したら、いくつかのコマンドを実行するだけで、Android がアンパックする実行可能な APK を作成できます。JVM をターゲットとするツール (および Android 固有の動的にリンクされた API とリンクできるツール) は、クラス ファイルを生成し、このツールチェーンを使用して残りの部分をコンパイルするという同様のプロセスを実行できると思いますが、明らかに自動化された ant ビルド プロセスははるかに簡単になります。
編集:
さらに掘り下げた後、この関連する android-developers スレッドを見つけました。 不穏な引用:
現時点では、独自のビルド システムを使用したい人をサポートするためのリソースがありませんが、できることを心から願っています。多くの点で、ロジックを eclipse または ant 固有のコードに明確に分離することで、他のツール ベンダーが簡単に使用できるようにしています (そのため、ツールと ADT のいたるところに多数の jar ファイルがあります) が、これはその 1 つではありません。
ただし、このリンクも役立つ場合があります。