これは、大きなプロジェクトの一部をメインプロジェクトから参照するライブラリプロジェクトにエクスポートする場合、メインプロジェクトを再構築するときに、すでに構築されている(変更されていない)ライブラリを再構築する必要がないことを意味しますか?
部分的にはありません。Androidライブラリプロジェクトは直接ビルドされません。常に依存するメインプロジェクトと一緒にビルドされます。SDKがメインプロジェクトをコンパイル/ビルドすると、SDKツールはライブラリプロジェクトを一時的なJARファイルにコンパイルし、メインプロジェクトで使用します。メインプロジェクトを再構築するたびに、参照されているライブラリプロジェクトは、ライブラリプロジェクトで何も変更されていなくても、メインプロジェクトのビルドライフサイクルの一部として再構築されます。app-lib / binフォルダーの下に生成された一時JARのタイムスタンプを確認してください。これは、メインプロジェクトをビルドするたびに常に変更されます。
公式開発ガイドからの引用:
ただし、ライブラリプロジェクトは、独自の.apkに直接コンパイルして、Androidデバイスで実行できないという点で、標準のAndroidアプリケーションプロジェクトとは異なります。同様に、実際のライブラリの場合のように、ライブラリプロジェクトを自己完結型のJARファイルにエクスポートすることはできません。代わりに、依存アプリケーションでライブラリを参照し、そのアプリケーションをビルドすることにより、ライブラリを間接的にコンパイルする必要があります。
ライブラリプロジェクトに依存するアプリケーションをビルドする場合、SDKツールはライブラリを一時的なJARファイルにコンパイルし、メインプロジェクトで使用してから、その結果を使用して.apkを生成します。アプリケーションとライブラリの両方でリソースIDが定義されている場合、ツールは、アプリケーションで宣言されたリソースが優先され、ライブラリプロジェクトのリソースがアプリケーション.apkにコンパイルされないようにします。これにより、アプリケーションは、任意のライブラリで定義されているリソースの動作または値を使用または再定義する柔軟性が得られます。
Androidライブラリプロジェクトは、通常のJavaライブラリプロジェクトとは異なります。ここで、すべてをコンパイルしてjarライブラリに一度ビルドし、メインプロジェクトの参照jar依存関係からクラスのインポート/使用を開始できます。現在、Android Library Projectは、このAndroidブログで言及されているように、コンパイル済みコードベースのライブラリメカニズムではなく、ソースベースのメカニズムで設計されていますが、将来のリリースでは自己完結型のjar配布が約束されています(残念ながら、r15、r16、r17、r18のいずれでもありません)。まだ)。