Android ライブラリ プロジェクトがありFooLibます。FooLibは AndroidContextのようなものを参照しますが、リソース ファイル ( res/.
FooLibに依存させたいのですがBarLib、リソースを使用するため、JAR としてパッケージ化できません。代わりに、AAR としてパッケージ化されています。依存しているが、JAR としてパッケージ化し続けることは可能ですか? または、AAR 依存関係があると、それも AAR にする必要がありますか?BarLib BarLibFooLibBarLibFooLibFooLib
JAR ファイルと AAR ファイルを依存関係として含むプロジェクトがある場合 (以下の注を参照)、Android API のクラスに依存する Android 固有の JAR を依存関係として持つことができますが、JAR ファイルに Android リソースを含めることはできません。あなたが既に知っている。Android クラスに依存しているからといって、AAR としてパッケージ化する必要があるわけではありません。
ここで私が話しているのは、多くの JAR および AAR 依存関係を含むおそらく単一モジュールのプロジェクトです。JAR ファイルは単なるクラス ファイル (およびおそらく Android 以外のリソースやその他のファイル) のコレクションであり、依存関係がないため、壊れるものはありません。ビルドの段階になると、ビルダーはすべてをまとめてパッケージ化するだけで、JAR が他のクラスに解決できない依存関係を持っているかどうかを確認しません。実行時にクラスローダーの例外で確認できます。
IDE のマルチモジュール プロジェクトでライブラリモジュールについて話している場合、それは別の問題です。プレーン JAR にコンパイルできるモジュール A がある場合 (ビルド ファイル内のステートメントを使用します)、 AAR にコンパイルされるapply plugin: 'java'Android モジュール ( ) に依存することはできません。apply plugin: 'android-library'これはおそらく修正されないか、少なくとも当面は修正されないでしょう。Android モジュールにはソース フォルダーの概念がはるかに複雑であり、Gradle の Java プラグインは Android のソース セットを理解できないためです。
ただし、その逆も当てはまります。Android モジュールはプレーンな Java モジュールに依存できます。
ノート
compile files(...)Gradle ビルダーではまだ解決されていない制限があるため、ビルド ファイル内の JAR と同じ方法で (ステートメントを介して参照することで) ローカル AAR にアクセスすることはできません。Gradle をだまして、ある種の Maven リポジトリにあると思わせる必要があります (おそらく、ローカルにある実際のMaven リポジトリに配置することによって)。必要な場合の回避策については、「ローカル .aar ファイルを gradle ビルドに追加する」を参照してください。