ビルド依存関係の追加

Android Studio の Gradle ビルドシステムを使うと、外部バイナリや他のライブラリ モジュールを依存関係として簡単にビルドに含めることができます。依存関係は、マシン上またはリモート リポジトリで見つけることができます。推移的な依存関係が宣言されている場合、それも自動的に含まれます。このページでは、Android Plugin for Gradle に特有の動作と構成を含め、Android プロジェクトで依存関係を使う方法について詳しく説明します。Gradle の依存関係の概念をより深く理解するには、依存関係管理に関する Gradle のガイドもご覧ください。ただし、Android プロジェクトでは、このページに定義された依存関係コンフィグレーションのみを使用する必要がある点に注意してください。

依存関係のタイプ

プロジェクトに依存関係を追加するには、build.gradle ファイルの dependencies ブロックで、implementation などの依存関係コンフィグレーションを指定します。

たとえば、次に示すアプリ モジュールの build.gradle ファイルには 3 種類の依存関係が含まれています。

apply plugin: 'com.android.application'

android { ... }

dependencies {
    // Dependency on a local library module
    implementation project(":mylibrary")

    // Dependency on local binaries
    implementation fileTree(dir: 'libs', include: ['*.jar'])

    // Dependency on a remote binary
    implementation 'com.example.android:app-magic:12.3'
}

これらはそれぞれ異なるタイプのライブラリ依存関係をリクエストします。

ローカル ライブラリ モジュールへの依存関係

implementation project(':mylibrary')

これは、「mylibrary」という名前の Android ライブラリ モジュールへの依存関係を宣言しています（この名前は、settings.gradle ファイルの include: で定義されているライブラリ名と一致する必要があります）。アプリのビルド時に、ビルドシステムはライブラリ モジュールをコンパイルし、その結果を APK にパッケージ化します。

ローカル バイナリへの依存関係

implementation fileTree(dir: 'libs', include: ['*.jar'])

Gradle は、プロジェクトの module_name/libs/ ディレクトリ内の JAR ファイルへの依存関係を宣言します（Gradle は build.gradle ファイルへの相対パスを読み取るため）。

または、次のように個々のファイルを指定することもできます。

implementation files('libs/foo.jar', 'libs/bar.jar')

リモート バイナリへの依存関係

implementation 'com.example.android:app-magic:12.3'

これは、実際には次の省略形です。

implementation group: 'com.example.android', name: 'app-magic', version: '12.3'

これは、「com.example.android」名前空間グループ内に存在するバージョン 12.3 の「app-magic」ライブラリへの依存関係を宣言しています。

注: このようなリモートの依存関係には、Gradle がライブラリを検索するための適切なリモート リポジトリの宣言が必要です。ローカルにライブラリが存在している場合を除き、Gradle はビルドで必要になったときにリモートサイトからライブラリを取得します（[Sync Project with Gradle Files] をクリックしたときや、ビルドを実行したときなど）。

ネイティブ依存関係

Android Gradle プラグイン 4.0 以降、この記事に記載の方法でネイティブ依存関係をインポートすることもできます。

ネイティブ ライブラリを公開する AAR に依存することで、externalNativeBuild に使用されるビルドシステムが、そのライブラリを自動的に使用できるようになります。コードからそのライブラリにアクセスするには、ネイティブ ビルド スクリプト内でライブラリにリンクする必要があります。詳細については、ネイティブ依存関係を使用するをご覧ください。

依存関係コンフィグレーション

dependencies ブロックでは、複数の依存関係コンフィグレーションのうちのいずれか（前述の implementation など）を使ってライブラリ依存関係を宣言できます。それぞれの依存関係コンフィグレーションは、依存関係の使用方法について Gradle にさまざまな指示を与えます。以下の表で、Android プロジェクトで依存関係に使用できる各コンフィグレーションについて説明します。 この表は、Android Gradle プラグイン 3.0.0 でサポートが終了したコンフィグレーションとの対応も示しています。

