KMP 用の Android Gradle ライブラリ プラグインを設定する

com.android.kotlin.multiplatform.library Gradle プラグインは、Kotlin Multiplatform(KMP) ライブラリ モジュールに Android ターゲットを追加するために公式に サポートされているツールです。プロジェクト構成を簡素化し、ビルド パフォーマンスを向上させ、Android Studio との統合を強化します。

KMP 開発に com.android.library プラグインを使用することは、Android Gradle プラグイン 9.0 以降(2025 年第 4 四半期)で非推奨となり、オプトインが必要となる Android Gradle プラグイン API に依存しています。これらの API は削除される予定です(Android Gradle プラグイン 10.0 (2026 年後半))。

このプラグインを適用するには、Android-KMP プラグインを適用する をご覧ください。以前の API から移行する必要がある場合は、移行 ガイドをご覧ください。

AGP 9.0 以降の移行については、エージェント スキル JetBrains が KMP アプリ用に作成したを使用できます。Android Studio でスキルを使用する方法について詳しくは、スキルを使用してエージェント モードを拡張するをご覧ください。AI の結果は完全に予測できるものではありません。

主な特長と相違点

Android-KMP プラグインは KMP プロジェクト専用に調整されており、いくつかの重要な点で標準の com.android.library プラグインとは異なります。

  • 単一バリアント アーキテクチャ: このプラグインは単一バリアントを使用し、プロダクト フレーバーとビルドタイプのサポートを削除することで、構成を簡素化し、ビルド パフォーマンスを向上させます。

  • KMP 向けに最適化: このプラグインは KMP ライブラリ向けに設計されており、共有 Kotlin コードと相互運用性に重点を置いています。Android 固有のネイティブ ビルド、AIDL、RenderScript のサポートは省略されています。

  • デフォルトでテストが無効: ビルド速度を向上させるため、ユニットテストとデバイス(インストルメンテーション)テストの両方がデフォルトで無効になっています。必要に応じて有効にできます。

  • 最上位の Android 拡張機能なし: 構成は Gradle KMP DSL 内の android ブロックで処理され、一貫した KMP プロジェクト構造が維持されます。最上位の android 拡張機能ブロックはありません。

  • オプトイン Java コンパイル: Java コンパイルはデフォルトで無効になっています。有効にするには、android ブロックで withJava() を使用します。これにより、Java コンパイルが不要な場合のビルド時間が短縮されます。

Android-KMP ライブラリ プラグインのメリット

Android-KMP プラグインは、KMP プロジェクトに次のメリットをもたらします。

  • ビルド パフォーマンスと安定性の向上: KMP プロジェクト内でビルド速度を最適化し、安定性を高めるように設計されています。KMP ワークフローに重点を置くことで、ビルド プロセスがより効率的かつ信頼性の高いものになります。

  • IDE 統合の強化: KMP Android ライブラリを使用する場合、コード補完、ナビゲーション、デバッグ、全体的なデベロッパー エクスペリエンスが向上します。

  • プロジェクト構成の簡素化: このプラグインは、ビルド バリアントなどの Android 固有の複雑さを排除することで、KMP プロジェクトの構成を簡素化します。これにより、ビルドファイルがよりクリーンで保守しやすくなります。 以前は、KMP プロジェクトで com.android.library プラグインを使用すると、androidAndroidTest などのわかりにくいソースセット名が作成されることがありました。この命名規則は、標準の KMP プロジェクト構造に慣れているデベロッパーにとっては直感的ではありませんでした。

サポートされていない機能の回避策

