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

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

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

注: com.android.application プラグインを使用して Kotlin マルチプラットフォーム モジュールを構成する直接的な代替手段はありません。移行するには、Android アプリケーションを別の Gradle モジュールに抽出します。

このプラグインを適用するには、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 マルチプラットフォーム ライブラリの androidMain ソースセットから標準のプロジェクト依存関係として使用することをおすすめします。詳しくは、Android ライブラリを作成するとビルド バリアントを設定するをご覧ください。

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

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

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

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

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

• BuildConfig クラス

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

前提条件

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

• Android Gradle プラグイン（AGP）: 8.10.0
• Kotlin Gradle プラグイン（KGP）: 2.0.0

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

既存の KMP ライブラリ モジュールに Android-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.4.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 マルチプラットフォーム ブロック（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 プラグインに移行する方法について説明します。

注: Android Gradle プラグインのバージョンが 8.12.0 より前の場合、Android ターゲットの構成ブロックは androidLibrary{} です。AGP 8.12.0 以降、androidLibrary{} に代わる新しい android{} ブロックが導入されました。androidLibrary{} は AGP 9.1.0-alpha09 以降非推奨となり、今後のリリースで削除される予定です。AGP 8.12.0 以降を使用している場合は android{} を使用し、それ以外の場合は androidLibrary{} を使用します。

1. ソースを移動する

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

2. カスタムのソース ディレクトリとリソース ディレクトリを構成する

標準以外のディレクトリにソースまたはリソースがある場合は、以前は sourceSets ブロックを使用して構成していました。新しいプラグインでは、androidComponents 拡張機能を使用して、静的ソース ディレクトリをバリアントに追加します。

新しいプラグインでは、addStaticSourceDirectory メソッドによって、既存のソース ディレクトリのリストにディレクトリが追加されます。以前のプラグインでは、setSrcDirs メソッドはリストを置き換え、srcDir メソッドはリストに追加します。

Android-KMP

新しいプラグインでは、onVariants ブロックを使用してバリアントのソースを操作します。

// build.gradle.kts

androidComponents {
    onVariants { variant ->
        // Add a directory for Kotlin sources
        variant.sources.kotlin?.addStaticSourceDirectory("other/kotlin")

        // Add a directory for Android assets
        variant.sources.assets?.addStaticSourceDirectory("other/assets")
    }
}

以前のプラグイン

com.android.library プラグインでは、sourceSets ブロックを使用してソース ディレクトリを設定または追加していました。

// build.gradle.kts

android {
    sourceSets {
        getByName("main") {
            // Replaces the directory for Kotlin sources.
            kotlin.setSrcDirs(listOf("other/kotlin"))

            // Appends a directory for assets.
            assets.srcDir("other/assets")
        }
    }
}

3. 依存関係の宣言

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

Android-KMP

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

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

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

// build.gradle.kts

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

以前のプラグイン

以前のプラグインでは、トップレベルの dependencies ブロックで 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")
}

4. 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/main に res ディレクトリをすぐに追加して、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

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

デフォルトでは、新しいプラグインは Android のホスト側（単体）テストとデバイス側（インストゥルメント化）テストを無効にします。テストのソースセットと構成を作成するには、明示的にオプトインする必要があります。一方、以前のプラグインでは、これらは自動的に作成されていました。

このオプトイン モデルにより、プロジェクトがスリムな状態を維持し、実際に使用するビルド ロジックとソースセットのみが含まれるようになります。

Android-KMP

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

6. 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"
    }
  }
}

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

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

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

Android-KMP

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

// build.gradle.kts

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

以前のプラグイン

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

// build.gradle.kts

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

8. 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 の使用方法の詳細については、マッチング エラーを解決するをご覧ください。

9. Compose プレビューの依存関係を追加する

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

Android-KMP

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

プレビュー: この回避策は、Android Gradle プラグイン バージョン 9.0.0-beta01 以降でのみ使用できます。

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

以前のプラグイン

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

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

10. 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)
}

この構成により、kotlinc と javac の両方が 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 の sourceCompatibility と targetCompatibility、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"
    }
}

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

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.defaultConfig で consumerProguardFiles を使用して指定されたルールファイルは、デフォルトでライブラリのアーティファクトに公開されます。

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

12. ライブラリを 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 リファレンスをご覧ください。

• KotlinMultiplatformAndroidLibraryExtension
• KotlinMultiplatformAndroidLibraryTarget
• KotlinMultiplatformAndroidDeviceTest
• KotlinMultiplatformAndroidHostTest
• KotlinMultiplatformAndroidVariant

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

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

• 新しい android-KMP プラグインを使用すると Compose プレビューが失敗する

  • Android Studio Otter 2 Feature Drop | 2025.2.2 Canary 3 と Android Gradle Plugin 9.0.0-alpha13 で修正

• com.android.kotlin.multiplatform.library プラグインを使用した Compose Multiplatform プレビューでの NullPointerException

  • Android Studio Otter 2 Feature Drop | 2025.2.2 Canary 3 と Android Gradle Plugin 9.0.0-alpha13 で修正

• KMP が共通のコンパイル依存関係の解決を構成キャッシュに保存し、デシリアル化時にエラーが発生する（Android のみ）

  • Kotlin Gradle Plugin 2.3.0-Beta2 で修正

• androidLibrary ターゲットのインストルメント化された sourceSetTree のサポート

  • Android Studio Otter 2 Feature Drop | 2025.2.2 Canary 3 と Android Gradle Plugin 9.0.0-alpha13 で修正