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 独自のネイティブ ターゲット(
androidNativeArm64やandroidNativeX86など)と 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 ライブラリ モジュールに適用する手順は次のとおりです。
バージョン カタログでプラグインを宣言します。バージョン カタログの 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" }ルート ビルドファイルでプラグイン宣言を適用します。プロジェクトのルート ディレクトリにある
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 }
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) }
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.) ... }
変更を適用します。プラグインを適用して
kotlinブロックを構成したら、Gradle プロジェクトを同期して変更を適用します。
従来のプラグインから移行する
このガイドでは、以前の com.android.library プラグインから com.android.kotlin.multiplatform.library プラグインに移行する方法について説明します。
1. 依存関係の宣言
一般的なタスクは、Android 固有のソースセットの依存関係を宣言することです。新しいプラグインでは、以前使用されていた一般的な dependencies ブロックとは異なり、これらのプラグインを sourceSets ブロック内に明示的に配置する必要があります。
Android-KMP
新しいプラグインは、Android の依存関係を androidMain ソースセット内にグループ化することで、よりクリーンな構造を促進します。メインのソースセットに加えて、オンデマンドで作成される 2 つのテストソースセット(androidDeviceTest と androidHostTest)があります(詳しくは、ホストとデバイスのテストを設定するをご覧ください)。
// 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")
}
}
}
ソースセットには、main、deviceTest、hostTest という名前の対応する 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/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
3. ホストテストとデバイス テストを構成する
新しいプラグインの大きな変更点は、Android のホスト側(ユニット)テストとデバイス側(計測)テストがデフォルトで無効になっていることです。古いプラグインではテスト ソースセットと構成が自動的に作成されましたが、新しいプラグインでは明示的にオプトインして作成する必要があります。
このオプトイン モデルは、プロジェクトがスリムな状態を維持し、実際に使用しているビルド ロジックとソースセットのみが含まれていることを確認するのに役立ちます。
Android-KMP
新しいプラグインでは、kotlin.androidLibrary ブロック内でテストを有効にして構成します。これにより、設定がより明確になり、未使用のテスト コンポーネントの作成を回避できます。androidUnitTest ソースセットが androidHostTest になり(テスト ディレクトリが src/androidUnitTest から src/androidHostTest に変更)、androidInstrumentedTest が androidDeviceTest になります(テスト ディレクトリが 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 プラグインを使用すると、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
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 ブロックは単一のバリアントを反復処理するようになりました。name や artifacts などの共通プロパティには引き続きアクセスできますが、ビルドタイプ固有のプロパティにはアクセスできません。
// 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)
}
この構成により、kotlinc と javac の両方が 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 の 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"
}
}
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.defaultConfig の consumerProguardFiles で指定されたルールファイルは、デフォルトでライブラリのアーティファクトに公開されます。
// 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 リファレンスをご覧ください。
KotlinMultiplatformAndroidLibraryExtensionKotlinMultiplatformAndroidLibraryTargetKotlinMultiplatformAndroidDeviceTestKotlinMultiplatformAndroidHostTestKotlinMultiplatformAndroidVariant
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で修正済み
-
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で修正済み
あなたへのおすすめ
- 注: JavaScript がオフになっている場合はリンクテキストが表示されます
- 環境を設定する
- プロジェクトに KMP モジュールを追加する