com.android.library プラグインとの KMP 統合と比較すると、com.android.kotlin.multiplatform.library プラグインには一部の機能がありません。サポートされていない機能の回避策は次のとおりです。

  • ビルド バリアント

    ビルドタイプとプロダクト フレーバーはサポートされていません。これは、新しいプラグインが単一バリアント アーキテクチャを使用しているため、構成が簡素化され、ビルド パフォーマンスが向上するためです。

    ビルド バリアントが必要な場合は、com.android.library プラグインを使用して別のスタンドアロン Android ライブラリ モジュールを作成し、そのモジュール内でビルドタイプとプロダクト フレーバーを構成してから、Kotlin Multiplatform ライブラリの androidMain ソースセットから標準のプロジェクト依存関係として使用することをおすすめします。 詳細については、Android ライブラリを作成するビルド バリアントを設定するをご覧ください。

  • データ バインディングとビュー バインディング

    これらは、Android View システムと XML レイアウトに密接に結合された Android 固有の UI フレームワーク機能です。新しい Android-KMP ライブラリ プラグインでは、 Compose Multiplatform などのマルチプラットフォーム フレームワークを使用して UI を処理することをおすすめします。データ バインディングとビュー バインディングは、共有可能なライブラリではなく、最終的な Android アプリの実装の詳細と見なされます。

  • ネイティブ ビルドのサポート

    新しいプラグインは、Android ターゲット用の標準 AAR の生成に重点を置いています。 Kotlin Multiplatform でのネイティブ コードの統合は、KMP 独自のネイティブ ターゲット(androidNativeArm64androidNativeX86 など)とその C 相互運用機能によって直接処理されます。ネイティブ C/C++ コードを含める必要がある場合は、Android 固有の externalNativeBuild メカニズムを使用するのではなく、共通またはネイティブ ソースセットの一部として定義し、kotlin ブロック内で C 相互運用機能を構成する必要があります。

    または、externalNativeBuild を介したネイティブ ビルドのサポートが必要な場合は、ネイティブ コードを統合できる別のスタンドアロン com.android.library モジュールを作成し、そのスタンドアロン ライブラリを Kotlin Multiplatform ライブラリ プロジェクトの androidMain ソースセットから使用することをおすすめします。 詳細については、Android ライブラリを作成するプロジェクトに C / C++ コードを追加するをご覧ください。

  • BuildConfig クラス

    BuildConfig 機能は、複数のバリアント環境で最も役立ちます。新しい Kotlin Multiplatform ライブラリ プラグインはバリアントに依存せず、ビルドタイプとプロダクト フレーバーをサポートしていないため、この機能は実装されていません。代わりに、BuildKonfig プラグインまたは同様のコミュニティ ソリューションを使用して、すべてのターゲットのメタデータを生成することをおすすめします。

前提条件

com.android.kotlin.multiplatform.library プラグインを使用するには、プロジェクトが次の最小バージョン以上で構成されている必要があります。

  • Android Gradle プラグイン(AGP): 8.10.0
  • Kotlin Gradle プラグイン(KGP): 2.0.0

既存のモジュールに Android-KMP プラグインを適用する

