2 つの Android ライブラリ プロジェクトを含む Android プロジェクトがあります。
コマンドant debugを使用してプロジェクトをビルドしていますが、約 1 分 20 秒かかります。最初の Android ライブラリ プロジェクトをコンパイルするのに 17 秒、2 番目の Android ライブラリ プロジェクトをコンパイルするのに 42 秒を費やしていることを数えました。
これら 2 つの依存プロジェクトはめったに更新されないため、毎回コンパイルする必要はありません。
ビルドごとに2つのAndroidライブラリプロジェクトをコンパイルするのを避けるにはどうすればよいですか?
あなたに追加
dont.do.deps=1しますlocal.properties（またはこのプロパティを他の方法でアリに渡します）
これは、Android ライブラリ プロジェクトがどのように設計され、現時点で動作すると想定されているかを示しています。メイン アプリケーション プロジェクトのコンパイルと共に常に間接的にコンパイルされます。次の公式開発ガイドを参照してください。
ただし、ライブラリ プロジェクトは、独自の .apk に直接コンパイルして Android デバイスで実行できないという点で、標準の Android アプリケーション プロジェクトとは異なります。同様に、真のライブラリの場合とは異なり、ライブラリ プロジェクトを自己完結型の JAR ファイルにエクスポートすることはできません。代わりに、依存アプリケーションでライブラリを参照してそのアプリケーションをビルドすることにより、ライブラリを間接的にコンパイルする必要があります。
... ... ...
開発上の考慮事項
ライブラリ プロジェクトを JAR ファイルにエクスポートすることはできません
ライブラリは、バイナリ ファイル (JAR ファイルなど) として配布することはできません。これは、SDK ツールの将来のバージョンで追加される予定です。
あなたが話しているのは、コンパイル済みのjarファイルです。ライブラリ プロジェクトの bin ディレクトリの下でEclipse エクスポート関数または自動生成された jarを使用することを提案するいくつかの投稿がここにあります。 Android リソース ファイルが含まれています。この場合、このようないくつかの汚いハックがあり、IMOは解決するよりも多くの問題を引き起こします。
Android 開発チームはそれに取り組んでおり、Android ライブラリ プロジェクトをソースベースのメカニズムからコンパイル済みコード ベースのライブラリ メカニズムに変更しようとしています。詳細については、このブログ投稿をご覧ください。公式の開発チームからの究極の解決策を待つことをお勧めします。
プロジェクトにライブラリがあるときに Android のコンパイルが遅いという問題があり、「--incremental」スイッチを dex ツールに適用することでこれを解決しました。SO でこの質問を参照してください。