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 から移行する必要がある場合は、移行ガイドをご覧ください。

主な機能と相違点

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

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

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

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

  • トップレベルの Android 拡張機能がない: 構成は Gradle KMP DSL 内の androidLibrary ブロックで処理され、一貫した KMP プロジェクト構造が維持されます。トップレベルの android 拡張機能ブロックがない。

  • オプトイン Java コンパイル: Java コンパイルはデフォルトで無効になっています。有効にするには、androidLibrary ブロックで 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 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.0.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 ブロック内で、androidLibrary を使用して Android ターゲットを指定します。

    Kotlin

    kotlin {
       androidLibrary {
           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 {
       androidLibrary {
           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. 依存関係の宣言

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

Android-KMP

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

// build.gradle.kts

kotlin {
    androidLibrary {}
    //... 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")
        }
    }
}

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

// build.gradle.kts

kotlin {
    androidLibrary {
        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")
}

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

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

Android-KMP

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

// build.gradle.kts

kotlin {
  androidLibrary {
    // ...
    // 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

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

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

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

Android-KMP

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

// build.gradle.kts

kotlin {
  androidLibrary {
    // ...

    // 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 プラグインを使用すると、androidUnitTestandroidInstrumentedTest のソースセットがデフォルトで作成されます。通常は 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

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

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

Android-KMP

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

// build.gradle.kts

kotlin {
  androidLibrary {
    //  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"
    }
  }
}

5. 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 ->
    // ...
  }
}

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

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

Android-KMP

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

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

7. 作成プレビューの依存関係

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

Android-KMP

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

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

以前のプラグイン

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

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

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

KMP Android プラグインは androidLibrary.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 {
    androidLibrary {
        compilerOptions {
            jvmTarget.set(JvmTarget.JVM_11)
        }
    }
}

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

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

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

// build.gradle.kts
kotlin {
    androidLibrary {
        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"
    }
}

9. コンシューマー保持ルールを公開

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

Android-KMP

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

// build.gradle.kts
kotlin {
  androidLibrary {
    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")
  }
}

10. ライブラリを 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 プラグインを適用する際に発生する可能性のある既知の問題は次のとおりです。