Android-KMP プラグインを既存の KMP ライブラリ モジュールに適用する手順は次のとおりです。

  1. バージョン カタログでプラグインを宣言します。バージョン カタログの TOML ファイル(通常は gradle/libs.versions.toml)を開き、プラグイン定義セクションを追加します。

    # To check the version number of the latest Kotlin release, go to
    # https://kotlinlang.org/docs/releases.html
    
    [versions]
    androidGradlePlugin = "9.1.0"
    kotlin = "KOTLIN_VERSION"
    
    [plugins]
    kotlin-multiplatform = { id = "org.jetbrains.kotlin.multiplatform", version.ref = "kotlin" }
    android-kotlin-multiplatform-library = { id = "com.android.kotlin.multiplatform.library", version.ref = "androidGradlePlugin" }
    
  2. ルート ビルドファイルでプラグイン宣言を適用します。プロジェクトのルート ディレクトリにある build.gradle.kts ファイルを開きます。apply false を使用して、プラグイン エイリアスを plugins ブロックに追加します。これにより、ルート プロジェクト自体にプラグイン ロジックを適用することなく、すべてのサブプロジェクトでプラグイン エイリアスを使用できるようになります。

    Kotlin

    // Root build.gradle.kts file
    
    plugins {
       alias(libs.plugins.kotlin.multiplatform) apply false
    
       // Add the following
       alias(libs.plugins.android.kotlin.multiplatform.library) apply false
    }

    Groovy

    // Root build.gradle file
    
    plugins {
       alias(libs.plugins.kotlin.multiplatform) apply false
    
       // Add the following
       alias(libs.plugins.android.kotlin.multiplatform.library) apply false
    }
  3. KMP ライブラリ モジュールのビルドファイルでプラグインを適用します。KMP ライブラリ モジュールの build.gradle.kts ファイルを開き、plugins ブロック内のファイルの先頭にプラグインを適用します。

    Kotlin

    // Module-specific build.gradle.kts file
    
    plugins {
       alias(libs.plugins.kotlin.multiplatform)
    
       // Add the following
       alias(libs.plugins.android.kotlin.multiplatform.library)
    }

    Groovy

    // Module-specific build.gradle file
    
    plugins {
       alias(libs.plugins.kotlin.multiplatform)
    
       // Add the following
       alias(libs.plugins.android.kotlin.multiplatform.library)
    }
  4. Android KMP ターゲットを構成します。Kotlin Multiplatform ブロック(kotlin)を構成して、Android ターゲットを定義します。kotlin ブロック内で、android を使用して Android ターゲットを指定します。

    Kotlin

    kotlin {
       android {
           namespace = "com.example.kmpfirstlib"
           compileSdk = 33
           minSdk = 24
    
           withJava() // enable java compilation support
           withHostTestBuilder {}.configure {}
           withDeviceTestBuilder {
               sourceSetTreeName = "test"
           }
    
           compilerOptions.configure {
               jvmTarget.set(
                   org.jetbrains.kotlin.gradle.dsl.JvmTarget.JVM_1_8
               )
           }
       }
    
       sourceSets {
           androidMain {
               dependencies {
                   // Add Android-specific dependencies here
               }
           }
           getByName("androidHostTest") {
               dependencies {
               }
           }
    
           getByName("androidDeviceTest") {
               dependencies {
               }
           }
       }
       // ... other targets (JVM, iOS, etc.) ...
    }

    Groovy

    kotlin {
       android {
           namespace = "com.example.kmpfirstlib"
           compileSdk = 33
           minSdk = 24
    
           withJava() // enable java compilation support
           withHostTestBuilder {}.configure {}
           withDeviceTestBuilder {
               it.sourceSetTreeName = "test"
           }
    
           compilerOptions.options.jvmTarget.set(
               org.jetbrains.kotlin.gradle.dsl.JvmTarget.JVM_1_8
           )
       }
    
       sourceSets {
           androidMain {
               dependencies {
               }
           }
           androidHostTest {
               dependencies {
               }
           }
           androidDeviceTest {
               dependencies {
               }
           }
       }
       // ... other targets (JVM, iOS, etc.) ...
    }
  5. 変更を適用します。プラグインを適用して kotlin ブロックを構成したら、Gradle プロジェクトを同期して変更を適用します。

従来のプラグインから移行する

このガイドでは、従来の com.android.library プラグインから com.android.kotlin.multiplatform.library プラグインに移行する方法について説明します。

1. ソースの移動

従来のプラグインでは、src/androidMainsrc/androidHostTestsrc/androidDeviceTest に加えて、src/mainsrc/testsrc/androidTest ソースセットを使用できました。新しいプラグインでは後者のソース ディレクトリのみを使用するため、src/main から src/androidMainsrc/test から src/androidHostTestsrc/androidTest から src/androidDeviceTest にソースを移動する必要があります。

2. 依存関係の宣言

一般的なタスクは、Android 固有のソースセットの依存関係を宣言することです。新しいプラグインでは、以前使用していた一般的な dependencies ブロックとは異なり、これらを sourceSets ブロック内に明示的に配置する必要があります。

Android-KMP

新しいプラグインでは、Android 依存関係を androidMain ソースセット内にグループ化することで、よりクリーンな構造を促進します。メインのソースセットに加えて、 オンデマンドで作成される 2 つのテスト ソースセット androidDeviceTestandroidHostTest があります(詳細については、ホストテストと デバイステストの構成をご覧ください)。

// build.gradle.kts

kotlin {
    android {}
    //... other targets

    sourceSets {
        commonMain.dependencies {
            implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core:1.8.0")
        }

        // Dependencies are now scoped to the specific Android source set
        androidMain.dependencies {
            implementation("androidx.appcompat:appcompat:1.7.0")
            implementation("com.google.android.material:material:1.11.0")
        }
    }
}

