ビルド依存関係を追加する

Android Studio の Gradle ビルドシステムを使用すると、 バイナリや他のライブラリ モジュールを、依存関係としてビルドに追加します。依存関係は、マシン上またはリモート リポジトリで見つけることができます。推移的な依存関係が宣言されている場合、それも自動的に含まれます。このページでは、Android プロジェクトで依存関係を使用する方法について説明します。内容は次のとおりです。 アプリケーション固有の動作と構成に関する詳細を Android Gradle プラグイン(AGP)です。Gradle の依存関係の概念をより深く理解するには、依存関係管理に関する Gradle のガイドもご覧ください。ただし、Android プロジェクトでは、このページで定義されている依存関係構成のみを使用する必要があることにご注意ください。

ライブラリまたはプラグインの依存関係を追加する

ビルドの依存関係を追加して管理するには、バージョン カタログを使用するのが最善の方法です。 新規プロジェクトでデフォルトで使用されるメソッドです。このセクションでは、最も一般的な Android プロジェクトに使用される設定のタイプ詳しくは、 Gradle のドキュメント をご覧ください。バージョン カタログを使用するアプリの例については、以下をご覧ください。 Now in Android。 すでにビルド依存関係をセットアップしている場合 マルチモジュール プロジェクトがある場合は、 移行をご覧ください。

ネイティブ依存関係の追加と管理のガイダンス(一般的ではありません)については、 ネイティブ依存関係

次の例では、リモート バイナリを 依存関係Jetpack Macrobenchmark ライブラリ)、ローカル ライブラリ モジュール 依存関係myLibrary)、プラグイン 依存関係(Android Gradle プラグイン)をプロジェクトに追加します。一般的な 依存関係をプロジェクトに追加する手順は次のとおりです。

  1. モジュール内で必要な依存関係のバージョンのエイリアスを バージョン カタログ ファイルの [versions] セクション( libs.versions.tomlgradle ディレクトリの [Project] ビューまたは [Android] ビューの [Gradle Scripts]):

    [versions]
    agp = "8.3.0"
    androidx-macro-benchmark = "1.2.2"
    my-library = "1.4"
    
    [libraries]
    ...
    
    [plugins]
    ...
    

    エイリアスにはダッシュまたはアンダースコアを使用できます。これらのエイリアスにより、ネストされた値が生成されます。 ビルド スクリプトで参照できます。参照は名前で始まり、 カタログ。libs.versions.tomllibs の部分です。日時 単一のバージョン カタログを使用する場合は、デフォルト値の "libs."

  2. [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 に管理させることができます。詳しくは、 詳しくは、部品構成表を使用するをご覧ください。

  3. 依存関係エイリアスへの参照を、アプリケーションのビルド スクリプトに追加する 依存関係を必要とするモジュールが存在します。エイリアスをアンダースコアとダッシュ ドットにドットを付けることができます。モジュール レベルのビルド スクリプト このようになります。

    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 を使用すると、ビルド時間が大幅に短縮される可能性があります。 ビルドシステムで必要なモジュールの数が減るため 再コンパイルする必要があります。たとえば、implementation 変更すると、Gradle はその依存関係のみを再コンパイルします。 直接依存するモジュールについて説明します。ほとんどのアプリとテスト モジュールでこの構成を使用する必要があります。

api Gradle は依存関係をコンパイル クラスパスとビルド出力に追加します。モジュールに api 依存関係が含まれている場合、 モジュールが推移的にエクスポートすることを Gradle に知らせます。 他のモジュールに依存関係を渡して、モジュール レベルで 向上させることができます

この構成は慎重に、また依存関係が重要な場合のみ 他のアップストリーム コンシューマに推移的にエクスポートする必要がある場合。もし api 依存関係が外部 API、Gradle を変更する コンパイル時に、その依存関係にアクセスできるすべてのモジュールを再コンパイルします。 あります。api 依存関係が多数ある場合、 ビルド時間が大幅に増加します。なんらかの理由で ライブラリ モジュールは、代わりに依存関係の API を別のモジュールに implementation 依存関係を使用する。

compileOnly Gradle はコンパイル クラスパスにのみ依存関係を追加する (つまり、ビルド出力には追加されません)。これは、 作成している Android モジュールで、依存関係が 実行時に追加することは任意です。対象 たとえば、コンパイル時のアノテーションのみを含むライブラリ(通常はコードの生成に使用され、ビルド出力には含まれないことが多い)に依存している場合は、そのライブラリを compileOnly としてマークできます。

この構成を使用する場合は、実行時に依存関係が利用可能かどうかを確認する条件をライブラリ モジュールに含める必要があります。次に、依存関係が提供されていなくても構成が機能するように、その動作をスムーズに切り替える必要があります。これは、重要でない一時的な依存関係を追加しないことにより最終的なアプリのサイズを削減するのに役立ちます。

注: compileOnly Android Archive(AAR)依存関係を含む構成を示しています。

runtimeOnly Gradle は、実行時に使用できるように、ビルド出力だけに依存関係を追加します。つまり、コンパイル クラスパスには追加されません。 Android ではめったに使用されませんが、サーバーでは一般的に使用されます。 ロギングの実装を提供します。たとえば、 含まれていない Logging API を使用できるため、 説明します。そのライブラリの利用者は、そのライブラリを implementation 依存関係があり、 実際のロギングに対する runtimeOnly 依存関係 使用します。
ksp
kapt
annotationProcessor

これらの構成により、アノテーションを処理するライブラリが提供されます。 などのシンボルをコード内で事前に記述する必要があります。通常、 コードの検証や追加コードの生成を行えるため、使用すべきコードが 記述する必要があります。

このような依存関係を追加するには、kspkapt、または annotationProcessor 構成を使用して、アノテーション プロセッサ クラスパスに依存関係を追加する必要があります。これらを使用して、 コンパイル時と依存関係が分離されるため、ビルドのパフォーマンスが向上します。 クラスパスをアノテーション プロセッサ クラスパスから取り出します。Gradle が アノテーション プロセッサを使用すると、 <ph type="x-smartling-placeholder"></ph> コンパイル回避が実装されており、ビルド時間に悪影響を及ぼします(Gradle 5.0 以降では、コンパイル時に見つかったアノテーション プロセッサが無視される classpath など)が含まれます。

JAR ファイルに次のファイルが含まれる場合、Android Gradle プラグインは、依存関係がアノテーション プロセッサであると想定します。

META-INF/services/javax.annotation.processing.Processor

プラグインは、コンパイル クラスパス上のアノテーション プロセッサを検出すると、ビルドエラーを生成します。

ksp は Kotlin Symbol プロセッサであり、 Kotlin コンパイラ。

kaptapt は、 処理アノテーションを、Kotlin または Java コンパイラが実行される前に処理する必要があります。

使用する構成を決定する際は、次の点を考慮してください。 次のとおりです。

  • プロセッサが Kotlin Symbol プロセッサとして使用可能な場合は、次のコマンドを使用します。 ksp 依存関係として作成します。 kapt から ksp に移行するをご覧ください。 をご覧ください。
  • プロセッサが Kotlin Symbol プロセッサとして利用できない場合: <ph type="x-smartling-placeholder">
      </ph>
    • プロジェクトに Kotlin ソースが含まれている場合 Java ソースを含める)、 kapt を使用 含まれます。
    • プロジェクトで Java ソースのみを使用している場合は、 annotationProcessor