dependencies {
  // Executes lint checks from the ':checks' project
  // at build time.
  lintChecks project(':checks')
  // Compiles lint checks from the ':checks-to-publish'
  // into a lint.jar file and publishes it to your
  // Android library.
  lintPublish project(':checks-to-publish')
}

上記のコンフィグレーションにより、すべてのビルド バリアントに依存関係が適用されます。これに対し、特定のビルド バリアントのソースセットまたはテスト用のソースセットのみに依存関係を宣言する場合は、コンフィグレーション名の先頭を大文字にして、その先頭に対象のビルド バリアントまたはテスト用のソースセットの名前を付加する必要があります。

たとえば、「free」プロダクト フレーバーのみに（リモート バイナリ依存関係を使って）implementation 依存関係を追加する場合は、次のようにします。

dependencies {
    freeImplementation 'com.google.firebase:firebase-ads:9.8.0'
}

ただし、プロダクト フレーバーとビルドタイプを組み合わせたバリアントに依存関係を追加する場合は、configurations ブロックでコンフィグレーション名を初期化する必要があります。次のサンプルでは、「freeDebug」ビルド バリアントに（ローカル バイナリ依存関係を使って）runtimeOnly 依存関係を追加しています。

configurations {
    // Initializes a placeholder for the freeDebugRuntimeOnly dependency
    // configuration.
    freeDebugRuntimeOnly {}
}

dependencies {
    freeDebugRuntimeOnly fileTree(dir: 'libs', include: ['*.jar'])
}

ローカルテストとインストゥルメント テストに implementation 依存関係を追加する場合は、次のようになります。

dependencies {
    // Adds a remote binary dependency only for local tests.
    testImplementation 'junit:junit:4.12'

    // Adds a remote binary dependency only for the instrumented test APK.
    androidTestImplementation 'com.android.support.test.espresso:espresso-core:3.0.2'
}

ただしこの状況では、一部のコンフィグレーションは効果がありません。たとえば、他のモジュールが androidTest に依存できないため、androidTestApi コンフィグレーションを使用すると、以下の警告が表示されます。

WARNING: Configuration 'androidTestApi' is obsolete and has been replaced with
'androidTestImplementation'.

アノテーション プロセッサを追加する

アノテーション プロセッサをコンパイル クラスパスに追加すると、次のようなエラー メッセージが表示されます。

Error: Annotation processors must be explicitly declared now.

このエラーを解決するには、次のように annotationProcessor を使用して依存関係を構成し、プロジェクトにアノテーション プロセッサを追加します。

dependencies {
    // Adds libraries defining annotations to only the compile classpath.
    compileOnly 'com.google.dagger:dagger:version-number'
    // Adds the annotation processor dependency to the annotation processor classpath.
    annotationProcessor 'com.google.dagger:dagger-compiler:version-number'
}

注: Android Plugin for Gradle 3.0.0 以降では、android-apt プラグインはサポートされなくなりました。

アノテーション プロセッサに引数を渡す

アノテーション プロセッサに引数を渡す必要がある場合は、モジュールのビルド構成で AnnotationProcessorOptions ブロックを使用します。たとえば、Key-Value ペアとしてプリミティブ データ型を渡す場合は、次のように argument プロパティを使用できます。

android {
    ...
    defaultConfig {
        ...
        javaCompileOptions {
            annotationProcessorOptions {
                argument "key1", "value1"
                argument "key2", "value2"
            }
        }
    }
}

ただし、Android Gradle プラグイン 3.2.0 以降を使用している場合は、Gradle の CommandLineArgumentProvider インターフェースを使用して、ファイルまたはディレクトリを表すプロセッサ引数を渡す必要があります。

アプリ デベロッパーやアノテーション プロセッサの作成者は CommandLineArgumentProvider を使用することで、増分ビルド プロパティ型のアノテーションを各引数に適用して、増分ビルドとキャッシュに保存されたクリーンビルドの正確性やパフォーマンスを改善できます。