ソースセットには、対応する Kotlin コンパイルがあり、名前は maindeviceTest、 および hostTest です。ソースセットとコンパイルは、次のようにビルドスクリプトで構成できます。

// build.gradle.kts

kotlin {
    android {
        compilations.getByName("deviceTest") {
            kotlinOptions.languageVersion = "2.0"
        }
    }
}

従来のプラグイン

古いプラグインでは、最上位の依存関係ブロックで Android 固有の依存関係を宣言できました。これは、マルチプラットフォーム モジュールではわかりにくい場合があります。

// build.gradle.kts

kotlin {
  androidTarget()
  //... other targets
}

// Dependencies for all source sets were often mixed in one block
dependencies {
  // Common dependencies
  commonMainImplementation("org.jetbrains.kotlinx:kotlinx-coroutines-core:1.8.0")

  // Android-specific dependencies
  implementation("androidx.appcompat:appcompat:1.7.0")
  implementation("com.google.android.material:material:1.11.0")
}

3. Android リソースを有効にする

ビルド パフォーマンスを最適化するため、新しいプラグインでは Android リソース(res フォルダ)のサポートはデフォルトで有効になっていません。使用するにはオプトインする必要があります。この変更により、Android 固有のリソースを必要としないプロジェクトに、関連するビルド オーバーヘッドの負担がかからないようにします。

Android-KMP

Android リソース処理を明示的に有効にする必要があります。リソースは src/androidMain/res に配置する必要があります。

// build.gradle.kts

kotlin {
  android {
    // ...
    // Enable Android resource processing
    androidResources {
      enable = true
    }
  }
}

// Project Structure
// └── src
//     └── androidMain
//         └── res
//             ├── values
//             │   └── strings.xml
//             └── drawable
//                 └── icon.xml

従来のプラグイン

リソース処理はデフォルトで有効になっていました。src/mainres ディレクトリをすぐに追加して、XML ドローアブルや値などを追加できます。

// build.gradle.kts

android {
    namespace = "com.example.library"
    compileSdk = 34
    // No extra configuration was needed to enable resources.
}

// Project Structure
// └── src
//     └── main
//         └── res
//             ├── values
//             │   └── strings.xml
//             └── drawable
//                 └── icon.xml

4. ホストテストとデバイステストを構成する

新しいプラグインの大きな変更点は、Android ホスト側(ユニット)テストとデバイス側(インストルメンテーション)テストがデフォルトで無効になっている ことです。テスト ソースセットと構成を作成するには明示的にオプトインする必要があります。古いプラグインではこれらが自動的に作成されていました。

このオプトイン モデルは、プロジェクトをスリムに保ち、積極的に使用するビルドロジックとソースセットのみを含めるのに役立ちます。

Android-KMP

新しいプラグインでは、kotlin.android ブロック内でテストを有効にして構成します。これにより、設定がより明確になり、未使用のテスト コンポーネントの作成を回避できます。androidUnitTest ソースセットは androidHostTest になり(テスト ディレクトリが src/androidUnitTest から src/androidHostTest に変更されます)、androidInstrumentedTestandroidDeviceTest になります(テスト ディレクトリが src/androidInstrumentedTest から src/androidDeviceTest に変更されます)。

// build.gradle.kts

kotlin {
  android {
    // ...

    // Opt-in to enable and configure host-side (unit) tests
    withHostTest {
      isIncludeAndroidResources = true
    }

    // Opt-in to enable and configure device-side (instrumented) tests
    withDeviceTest {
      instrumentationRunner = "androidx.test.runner.AndroidJUnitRunner"
      execution = "HOST"
    }
  }
}

// Project Structure (After Opt-in)
// └── src
//     ├── androidHostTest
//     └── androidDeviceTest

従来のプラグイン

com.android.library プラグインでは、androidUnitTest ソースセットと androidInstrumentedTest ソースセットがデフォルトで作成されます。通常は testOptions DSL を使用して、android ブロック内で動作を構成します。

// build.gradle.kts

