ツールとライブラリの相互依存関係

ビルド依存関係は、プロジェクトを正常にビルドするために必要な外部コンポーネントです。ビルドは、ライブラリ、プラグイン、サブプロジェクト、Android SDK、Kotlin や Java コンパイラなどのツール、Android Studio などの開発環境、Gradle 自体に依存できます。

各依存関係自体に他の依存関係が必要な場合があります。こうした依存関係は推移的依存関係と呼ばれ、アプリケーションで使用される依存関係全体は急速に増加しています。ライブラリ、ツール、Android SDK など、依存関係をアップグレードすると、そのアップグレードが連鎖的に発生し、他の多くの依存関係もアップグレードされる可能性があります。

多くのライブラリはセマンティック バージョニングと呼ばれるスキームに従っているため、多くの場合、問題は発生しません。これらのライブラリは、下位バージョンとの互換性を確保するために、変更の種類を制限しています。

セマンティック バージョニングは major.minor.patch 形式に従います。たとえば、バージョン番号 4.8.3 では、4 が major バージョン、8 が minor バージョン、3 が patch 番号です。major 部分が変更されると、ライブラリの API または動作に破壊的な変更が生じる可能性があります。これにより、ビルドまたはアプリケーションの動作に影響する可能性があります。

minor（新機能）または patch（バグ修正）の部分が変更された場合、ライブラリ デベロッパーは、ライブラリが引き続き互換性があり、アプリに影響しないことを示しています。

このような変更に注意することが重要です。いくつかの依存関係のアップグレード ツールが役立ちます。

ビルド内の関係

Android ビルドには、次の間の関係が含まれます。

• ソースコード - 管理可能なコードとリソース
• ライブラリの依存関係 - ビルド時にプロジェクトとサブプロジェクトに含まれる外部ライブラリまたはモジュール
• ツール - ソースをアプリまたはライブラリに変換するコンパイラ、プラグイン、SDK

ソースコード

ソースコードは、アプリケーションまたはライブラリで記述する Kotlin または Java コードです。（C++ の使用方法については、Android NDK をご覧ください）。

ソースコードはライブラリ（Kotlin と Java のランタイム ライブラリを含む）と Android SDK に依存し、対応する Kotlin または Java コンパイラが必要です。

一部のソースコードには、追加の処理を必要とするアノテーションが含まれています。たとえば、Jetpack Compose コードを記述する場合は、Compose Kotlin コンパイラ プラグインによって処理される必要がある @Composable などのアノテーションを追加します。その他のアノテーションは、Kotlin Symbol Processor（KSP）または別のアノテーション処理ツールによって処理されます。

ライブラリの依存関係

ライブラリには、アプリの一部として取り込まれたバイトコードが含まれています。これは、Java JAR、Android ライブラリ（AAR）、ビルドのサブプロジェクトのいずれかです。多くのライブラリはセマンティック バージョニングに従っているため、アップグレード時に互換性が維持される（または維持されない）タイミングを把握できます。

ライブラリは、再利用のために他のライブラリに依存する場合があります。これは、推移的依存関係と呼ばれます。これにより、明示的に管理する必要がある依存関係が減ります。直接使用する依存関係を指定し、Gradle がそれらの推移的依存関係とともに pull します。直接依存関係をアップグレードすると、それらの推移的依存関係もアップグレードされる可能性があります。

ライブラリで、ランタイム（minSdk）またはコンパイル時（compileSdk）に Android SDK の最小バージョンが必要な場合があります。これは、ライブラリが Android SDK またはその提供の JDK API に含まれる関数を使用する場合に必要です。アプリの有効な minSdk は、アプリがリクエストする最も高い minSdk と、そのすべての直接的および推移的ライブラリ依存関係です。

一部のライブラリを使用するには、特定の Gradle プラグインが必要になる場合があります。これらのヘルパー プラグインは、多くの場合、Kotlin Symbol Processor やその他のアノテーション プロセッサをインストールします。これらのプロセッサは、ライブラリ機能の使用をサポートするためにコードを生成したり、ソースのコンパイルを変更したりします。たとえば、Jetpack Room には、アノテーションと KSP が含まれています。これらのアノテーションは、生成されたコードに変換され、データベース内のデータの取得と変更を行います。Jetpack Compose では、アノテーション付きの関数を変更して、その関数の再実行方法とタイミングを管理するために、Compose コンパイラ プラグインが必要です。

ツール

Gradle スコープ

Gradle は、ライブラリ依存関係をさまざまなスコープ（Gradle API では構成と呼ばれます）にグループ化します。これにより、ビルドのさまざまな部分で使用するライブラリ依存関係のセットを指定できます。たとえば、公開するアプリやライブラリには JUnit などのテスト ライブラリを含めない一方で、単体テストのビルドと実行時には含める場合などです。また、スコープを使用して、シンボルまたはアノテーション プロセッサを追加してコードを分析します。

たとえば、AGP は implementation スコープと api スコープを定義します。これは、サブプロジェクトのユーザーに依存関係を公開するかどうかを指定するための方法です。Android ビルドで使用されるこれらのスコープとその他のスコープの説明については、依存関係を構成するをご覧ください。

ビルドファイルの dependencies ブロックに、ライブラリ依存関係を group:artifact:version 文字列として追加します。

// In a module-level build script
// explicit dependency strings ("group:artifact:version")
dependencies {
    implementation("com.example:library1:1.2.3")
    api("com.example:library2:1.1.1")
}

// In a module-level build script
// explicit dependency strings ("group:artifact:version")
dependencies {
    implementation 'com.example:library1:1.2.3'
    api 'com.example:library2:1.1.1'
}

または バージョン カタログで次の操作を行います。

# Version catalog - gradle/libs.versions.toml
[versions]
exampleLib = "1.2.3"
examplePlugin = "2.3.4"

[libraries]
example-library = { group = "com.example", name = "library", version.ref = "exampleLib" }

[plugins]
example-plugin = { id = "com.example.plugin", version.ref = "examplePlugin" }

生成された変数をビルドファイルで指定します。

// In a module-level build script
// Using a version catalog
plugins {
    alias(libs.plugins.example.plugin)
}

dependencies {
    implementation(libs.example.library)
}

// In a module-level build script
// Using a version catalog
plugins {
    alias(libs.plugins.example.plugin)
}

dependencies {
    implementation libs.example.library
}