たとえば、次のクラスは CommandLineArgumentProvider を実装し、プロセッサの各引数にアノテーションを追加しています。また、このサンプルは Groovy 言語の構文を使用し、モジュールの build.gradle ファイルに直接組み込まれています。

class MyArgsProvider implements CommandLineArgumentProvider {

    // Annotates each directory as either an input or output for the
    // annotation processor.
    @InputFiles
    // Using this annotation helps Gradle determine which part of the file path
    // should be considered during up-to-date checks.
    @PathSensitive(PathSensitivity.RELATIVE)
    FileCollection inputDir

    @OutputDirectory
    File outputDir

    // The class constructor sets the paths for the input and output directories.
    MyArgsProvider(FileCollection input, File output) {
        inputDir = input
        outputDir = output
    }

    // Specifies each directory as a command line argument for the processor.
    // The Android plugin uses this method to pass the arguments to the
    // annotation processor.
    @Override
    Iterable<String> asArguments() {
        // Use the form '-Akey[=value]' to pass your options to the Java compiler.
        ["-AinputDir=${inputDir.singleFile.absolutePath}",
         "-AoutputDir=${outputDir.absolutePath}"]
    }
}

android {...}

CommandLineArgumentProvider を実装するクラスを作成したら、そのクラスを初期化し、次に示すように annotationProcessorOptions.compilerArgumentProvider プロパティを使用して Android プラグインに渡す必要があります。

// This is in your module's build.gradle file.
android {
    defaultConfig {
        javaCompileOptions {
            annotationProcessorOptions {
                // Creates a new MyArgsProvider object, specifies the input and
                // output paths for the constructor, and passes the object
                // to the Android plugin.
                compilerArgumentProvider new MyArgsProvider(files("input/path"),
                                         new File("output/path"))
            }
        }
    }
}

CommandLineArgumentProvider の実装を通じてビルドのパフォーマンスを改善する方法について詳しくは、Java プロジェクトのキャッシュをご覧ください。

アノテーション プロセッサによるエラーチェックを無効にする

コンパイル クラスパスの依存関係に不要なアノテーション プロセッサが含まれている場合は、build.gradle ファイルに次の内容を追加することでエラーチェックを無効にできます。コンパイル クラスパスに追加するアノテーション プロセッサは、まだプロセッサ クラスパスに追加されていない点に注意してください。

android {
    ...
    defaultConfig {
        ...
        javaCompileOptions {
            annotationProcessorOptions {
                includeCompileClasspath false
            }
        }
    }
}

プロジェクトのアノテーション プロセッサをプロセッサ クラスパスに移行した後に問題が発生する場合は、includeCompileClasspath を true に設定することで、コンパイル クラスパスのアノテーション プロセッサを許容できます。ただし、このプロパティを true に設定することは推奨されません。Android プラグインの将来のアップデートで、この設定は使用できなくなります。

推移的依存関係を除外する

アプリの規模が大きくなるにつれ、直接的な依存関係や推移的な依存関係（アプリがインポートしたライブラリが依存するライブラリ）など、多くの依存関係が含まれる可能性があります。不要になった推移的な依存関係を除外するには、次のように exclude キーワードを使用します。

dependencies {
    implementation('some-library') {
        exclude group: 'com.example.imgtools', module: 'native'
    }
}

推移的依存関係をテスト コンフィグレーションから除外する

テスト時に、特定の推移的な依存関係を除外する必要がある場合、上記のコードサンプルは期待どおりに動作しない可能性があります。これは、テスト コンフィグレーション（androidTestImplementation など）がモジュールの implementation コンフィグレーションを拡張するためです。つまり、Gradle がコンフィグレーションを解決するときに、implementation 依存関係が常に含まれます。

よって、テスト時に推移的な依存関係を除外するには、次のようにして実行時に除外します。

android.testVariants.all { variant ->
    variant.getCompileConfiguration().exclude group: 'com.jakewharton.threetenabp', module: 'threetenabp'
    variant.getRuntimeConfiguration().exclude group: 'com.jakewharton.threetenabp', module: 'threetenabp'
}

