Android Studio の Gradle ビルドシステムを使用すると、外部バイナリやその他のライブラリ モジュールを依存関係としてビルドに含めることができます。依存関係は、マシン上またはリモート リポジトリで見つけることができます。推移的な依存関係が宣言されている場合、それも自動的に含まれます。このページでは、Android Gradle プラグイン(AGP)に固有の動作や設定など、Android プロジェクトで依存関係を使用する方法について説明します。Gradle の依存関係の概念をより深く理解するには、依存関係管理に関する Gradle のガイドもご覧ください。ただし、Android プロジェクトでは、このページで定義されている依存関係構成のみを使用する必要があることにご注意ください。
ライブラリまたはプラグインの依存関係を追加する
ビルドの依存関係を追加して管理するには、バージョン カタログを使用することをおすすめします。これは、新しいプロジェクトでデフォルトで使用される方法です。このセクションでは、Android プロジェクトに使用される最も一般的なタイプの構成について説明します。その他のオプションについては、Gradle のドキュメントをご覧ください。バージョン カタログを使用するアプリの例については、Now in Android をご覧ください。バージョン カタログを使用せずにビルド依存関係がすでに設定されていて、マルチモジュール プロジェクトがある場合は、移行することをおすすめします。
ネイティブ依存関係の追加と管理(一般的ではありません)については、ネイティブ依存関係をご覧ください。
次の例では、リモート バイナリの依存関係(Jetpack Macrobenchmark ライブラリ)、ローカル ライブラリ モジュールの依存関係(myLibrary
)、プラグインの依存関係(Android Gradle プラグイン)をプロジェクトに追加します。これらの依存関係をプロジェクトに追加する一般的な手順は次のとおりです。
バージョン カタログ ファイルの
[versions]
セクションに、libs.versions.toml
という依存関係のバージョンのエイリアスを追加します([Project] ビューのgradle
ディレクトリまたは [Android] ビューの Gradle Scripts の下)。[versions] agp = "8.3.0" androidx-macro-benchmark = "1.2.2" my-library = "1.4" [libraries] ... [plugins] ...
エイリアスにはダッシュまたはアンダースコアを使用できます。これらのエイリアスにより、ビルド スクリプトで参照できるネストされた値が生成されます。参照は、カタログの名前(
libs.versions.toml
のlibs
部分)から始まります。単一のバージョン カタログを使用する場合は、デフォルト値の「libs」のままにすることをおすすめします。libs.versions.toml
ファイルの[libraries]
(リモート バイナリまたはローカル ライブラリ モジュールの場合)または[plugins]
(プラグインの場合)セクションに、依存関係のエイリアスを追加します。[versions] ... [libraries] androidx-benchmark-macro = { group = "androidx.benchmark", name = "benchmark-macro-junit4", version.ref = "androidx-macro-benchmark" } my-library = { group = "com.myapplication", name = "mylibrary", version.ref = "my-library" } [plugins] androidApplication = { id = "com.android.application", version.ref = "agp" }
一部のライブラリは、ライブラリ ファミリーとそのバージョンをグループ化した公開部品構成表(BOM)で利用できます。バージョン カタログとビルドファイルに BOM を追加し、BOM バージョンの管理を任せることができます。詳細については、部品構成表を使用するをご覧ください。
依存関係を必要とするモジュールのビルド スクリプトに、依存関係エイリアスへの参照を追加します。ビルド スクリプトから参照する場合は、エイリアスのアンダースコアとダッシュをドットに変換します。モジュール レベルのビルド スクリプトは次のようになります。
Kotlin
plugins { alias(libs.plugins.androidApplication) } dependencies { implementation(libs.androidx.benchmark.macro) implementation(libs.my.library) }
Groovy
plugins { alias 'libs.plugins.androidApplication' } dependencies { implementation libs.androidx.benchmark.macro implementation libs.my.library }
プラグイン参照では、カタログ名の後に
plugins
が含まれ、バージョン参照では、カタログ名の後にversions
が含まれます(バージョン参照は一般的ではありません。バージョン参照の例については、同じバージョン番号の依存関係をご覧ください)。ライブラリ参照にはlibraries
修飾子がないため、ライブラリ エイリアスの先頭にversions
やplugins
を使用できません。
依存関係を構成する
dependencies
ブロック内で、複数の依存関係コンフィグレーション(前述の implementation
など)のいずれかを使用してライブラリ依存関係を宣言できます。それぞれの依存関係構成は、依存関係の使用方法についてのさまざまな指示を Gradle に与えます。次の表に、Android プロジェクトで依存関係に使用できる各コンフィグレーションを示します。
設定 | 動作 |
---|---|
implementation |
Gradle は依存関係をコンパイル クラスパスに追加し、また依存関係をビルド出力にパッケージ化します。モジュールで implementation 依存関係を構成すると、コンパイル時にそのモジュールの依存関係が他のモジュールに漏洩しないように Gradle に通知されます。つまり、現在のモジュールに依存する他のモジュールでは、依存関係を利用できません。
|
api |
Gradle は依存関係をコンパイル クラスパスとビルド出力に追加します。モジュールに api 依存関係が含まれていると、モジュールがその依存関係を他のモジュールに推移的にエクスポートしようとしていることを Gradle に知らせます。これにより、実行時とコンパイル時の両方で依存関係を利用できるようになります。この構成は、他のアップストリーム コンシューマに推移的にエクスポートする必要がある依存関係でのみ使用してください。 |
compileOnly |
Gradle は依存関係をコンパイル クラスパスにのみ追加します(つまり、ビルド出力には追加されません)。これは、Android モジュールを作成しており、コンパイル時には依存関係が必要であるものの、実行時にはなくても構わない場合に便利です。たとえば、コンパイル時のアノテーションのみを含むライブラリ(通常はコードの生成に使用され、ビルド出力には含まれないことが多い)に依存している場合は、そのライブラリを compileOnly としてマークできます。
この構成を使用する場合は、実行時に依存関係が利用可能かどうかを確認する条件をライブラリ モジュールに含める必要があります。次に、依存関係が提供されていなくても構成が機能するように、その動作をスムーズに切り替える必要があります。これは、重要でない一時的な依存関係を追加しないことにより最終的なアプリのサイズを削減するのに役立ちます。
注: |
runtimeOnly |
Gradle は、実行時に使用できるように、ビルド出力だけに依存関係を追加します。つまり、コンパイル クラスパスには追加されません。
これは Android ではめったに使用されませんが、サーバーアプリではロギングを実装するためによく使用されます。たとえば、ライブラリで実装を含まない Logging API を使用できます。そのライブラリのコンシューマは、このライブラリを implementation 依存関係として追加し、実際のロギング実装に使用する runtimeOnly 依存関係を含めることができます。 |
ksp |
これらのコンフィグレーションにより、コード内のアノテーションやその他のシンボルをコンパイル前に処理するライブラリが提供されます。通常は、コードの検証や追加のコードの生成を行うことで、記述する必要があるコードが削減されます。 このような依存関係を追加するには、 JAR ファイルに次のファイルが含まれる場合、Android Gradle プラグインは、依存関係がアノテーション プロセッサであると想定します。
プラグインは、コンパイル クラスパス上のアノテーション プロセッサを検出すると、ビルドエラーを生成します。
使用する構成を決定する際は、次の点を考慮してください。
アノテーション プロセッサの使用の詳細については、アノテーション プロセッサを追加するをご覧ください。 |
lintChecks |
Android アプリ プロジェクトのビルド時に Gradle に実行させる lint チェックを含むライブラリを含めるには、このコンフィグレーションを使用します。
|
lintPublish |
Gradle で lint チェックを lint.jar ファイルにコンパイルして AAR にパッケージ化するには、Android ライブラリ プロジェクトでこの構成を使用します。これにより、AAR を使用するプロジェクトもそれらの lint チェックを適用するようになります。以前に lintChecks 依存関係構成を使用して公開 AAR に lint チェックを含めていた場合は、その依存関係を移行して、代わりに lintPublish 構成を使用する必要があります。
Kotlindependencies { // 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")) } Groovydependencies { // 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') } |
特定のビルド バリアントの依存関係を設定する
上記の構成はすべて、すべてのビルド バリアントに依存関係を適用します。特定のビルド バリアント ソースセットまたはテスト ソースセットのみの依存関係を宣言する場合は、構成名の先頭を大文字にし、先頭にビルド バリアント ソースセットまたはテスト ソースセットの名前を付加する必要があります。
たとえば、implementation
コンフィグレーションを使用してリモート バイナリ依存関係を「free」プロダクト フレーバーのみに追加するには、次のようにします。
Kotlin
dependencies { freeImplementation("com.google.firebase:firebase-ads:21.5.1") }
Groovy
dependencies { freeImplementation 'com.google.firebase:firebase-ads:21.5.1' }
ただし、プロダクト フレーバーとビルドタイプを組み合わせたバリアントの依存関係を追加する場合は、設定名を初期化する必要があります。
Kotlin
// Initializes a placeholder for the freeDebugImplementation dependency configuration. val freeDebugImplementation by configurations.creating dependencies { freeDebugImplementation(project(":free-support")) }
Groovy
configurations { // Initializes a placeholder for the freeDebugImplementation dependency configuration. freeDebugImplementation {} } dependencies { freeDebugImplementation project(":free-support") }
ローカルテストとインストルメンテーション テストに implementation
依存関係を追加するには、次のようにします。
Kotlin
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("androidx.test.espresso:espresso-core:3.5.1") }
Groovy
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 'androidx.test.espresso:espresso-core:3.5.1' }
ただし、この状況では、一部の構成は効果がありません。たとえば、他のモジュールが androidTest
に依存できないため、androidTestApi
構成を使用すると、以下の警告が表示されます。
WARNING: Configuration 'androidTestApi' is obsolete and has been replaced with 'androidTestImplementation'.
依存関係の順序
依存関係をリストする順序は、それぞれの優先度を示します。たとえば、1 番目のライブラリは 2 番目のライブラリより優先度が高く、2 番目は 3 番目より優先度が高くなります。この順序は、ライブラリからアプリにリソースをマージする場合、またはマニフェスト要素をマージする場合に重要です。
たとえば、プロジェクトで以下を宣言したとします。
LIB_A
への依存関係とLIB_B
への依存関係(この順序)LIB_A
はLIB_C
とLIB_D
に依存(この順序)LIB_B
もLIB_C
に依存
この場合、依存関係の順序を展開すると次のようになります。
LIB_A
LIB_D
LIB_B
LIB_C
これにより、LIB_A
と LIB_B
はいずれも LIB_C
より優先され、LIB_D
は LIB_B
よりも優先度が高くなります。これは、依存元の LIB_A
の優先度が LIB_B
より高いためです。
異なるプロジェクトのソースや依存関係のマニフェストをマージする方法については、複数のマニフェスト ファイルをマージするをご覧ください。
Google Play Console の依存関係情報
アプリをビルドする際、AGP には、アプリにコンパイルされるライブラリ依存関係を記述するメタデータが含まれます。アプリをアップロードすると、Google Play Console はこのメタデータを検査して、SDK とアプリが使用する依存関係に関する既知の問題についてアラートを提供します。場合によっては、問題を解決するための実用的なフィードバックを提供します。
データは圧縮され、Google Play 署名鍵で暗号化され、リリースアプリの署名ブロックに保存されます。安全で優れたユーザー エクスペリエンスのために、この依存関係ファイルは保持することをおすすめします。オプトアウトするには、モジュールの build.gradle.kts
ファイルに次の dependenciesInfo
ブロックを含めます。
android {
dependenciesInfo {
// Disables dependency metadata when building APKs.
includeInApk = false
// Disables dependency metadata when building Android App Bundles.
includeInBundle = false
}
}
依存関係に関する Google のポリシーと潜在的な問題について詳しくは、アプリでサードパーティの SDK を使用する場合のサポートページをご覧ください。
SDK 分析情報
以下の問題に当てはまる場合、Android Studio では、Google Play SDK Index の公開 SDK について、バージョン カタログ ファイルと [Project Structure] ダイアログに lint 警告が表示されます。
- SDK は作成者によって古いものとしてマークされています。
- SDK が Google Play のポリシーに違反しています。
この警告は、そうした依存関係を更新する必要があることを知らせるものです。古いバージョンを使用すると、今後 Google Play Console に公開できなくなる可能性があります。
バージョン カタログを使用せずにビルド依存関係を追加する
依存関係の追加と管理にはバージョン カタログを使用することをおすすめしますが、単純なプロジェクトでは不要な場合もあります。バージョン カタログを使用しないビルドファイルの例を次に示します。
Kotlin
plugins { id("com.android.application") } android { ... } dependencies { // Dependency on a remote binary implementation("com.example.android:app-magic:12.3") // Dependency on a local library module implementation(project(":mylibrary")) }
Groovy
plugins { id 'com.android.application' } android { ... } dependencies { // Dependency on a remote binary implementation 'com.example.android:app-magic:12.3' // Dependency on a local library module implementation project(':mylibrary') }
このビルドファイルは、「com.example.android」名前空間グループ内で、「app-magic」ライブラリのバージョン 12.3 への依存関係を宣言しています。リモート バイナリの依存関係宣言は、次の省略形です。
Kotlin
implementation(group = "com.example.android", name = "app-magic", version = "12.3")
Groovy
implementation group: 'com.example.android', name: 'app-magic', version: '12.3'
ビルドファイルでは、「mylibrary」という名前の Android ライブラリ モジュールへの依存関係も宣言します。この名前は、settings.gradle.kts
ファイル内の include:
で定義されたライブラリ名と一致する必要があります。アプリのビルド時、ビルドシステムはライブラリ モジュールをコンパイルし、コンパイルしたコンテンツをアプリにパッケージ化します。
ビルドファイルでは、Android Gradle プラグイン(com.application.android
)への依存関係も宣言します。同じプラグインを使用する複数のモジュールがある場合、すべてのモジュールのビルド クラスパスに設定できるプラグインのバージョンは 1 つのみです。各モジュール ビルド スクリプトでバージョンを指定する代わりに、ルート ビルド スクリプトにバージョンと一緒にプラグインの依存関係を含め、プラグインを適用しないよう指示する必要があります。apply false
を追加すると、Gradle はプラグインのバージョンをメモしますが、ルートビルドでは使用しません。通常、この plugins
ブロックを除き、ルート ビルド スクリプトは空です。
Kotlin
plugins { id("org.jetbrains.kotlin.android") version "1.9.0" apply false }
Groovy
plugins { id ‘com.android.application’ version ‘8.3.0-rc02’ apply false }
単一モジュール プロジェクトの場合は、モジュール レベルのビルド スクリプトでバージョンを明示的に指定し、プロジェクト レベルのビルド スクリプトは空のままにすることができます。
Kotlin
plugins { id("com.android.application") version "8.3.0" }
Groovy
plugins { id 'com.android.application' version '8.3.0-rc02' }