アノテーション プロセッサの使用の詳細については、以下をご覧ください。 アノテーション プロセッサを追加する

lintChecks

lint を含むライブラリをインクルードするには、この設定を使用します。 Android アプリのビルド時に Gradle が実行するチェック できます。

なお、lint.jarファイルを含む AAR は、 その lint.jar ファイルで定義されたチェックを自動的に実行する。 明示的な lintChecks 依存関係を追加する必要はありません。 これにより、ライブラリと関連する lint チェックを 1 つの関数で定義できます。 チェックが確実に実行されるよう、依存関係のチェックは ライブラリです。

lintPublish Gradle で lint チェックを lint.jar ファイルにコンパイルして AAR にパッケージ化するには、Android ライブラリ プロジェクトでこの構成を使用します。これにより、AAR を使用するプロジェクトもそれらの lint チェックを適用するようになります。以前に lintChecks 依存関係構成を使用して公開 AAR に lint チェックを含めていた場合は、その依存関係を移行して、代わりに lintPublish 構成を使用する必要があります。

Kotlin

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"))
}

Groovy

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')
}

特定のビルド バリアントの依存関係を設定する

上記の構成はすべて、すべてのビルド バリアントに依存関係を適用します。条件 代わりに、特定のビルドに対してのみ依存関係を宣言する場合 バリアントソースセットまたはテスト ソース用 「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_ALIB_CLIB_D に依存(この順序)
  • LIB_BLIB_C に依存

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

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

これにより、LIB_ALIB_B はいずれも LIB_C より優先され、LIB_DLIB_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'
}