注: 依存関係の除外セクションの元のコードサンプルに示されている依存関係ブロックで exclude キーワードを使用して、テスト コンフィグレーションに固有で、他のコンフィグレーションに含まれていない推移的な依存関係を省略することもできます。

バリアント認識型の依存関係管理を使用する

Android プラグイン 3.0.0 以降に含まれている新しい依存関係メカニズムでは、ライブラリの使用時に自動でバリアントのマッチングを行います。つまり、アプリの debug バリアントによって自動的にライブラリの debug バリアントが使用されます。これはフレーバーの使用時にも当てはまるため、アプリの freeDebug バリアントによってライブラリの freeDebug バリアントが使用されることになります。

バリアントのマッチングが正しく行われるためには、直接的なマッチングが不可能な場合のために代替のマッチング手段を提供する必要があります。アプリで「staging」というビルドタイプを構成しているにもかかわらず、そのライブラリ依存関係に「staging」が含まれていない場合は、プラグインでアプリの「staging」バージョンをビルドしようとしたときに、どのバージョンのライブラリを使用すべきかを判断できません。そのため、次のようなエラー メッセージが表示されます。

Error:Failed to resolve: Could not resolve project :mylibrary.
Required by:
    project :app

バリアント マッチングに関連するビルドエラーを解決する

アプリと依存関係との直接的なバリアント マッチングが不可能な状況において、Gradle での処理方法を制御するには、プラグインに含まれる DSL 要素が便利です。バリアント識別依存関係マッチングに関連する特定のビルドエラーを解決する際に使用する DSL プロパティを決めるには、以下の表を参考にしてください。

// In the app's build.gradle file.
android {
    buildTypes {
        debug {}
        release {}
        staging {
            // Specifies a sorted list of fallback build types that the
            // plugin should try to use when a dependency does not include a
            // "staging" build type. You may specify as many fallbacks as you
            // like, and the plugin selects the first build type that's
            // available in the dependency.
            matchingFallbacks = ['debug', 'qa', 'release']
        }
    }
}

// In the app's build.gradle file.
android {
    defaultConfig{
    // Do not configure matchingFallbacks in the defaultConfig block.
    // Instead, you must specify fallbacks for a given product flavor in the
    // productFlavors block, as shown below.
  }
    flavorDimensions 'tier'
    productFlavors {
        paid {
            dimension 'tier'
            // Because the dependency already includes a "paid" flavor in its
            // "tier" dimension, you don't need to provide a list of fallbacks
            // for the "paid" flavor.
        }
        free {
            dimension 'tier'
            // Specifies a sorted list of fallback flavors that the plugin
            // should try to use when a dependency's matching dimension does
            // not include a "free" flavor. You may specify as many
            // fallbacks as you like, and the plugin selects the first flavor
            // that's available in the dependency's "tier" dimension.
            matchingFallbacks = ['demo', 'trial']
        }
    }
}

// In the app's build.gradle file.
android {
    defaultConfig{
    // Specifies a sorted list of flavors that the plugin should try to use from
    // a given dimension. The following tells the plugin that, when encountering
    // a dependency that includes a "minApi" dimension, it should select the
    // "minApi18" flavor. You can include additional flavor names to provide a
    // sorted list of fallbacks for the dimension.
    missingDimensionStrategy 'minApi', 'minApi18', 'minApi23'
    // You should specify a missingDimensionStrategy property for each
    // dimension that exists in a local dependency but not in your app.
    missingDimensionStrategy 'abi', 'x86', 'arm64'
    }
    flavorDimensions 'tier'
    productFlavors {
        free {
            dimension 'tier'
            // You can override the default selection at the product flavor
            // level by configuring another missingDimensionStrategy property
            // for the "minApi" dimension.
            missingDimensionStrategy 'minApi', 'minApi23', 'minApi18'
        }
        paid {}
    }
}

Wear OS アプリ依存関係を構成する

