Android Studio の Gradle ビルドシステムを使用すると、 バイナリや他のライブラリ モジュールを、依存関係としてビルドに追加します。依存関係は、マシン上またはリモート リポジトリで見つけることができます。推移的な依存関係が宣言されている場合、それも自動的に含まれます。このページでは、Android プロジェクトで依存関係を使用する方法について説明します。内容は次のとおりです。 アプリケーション固有の動作と構成に関する詳細を Android Gradle プラグイン(AGP)です。Gradle の依存関係の概念をより深く理解するには、依存関係管理に関する Gradle のガイドもご覧ください。ただし、Android プロジェクトでは、このページで定義されている依存関係構成のみを使用する必要があることにご注意ください。
ライブラリまたはプラグインの依存関係を追加する
ビルドの依存関係を追加して管理するには、バージョン カタログを使用するのが最善の方法です。 新規プロジェクトでデフォルトで使用されるメソッドです。このセクションでは、最も一般的な Android プロジェクトに使用される設定のタイプ詳しくは、 Gradle のドキュメント をご覧ください。バージョン カタログを使用するアプリの例については、以下をご覧ください。 Now in Android。 すでにビルド依存関係をセットアップしている場合 マルチモジュール プロジェクトがある場合は、 移行をご覧ください。
ネイティブ依存関係の追加と管理のガイダンス(一般的ではありません)については、 ネイティブ依存関係。
次の例では、リモート バイナリを
依存関係(Jetpack Macrobenchmark
ライブラリ)、ローカル ライブラリ モジュール
依存関係(myLibrary
)、プラグイン
依存関係(Android Gradle プラグイン)をプロジェクトに追加します。一般的な
依存関係をプロジェクトに追加する手順は次のとおりです。
モジュール内で必要な依存関係のバージョンのエイリアスを バージョン カタログ ファイルの
[versions]
セクション(libs.versions.toml
(gradle
ディレクトリの [Project] ビューまたは [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."[libraries]
に依存関係のエイリアスを追加します( (リモート バイナリやローカル ライブラリ モジュールなど)または[plugins]
( 各セクション(libs.versions.toml
ファイル内)で参照します。[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 を ビルドファイルを作成し、それらのバージョンを Google に管理させることができます。詳しくは、 詳しくは、部品構成表を使用するをご覧ください。
依存関係エイリアスへの参照を、アプリケーションのビルド スクリプトに追加する 依存関係を必要とするモジュールが存在します。エイリアスをアンダースコアとダッシュ ドットにドットを付けることができます。モジュール レベルのビルド スクリプト このようになります。
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
が含まれます(version 参照は一般的ではありません。Dependencies を参照 バージョン参照の例については、同じバージョン番号で作成してください)。ライブラリ 参照にlibraries
修飾子がないため、 ライブラリの先頭のversions
またはplugins
使用します。
依存関係を構成する
dependencies
ブロック内で、Terraform を使用してライブラリの依存関係を宣言できます。
いくつかの依存関係の設定(例: implementation
挙げられます)。それぞれの依存関係構成は、依存関係の使用方法についてのさまざまな指示を Gradle に与えます。次の表に、それぞれの Pod について
Android プロジェクトの依存関係に使用できる構成のリスト。
構成 | 動作 |
---|---|
implementation |
Gradle は依存関係をコンパイル クラスパスに追加し、また依存関係をビルド出力にパッケージ化します。Google
モジュールで implementation 依存関係が設定されている場合、
モジュールがコードをリークしないように Gradle に、
他のモジュールへの依存関係をコンパイルできます。つまり、この依存関係は
依存する他のモジュールでは、そのモジュールを使用でき、
説明します。
代わりにこの依存関係構成を使用すると、
|
api |
Gradle は依存関係をコンパイル クラスパスとビルド出力に追加します。モジュールに api 依存関係が含まれている場合、
モジュールが推移的にエクスポートすることを Gradle に知らせます。
他のモジュールに依存関係を渡して、モジュール レベルで
向上させることができます
この構成は慎重に、また依存関係が重要な場合のみ
他のアップストリーム コンシューマに推移的にエクスポートする必要がある場合。もし
|
compileOnly |
Gradle はコンパイル クラスパスにのみ依存関係を追加する
(つまり、ビルド出力には追加されません)。これは、
作成している Android モジュールで、依存関係が
実行時に追加することは任意です。対象
たとえば、コンパイル時のアノテーションのみを含むライブラリ(通常はコードの生成に使用され、ビルド出力には含まれないことが多い)に依存している場合は、そのライブラリを compileOnly としてマークできます。
この構成を使用する場合は、実行時に依存関係が利用可能かどうかを確認する条件をライブラリ モジュールに含める必要があります。次に、依存関係が提供されていなくても構成が機能するように、その動作をスムーズに切り替える必要があります。これは、重要でない一時的な依存関係を追加しないことにより最終的なアプリのサイズを削減するのに役立ちます。
注: |
runtimeOnly |
Gradle は、実行時に使用できるように、ビルド出力だけに依存関係を追加します。つまり、コンパイル クラスパスには追加されません。
Android ではめったに使用されませんが、サーバーでは一般的に使用されます。
ロギングの実装を提供します。たとえば、
含まれていない Logging API を使用できるため、
説明します。そのライブラリの利用者は、そのライブラリを
implementation 依存関係があり、
実際のロギングに対する runtimeOnly 依存関係
使用します。
|
ksp |
これらの構成により、アノテーションを処理するライブラリが提供されます。 などのシンボルをコード内で事前に記述する必要があります。通常、 コードの検証や追加コードの生成を行えるため、使用すべきコードが 記述する必要があります。 このような依存関係を追加するには、 JAR ファイルに次のファイルが含まれる場合、Android Gradle プラグインは、依存関係がアノテーション プロセッサであると想定します。
プラグインは、コンパイル クラスパス上のアノテーション プロセッサを検出すると、ビルドエラーを生成します。
使用する構成を決定する際は、次の点を考慮してください。 次のとおりです。
アノテーション プロセッサの使用の詳細については、以下をご覧ください。 アノテーション プロセッサを追加する。 |
lintChecks |
lint を含むライブラリをインクルードするには、この設定を使用します。 Android アプリのビルド時に Gradle が実行するチェック できます。 なお、 |
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') } |
特定のビルド バリアントの依存関係を設定する
上記の構成はすべて、すべてのビルド バリアントに依存関係を適用します。条件 代わりに、特定のビルドに対してのみ依存関係を宣言する場合 バリアントソースセットまたはテスト ソース用 「set」以外の値を使用する場合は、 ビルド バリアントまたはテスト ソースセットの名前をプレフィックスとして付加します。
たとえば、リモート バイナリの依存関係を「free」ファイルにのみ追加すると、
次のように implementation
設定を使用します。
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 にはライブラリを記述するメタデータが含まれます。 アプリにコンパイルされる必要があります。アプリをアップロードすると、Play の コンソールでは、このメタデータが検査され、SDK に関する既知の問題に対するアラートが提供されます。 し、場合によっては、実行可能なフィードバックを 解決できます
データは圧縮され、Google Play の署名鍵で暗号化されて
署名ブロックを使用します。この依存関係は保持することをおすすめします
安全なユーザー エクスペリエンスを実現してください。オプトアウトするには、
フォロー中
dependenciesInfo
モジュールの build.gradle.kts
ファイル内のブロックに追加します。
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 のバージョン カタログ ファイルと [Project [ストラクチャ] ダイアログ Google Play SDK Index(以下の問題に該当する場合):
- SDK は作成者によって古いものとしてマークされています。
- SDK が Google Play のポリシーに違反しています。
この警告は、依存関係の更新が必要であることを示すシグナルです。 古いバージョンを使用すると、Google Play で公開できなくなる可能性があります 使用することもできます。
バージョン カタログを使用せずにビルド依存関係を追加する
依存関係の追加と管理にはバージョン カタログを使用することをおすすめします。ただし、 必要ない可能性があります。この例は、Node.js の バージョン カタログ:
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') }
このビルドファイルは、「app-magic」バージョン 12.3 への依存関係を宣言しています。 「com.example.android」内にあります。名前空間グループです。リモート バイナリ 依存関係の宣言は、次の省略形です。
Kotlin
implementation(group = "com.example.android", name = "app-magic", version = "12.3")
Groovy
implementation group: 'com.example.android', name: 'app-magic', version: '12.3'
また、ビルドファイルでは、Android ライブラリ モジュール
"mylibrary";この名前は、include:
で定義されたライブラリ名と一致する必要があります。
settings.gradle.kts
ファイル。アプリをビルドすると、ビルドシステムは
ライブラリ モジュールをコンパイルし、その結果を
。
ビルドファイルでは、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 }
単一モジュール プロジェクトがある場合は、Terraform でバージョンを明示的に指定できます。 プロジェクト レベルのビルド スクリプトは空のままにしておきます。
Kotlin
plugins { id("com.android.application") version "8.3.0" }
Groovy
plugins { id 'com.android.application' version '8.3.0-rc02' }