android {
  defaultConfig {
    // Runner was configured in defaultConfig
    testInstrumentationRunner = "androidx.test.runner.AndroidJUnitRunner"
  }

  testOptions {
    // Configure unit tests (for the 'test' source set)
    unitTests.isIncludeAndroidResources = true

    // Configure device tests (for the 'androidTest' source set)
    execution = "HOST"
  }
}

// Project Structure (Defaults)
// └── src
//     ├── test
//     └── androidTest

5. Java ソースのコンパイルを有効にする

KMP ライブラリで Android ターゲットの Java ソースをコンパイルする必要がある場合は、新しいプラグインでこの機能を明示的に有効にする必要があります。これにより、依存関係ではなく、プロジェクト内に直接配置された Java ファイルのコンパイルが有効になります。Java コンパイラと Kotlin コンパイラの JVM ターゲット バージョンを設定する方法も変更されます。

Android-KMP

withJava() を呼び出して、Java コンパイルをオプトインする必要があります。JVM ターゲットは、統合された設定のために kotlin { android {} } ブロック内で直接構成されるようになりました。ここで jvmTarget を設定すると、Android ターゲットの Kotlin コンパイルと Java コンパイルの両方に適用されます。

// build.gradle.kts

kotlin {
  android {
    //  Opt-in to enable Java source compilation
    withJava()
    // Configure the JVM target for both Kotlin and Java sources
    compilerOptions {
      jvmTarget.set(org.jetbrains.kotlin.gradle.dsl.JvmTarget.JVM_1_8)
    }
  }
  // ...
}

// Project Structure:
// └── src
//     └── androidMain
//         ├── kotlin
//         │   └── com/example/MyKotlinClass.kt
//         └── java
//             └── com.example/MyJavaClass.java

従来のプラグイン

Java コンパイルはデフォルトで有効になっていました。Java ソースと Kotlin ソースの JVM ターゲットは、compileOptions を使用して android ブロックで設定されていました。

// build.gradle.kts

android {
  // ...
  compileOptions {
    sourceCompatibility = JavaVersion.VERSION_1_8
    targetCompatibility = JavaVersion.VERSION_1_8
  }
}

kotlin {
  androidTarget {
    compilations.all {
      kotlinOptions.jvmTarget = "1.8"
    }
  }
}

6. androidComponents を使用してビルド バリアントを操作する

androidComponents 拡張機能は、ビルド アーティファクトをプログラムで操作するために引き続き使用できます。Variant API の多くは同じですが、 新しい AndroidKotlinMultiplatformVariant インターフェースは、 プラグインが単一のバリアントのみを生成するため、より制限されています。

そのため、ビルドタイプとプロダクト フレーバーに関連するプロパティは、バリアント オブジェクトで使用できなくなりました。

Android-KMP

onVariants ブロックは、単一のバリアントに対して反復処理を行うようになりました。nameartifacts などの共通プロパティには引き続きアクセスできますが、ビルドタイプ固有のプロパティにはアクセスできません。

// build.gradle.kts

androidComponents {
  onVariants { variant ->
      val artifacts = variant.artifacts
  }
}

従来のプラグイン

複数のバリアントを使用すると、ビルドタイプ固有のプロパティにアクセスしてタスクを構成できました。

// build.gradle.kts

androidComponents {
  onVariants(selector().withBuildType("release")) { variant ->
    // ...
  }
}

7. Android ライブラリの依存関係のバリアントを選択する

KMP ライブラリは、Android 用の単一バリアントを生成します。ただし、複数のバリアント(free/paid プロダクト フレーバーなど)を持つ標準の Android ライブラリ(com.android.library)に依存する場合があります。プロジェクトがその依存関係からバリアントを選択する方法を制御することは、一般的な要件です。

Android-KMP

新しいプラグインでは、このロジックが kotlin.android.localDependencySelection ブロック内で一元化され、明確になります。これにより、単一バリアント KMP ライブラリに選択される外部依存関係のバリアントが明確になります。