Wear OS モジュールの依存関係の構成方法は、他のモジュールの場合と同様です。つまり、implementation や compileOnly など、同じ依存関係コンフィグレーションを使用します。

Wear モジュールでは、バリアント識別による依存関係の管理も使用できます。 そのため、アプリのベース モジュールに Wear モジュールとの依存関係がある場合、ベース モジュールの各バリアントは、Wear モジュールの対応するバリアントを使用します。1 つの Wear モジュールとの依存関係のみを持つ簡単なアプリをビルドしていて、そのモジュールがベース モジュールと同じバリアントを構成している場合、ベース モジュールの build.gradle ファイルに次のように wearApp コンフィグレーションを指定する必要があります。

dependencies {
    // If the main and Wear app modules have the same variants,
    // variant-aware dependency management automatically matches
    // variants of the main app module with that of the wear module.
    wearApp project(':wearable')
}

複数の Wear モジュールがあり、アプリのフレーバーごとに異なる Wear モジュールを指定する場合は、以下のように flavorWearApp コンフィグレーションを使用して指定できます（ただし、wearApp コンフィグレーションを使用する他の依存関係を含めることはできません）。

dependencies {
    paidWearApp project(':wear1')
    demoWearApp project(':wear1')
    freeWearApp project(':wear2')
}

リモート リポジトリ

ローカル ライブラリまたはファイルツリー以外の依存関係がある場合、Gradle は build.gradle ファイルの repositories ブロックで指定されたすべてのオンライン リポジトリでファイルを探します。リストでのリポジトリの配置順により、各プロジェクトの依存関係について、Gradle がリポジトリを検索する順番が決まります。たとえば、ある依存関係がリポジトリ A とリポジトリ B の両方で使用でき、リストで A が最初に記述されている場合、Gradle はその依存関係をリポジトリ A からダウンロードします。

新規の Android Studio プロジェクトではデフォルトで、プロジェクトの最上位の build.gradle ファイルで、以下に示すように Google の Maven リポジトリと JCenter がリポジトリの場所として指定されています。

allprojects {
    repositories {
        google()
        jcenter()
    }
}

Maven セントラル リポジトリから取得するものがある場合は、mavenCentral() を追加します。ローカル リポジトリの場合は、mavenLocal() を使用します。

allprojects {
    repositories {
        google()
        jcenter()
        mavenCentral()
        mavenLocal()
    }
}

または、次のようにして特定の Maven または Ivy リポジトリを宣言することもできます。

allprojects {
    repositories {
        maven {
            url "https://repo.example.com/maven2"
        }
        maven {
            url "file://local/repo/"
        }
        ivy {
            url "https://repo.example.com/ivy"
        }
    }
}

詳しくは、Gradle リポジトリ ガイドをご覧ください。

Google の Maven リポジトリ

以下の Android ライブラリの最新バージョンを Google の Maven リポジトリから入手できます。

• Android サポート ライブラリ
• アーキテクチャ コンポーネント ライブラリ
• Constraint Layout ライブラリ
• AndroidX Test
• データ バインディング ライブラリ
• Android Instant App ライブラリ
• Wear OS
• Google Play 開発者サービス
• Google Play 請求サービス ライブラリ
• Firebase

すべての利用可能なアーティファクトは、Google の Maven リポジトリ インデックスで確認できます（下のプログラムからのアクセスをご覧ください）。

上記のライブラリのいずれかをビルドに追加するには、最上位の build.gradle ファイル内に Google の Maven リポジトリを組み込みます。

allprojects {
    repositories {
        google()

        // If you're using a version of Gradle lower than 4.1, you must instead use:
        // maven {
        //     url 'https://maven.google.com'
        // }
        // An alternative URL is 'https://dl.google.com/dl/android/maven2/'
    }
}

次に、目的のライブラリをモジュールの dependencies ブロックに追加します。 たとえば、appcompat ライブラリの場合は次のようになります。

dependencies {
    implementation 'com.android.support:appcompat-v7:28.0.0'
}

ただし、上記のライブラリの古いバージョンを使おうとして依存関係を解決できなかった場合は、Maven リポジトリからは入手できないため、オフライン リポジトリからライブラリを入手する必要があります。

プログラムからのアクセス

Google の Maven アーティファクトにプログラムからアクセスするために、XML 形式のアーティファクト グループのリストを maven.google.com/master-index.xml から取得できます。そうすると、次のファイルから任意のグループのライブラリ名とバージョンを確認できます。

maven.google.com/group_path/group-index.xml

たとえば、android.arch.lifecycle グループのライブラリは、maven.google.com/android/arch/lifecycle/group-index.xml にリストされています。

また、以下から POM ファイルと JAR ファイルをダウンロードすることもできます。

maven.google.com/group_path/library/version/library-version.ext

例: maven.google.com/android/arch/lifecycle/compiler/1.0.0/compiler-1. 0.0.pom

SDK Manager のオフライン リポジトリ

Google Maven リポジトリから入手できないライブラリ（古いバージョンのライブラリなど）の場合は、SDK Manager からオフライン Google Repository パッケージをダウンロードする必要があります。

その後は通常どおり、dependencies ブロックにライブラリを追加できます。

オフライン ライブラリは android_sdk/extras/ に保存されます。

依存関係の順序

依存関係は、記述された順序に応じてそれぞれの優先度が指定されます。たとえば、1 番目のライブラリは 2 番目のライブラリより優先度が高く、2 番目は 3 番目より優先度が高くなります。この順序は、ライブラリからアプリにリソースを統合する場合、またはマニフェスト要素を統合する場合に重要です。

たとえば、プロジェクトで以下の宣言がされているとします。

• LIB_A への依存関係と LIB_B への依存関係（この順序）
• LIB_A は LIB_C と LIB_D に依存（この順序）
• LIB_B も LIB_C に依存

この場合、依存関係の順序を展開すると次のようになります。

1. LIB_A
2. LIB_D
3. LIB_B
4. LIB_C

これにより、LIB_A と LIB_B はいずれも LIB_C より優先され、LIB_D は LIB_B よりも優先度が高くなります。これは、依存元の LIB_A の優先度が LIB_B より高いためです。

異なるプロジェクトのソースや依存関係のマニフェストをマージする方法については、複数のマニフェスト ファイルをマージするをご覧ください。

モジュールの依存関係を表示する

直接的な依存関係の中には、独自の依存関係を持つものもあります。これは、推移的な依存関係と呼ばれています。推移的な各依存関係を手動で宣言しなくても、Gradle ではこれらの依存関係が自動的に収集され、追加されます。Android Plugin for Gradle では、Gradle が特定のモジュールに対して解決する依存関係のリストを表示するタスクを提供しています。

また、各モジュールのレポートでは、ビルド バリアント、テスト ソースセット、クラスパスに基づいて依存関係がグループ化されます。以下に、アプリ モジュールのデバッグビルド バリアントのランタイム クラスパスと、インストゥルメント化されたテスト ソースセットのコンパイル クラスパスのサンプル レポートを示します。

debugRuntimeClasspath - Dependencies for runtime/packaging
+--- :mylibrary (variant: debug)
+--- com.google.android.material:material:1.0.0@aar
+--- androidx.appcompat:appcompat:1.0.2@aar
+--- androidx.constraintlayout:constraintlayout:1.1.3@aar
+--- androidx.fragment:fragment:1.0.0@aar
+--- androidx.vectordrawable:vectordrawable-animated:1.0.0@aar
+--- androidx.recyclerview:recyclerview:1.0.0@aar
+--- androidx.legacy:legacy-support-core-ui:1.0.0@aar
...

debugAndroidTest
debugAndroidTestCompileClasspath - Dependencies for compilation
+--- androidx.test.ext:junit:1.1.0@aar
+--- androidx.test.espresso:espresso-core:3.1.1@aar
+--- androidx.test:runner:1.1.1@aar
+--- junit:junit:4.12@jar
...