// build.gradle.kts
kotlin {
  android {
    localDependencySelection {
      // For dependencies with multiple build types, select 'debug' first, and 'release' in case 'debug' is missing
      selectBuildTypeFrom.set(listOf("debug", "release"))

      // For dependencies with a 'type' flavor dimension...
      productFlavorDimension("type") {
        // ...select the 'typeone' flavor.
        selectFrom.set(listOf("typeone"))
      }
    }
  }
}

従来のプラグイン

依存関係選択戦略は、buildTypes and productFlavors ブロック内で構成しました。多くの場合、missingDimensionStrategy を使用して、ライブラリにないディメンションのデフォルト フレーバーを指定したり、特定のフレーバー内で matchingFallbacks を使用して検索順序を定義したりしていました。

API の使用方法について詳しくは、一致エラーを解決するをご覧ください。

8. Compose プレビューの依存関係

通常、内部ツールが最終的な公開アーティファクトに漏洩しないように、特定のライブラリをローカル開発環境に限定する必要があります。新しい KMP Android プラグインでは、開発依存関係とリリースコードを分離するために使用されるビルドタイプ アーキテクチャが削除されるため、これは課題となります。

Android-KMP

ローカルでの開発とテストのみの依存関係を追加するには、メインの Android コンパイルのランタイム クラスパス構成(最上位の dependencies ブロック内)に依存関係を直接追加します。これにより、依存関係は実行時に使用できますが(Compose プレビューなどのツールの場合)、コンパイル クラスパスやライブラリの公開 API には含まれません。

// build.gradle.kts
dependencies {
  "androidRuntimeClasspath"(libs.androidx.compose.ui.tooling)
}

従来のプラグイン

Android ターゲットに com.android.library プラグインを使用する Kotlin Multiplatform プロジェクトでは、依存関係をデバッグ ビルドタイプに限定し、コンシューマが使用するライブラリのリリース バリアントに含まれないようにする debugImplementation 構成を使用する必要があります。

// build.gradle.kts
dependencies {
  debugImplementation(libs.androidx.compose.ui.tooling)
}

9. KMP Android ターゲットの JVM ターゲットを構成する

KMP Android プラグインは、android.compilerOptions.jvmTarget を使用して JVM ターゲットを設定します。これは Java と Kotlin の両方に適用され、純粋な Android プロジェクトの個別の compileOptions ブロックと kotlinOptions ブロックと比較して構成が簡素化されます。

Android-KMP

Android ターゲットを含む Kotlin Multiplatform(KMP)プロジェクトを使用する場合、Kotlin コンパイラと Java コンパイラの両方の JVM ターゲット バージョンを構成する方法はいくつかあります。プロジェクトのバイトコードの互換性を管理するには、これらの構成のスコープと階層を理解することが重要です。

JVM ターゲットを設定する主な方法は 3 つあり、優先度の低い順に並んでいます。優先度の高い JVM ターゲット値は、構成されたターゲットの小さいサブセットに適用され、優先度の低い値をオーバーライドします。つまり、プロジェクト内のターゲットとターゲット内のコンパイルごとに異なる JVM バージョンを設定できます。

Kotlin ツールチェーンを使用する(優先度が最も低い)

JVM ターゲットを設定する最も一般的な方法は、build.gradle.kts ファイルの kotlin ブロックでツールチェーンを指定することです。この方法では、Android を含む、プロジェクト内のすべての JVM ベースのターゲットに対して、Kotlin コンパイル タスクと Java コンパイル タスクの両方のターゲットを設定します。

// build.gradle.kts
kotlin {
    jvmToolchain(21)
}

この構成では、kotlincjavac の両方が JVM 21 をターゲットにします。プロジェクト全体で一貫したベースラインを確立するのに最適な方法です。

Android ターゲット レベルのコンパイラ オプションを使用する(優先度が中程度)

android ブロック内で、Android KMP ターゲットの JVM ターゲットを明示的に指定できます。この設定は、プロジェクト全体の jvmToolchain 構成をオーバーライドし、すべての Android コンパイルに適用されます。

// build.gradle.kts
kotlin {
    android {
        compilerOptions {
            jvmTarget.set(JvmTarget.JVM_11)
        }
    }
}