このタスクを実行する手順は次のとおりです。

1. [View] > [Tool Windows] > [Gradle] を選択します（または、ツール ウィンドウ バーの Gradle アイコン をクリックします）。
2. AppName > [Tasks] > [android] の順に展開し、androidDependencies をダブルクリックします。Gradle がタスクを実行すると、[Run] ウィンドウが開いて出力が表示されます。

Gradle での依存関係の管理について詳しくは、Gradle ユーザーガイドの依存関係管理の基本をご覧ください。

依存関係解決エラーを修正する

アプリのプロジェクトに複数の依存関係を追加すると、それらの直接的または推移的な依存関係の間に競合が発生する可能性があります。Android Gradle プラグインは競合を適切に解決しようとしますが、一部の競合によりコンパイル時エラーまたは実行時エラーが発生することがあります。

どの依存関係がエラーの原因になっているかを調査するには、アプリの依存関係ツリーを検査し、複数回登場する依存関係または競合するバージョンを含む依存関係を探します。

重複する依存関係を簡単に見つけられない場合は、次のように Android Studio の UI を使用して、重複するクラスを含む依存関係を探します。

1. メニューバーから [Navigate] > [Class] を選択します。
2. ポップアップ検索ダイアログで、[Include non-project items] チェックボックスがオンになっていることを確認します。
3. ビルドエラーで表示されるクラスの名前を入力します。
4. このクラスを含む依存関係がないか結果を検査します。

次のセクションでは、依存関係の解決で発生する可能性のあるさまざまなタイプのエラーと、その修正方法について説明します。

重複クラスエラーを修正する

ランタイム クラスパスにクラスが複数回登場すると、次のようなエラーが発生します。

Program type already present com.example.MyClass

このエラーは通常、以下のいずれかの状況で発生します。

• バイナリ依存関係に含まれているライブラリが、直接的な依存関係としてアプリにも含まれている場合。たとえば、アプリでライブラリ A とライブラリ B に対する直接的な依存関係が宣言されているものの、すでにライブラリ A のバイナリにライブラリ B が含まれている場合などです。
  • この問題を解決するには、ライブラリ B を直接的な依存関係から削除します。
• アプリにローカル バイナリ依存関係があり、同じライブラリに対するリモート バイナリ依存関係も存在する場合。
  • この問題を解決するには、バイナリ依存関係の一方を削除します。

クラスパス間の競合を修正する

Gradle がコンパイル クラスパスを解決する際、まずランタイム クラスパスが解決され、その結果によりコンパイル クラスパスに追加する依存関係のバージョンが判定されます。つまり、ランタイム クラスパスにより、それ以降のクラスパスで同じ依存関係に必要なバージョン番号が決まります。

アプリのランタイム クラスパスは、アプリのテスト APK のランタイム クラスパスでの依存関係をマッチングする際に、Gradle が必要とするバージョン番号の決定にも関係します。クラスパスの階層関係を図 1 に示します。

図 1. 複数のクラスパスに登場する依存関係のバージョン番号は、この階層に基づいてマッチングされる必要があります。

たとえば、アプリに implementation 依存関係コンフィグレーションを使用するあるバージョンの依存関係が含まれており、ライブラリ モジュールに runtimeOnly コンフィグレーションを使用する別のバージョンの依存関係が含まれている場合、同じ依存関係の異なるバージョンが複数のクラスパスに登場する競合が発生することがあります。

Android Gradle プラグイン 3.3.0 以降では、ランタイム クラスパスとコンパイル クラスパスへの依存関係を解決する際に、その後の特定のバージョン競合を自動的に修正しようとします。たとえば、ランタイム クラスパスにライブラリ A バージョン 2.0 が含まれ、コンパイル クラスパスにライブラリ A バージョン 1.0 が含まれている場合、プラグインはコンパイル クラスパスへの依存関係を自動的にライブラリ A バージョン 2.0 にアップデートして、エラーを回避します。