この場合、jvmToolchain が別のバージョンに設定されていても、Android ターゲットの Kotlin コードと Java コードは JVM 11 をターゲットにコンパイルされます。

コンパイル レベルのコンパイラ オプションを使用する(優先度が最も高い)

最も詳細な制御を行うには、コンパイルごとにコンパイラ オプションを構成します(androidMain または androidHostTest のみなど)。特定のコンパイルで別の JVM バージョンをターゲットにする必要がある場合に便利です。この設定は、Kotlin ツールチェーンと Android ターゲット レベルのオプションの両方をオーバーライドします。

// build.gradle.kts
kotlin {
    android {
        compilations.all {
            compileTaskProvider.configure {
                compilerOptions.jvmTarget.set(JvmTarget.JVM_11)
            }
        }
    }
}

この構成により、Android ターゲット内のすべてのコンパイルで JVM 11 が使用され、きめ細かい制御が可能になります。

従来のプラグイン

標準の Android ライブラリ プラグイン(com.android.library)を使用する KMP プロジェクトでは、KMP Android プラグインを使用する場合と構成が若干異なります(概念的には似ています)。

Kotlin ツールチェーンを使用する

kotlin.jvmToolchain() メソッドは同じように機能し、Java の sourceCompatibilitytargetCompatibility、Kotlin の jvmTarget を設定します。この方法をおすすめします。

// build.gradle.kts
kotlin {
    jvmToolchain(21)
}

compileOptions と kotlinOptions

Kotlin ツールチェーンを使用しない場合は、Java と Kotlin の個別のブロックを使用して JVM ターゲットを構成する必要があります。

// build.gradle.kts
android {
    compileOptions {
        sourceCompatibility = JavaVersion.VERSION_11
        targetCompatibility = JavaVersion.VERSION_11
    }

    kotlinOptions {
        jvmTarget = "11"
    }
}

10. コンシューマの保持ルールを公開する

KMP ライブラリでコンシューマの保持ルール(R8 の ProGuard ルールなど)をコンシューマに提供する必要がある場合は、新しいプラグインで公開を明示的に有効にする必要があります。以前は、指定されたコンシューマの保持ルールはデフォルトで公開されていました。

Android-KMP

新しいプラグインでは、コンシューマの保持ルールを公開するには、 optimization.consumerKeepRules.publish = true を設定し、 ブロック内でルールファイルを指定する必要があります。consumerKeepRules

// build.gradle.kts
kotlin {
  android {
    optimization {
      consumerKeepRules.apply {
        publish = true
        file("consumer-proguard-rules.pro")
      }
    }
  }
}

従来のプラグイン

com.android.library では、android.defaultConfigconsumerProguardFiles で指定されたルールファイルは、デフォルトでライブラリのアーティファクトに公開されます。

// build.gradle.kts
android {
  defaultConfig {
    consumerProguardFiles("consumer-proguard-rules.pro")
  }
}

11. ライブラリを Maven に公開する

他のプロジェクトで使用するために KMP ライブラリを Maven に公開する場合は、新しい Android-KMP プラグインを使用しているか、従来のプラグインを使用しているかによって手順が異なります。

Android-KMP

com.android.kotlin.multiplatform.library プラグインは、標準の Kotlin Multiplatform 公開メカニズムと統合されています。標準の KMP ライブラリ公開プロセス以外に、Android 固有の手順は必要ありません。

ライブラリを公開するには、JetBrains の公式ドキュメントの マルチプラットフォーム ライブラリの公開を設定するをご覧ください。

従来のプラグイン

KMP プロジェクトで Android ターゲットに com.android.library を使用する場合は、標準の Android ライブラリ公開ガイドに沿って Android 固有のアーティファクト(.aar)を準備して公開する必要があります。

手順について詳しくは、 リリース用にライブラリを準備するをご覧ください。

プラグイン API リファレンス

新しいプラグインの API サーフェスは com.android.library と異なります。新しい DSL とインターフェースの詳細については、API リファレンスをご覧ください。

Android-KMP ライブラリ プラグインの既知の問題

新しい com.android.kotlin.multiplatform.library プラグインを適用すると、次の既知の問題が発生する可能性があります。