ただし、ランタイム クラスパスにライブラリ A バージョン 1.0 が含まれ、コンパイル クラスパスにライブラリ A バージョン 2.0 が含まれている場合、プラグインはコンパイル クラスパスへの依存関係をライブラリ A バージョン 1.0 にダウングレードしないため、以下のようなエラーが発生します。

Conflict with dependency 'com.example.library:some-lib:2.0' in project 'my-library'.
Resolved versions for runtime classpath (1.0) and compile classpath (2.0) differ.

この問題を解決するには、以下のいずれかを行います。

• 必要なバージョンの依存関係を api 依存関係としてライブラリ モジュールに含めます。これにより、ライブラリ モジュールでは依存関係を宣言するだけになりますが、アプリ モジュールはその API に推移的にアクセスします。
• または、両方のモジュールに依存関係を宣言します。この場合、各モジュールが同じバージョンの依存関係を使用する必要があります。プロジェクト全体でプロパティの構成を行うことを考えて、プロジェクト全体で各依存関係のバージョンが一致するようにしてください。

カスタム ビルドロジックを適用する

このセクションでは、Android Gradle プラグインの拡張や独自のプラグインの作成に役立つトピックについて詳しく説明します。

バリアント依存関係をカスタム ロジックに公開する

ライブラリに、他のプロジェクトまたはサブプロジェクトで使用したい機能が含まれていることがあります。ライブラリの公開とは、ライブラリが他で使用できるようにするためのプロセスです。ライブラリは、コンパイル時および実行時にアクセスできる依存関係を制御できます。

各クラスパスの推移的な依存関係を保持するために、2 つの異なるコンフィグレーションを使用します。これらはライブラリの利用元により、以下のようにして使用される必要があります。

• variant_nameApiElements: このコンフィグレーションは、コンパイル時に使用できる推移的な依存関係を保持します。
• variant_nameRuntimeElements: このコンフィグレーションは、実行時に使用できる推移的な依存関係を保持します。

異なるコンフィグレーション間の関係について詳しくは、Java ライブラリ プラグイン コンフィグレーションをご覧ください。

カスタム依存関係の解決方針

同じライブラリの 2 つのバージョンへの依存関係がプロジェクトに含まれていることがあります。その場合、依存関係の競合が発生することがあります。たとえば、プロジェクトがモジュール A のバージョン 1 とモジュール B のバージョン 2 に依存し、モジュール A がモジュール B のバージョン 3 に推移的に依存している場合、依存関係のバージョン競合が発生します。

Android Gradle プラグインは、次のような依存関係の解決方針でこの競合を解決します。同じモジュールの異なるバージョンが依存関係グラフで見つかった場合、デフォルトでは、バージョン番号が最も大きいものを選択します。

ただしこの方針は、常に意図したとおりの結果になるとは限りません。依存関係の解決方針をカスタマイズするには、次のコンフィグレーションを使用して、タスクで必要なバリアントの特定の依存関係を解決します。

• variant_nameCompileClasspath: このコンフィグレーションでは、指定したバリアントのコンパイル クラスパスのための解決方針が指定されます。
• variant_nameRuntimeClasspath: このコンフィグレーションでは、指定したバリアントのランタイム クラスパスのための解決方針が指定されます。

Android Gradle プラグインには、各バリアントのコンフィグレーション オブジェクトにアクセスするための getter が用意されています。そのため、バリアント API を使用して、次の例のように依存関係の解決をクエリすることができます。

android {
    applicationVariants.all { variant ->
        // Return compile configuration objects of a variant.
        variant.getCompileConfiguration().resolutionStrategy {
        // Use Gradle's ResolutionStrategy API
        // to customize how this variant resolves dependencies.
            ...
        }
        // Return runtime configuration objects of a variant.
        variant.getRuntimeConfiguration().resolutionStrategy {
            ...
        }
        // Return annotation processor configuration of a variant.
        variant.getAnnotationProcessorConfiguration().resolutionStrategy {
            ...
        }
    }
}