com.android.kotlin.multiplatform.library Gradle प्लगिन, Kotlin Multiplatform (KMP) लाइब्रेरी मॉड्यूल में Android टारगेट जोड़ने के लिए, आधिकारिक तौर पर उपलब्ध टूल है. इससे प्रोजेक्ट को आसानी से कॉन्फ़िगर किया जा सकता है. साथ ही, बिल्ड की परफ़ॉर्मेंस बेहतर होती है और Android Studio के साथ बेहतर तरीके से इंटिग्रेट किया जा सकता है.
KMP डेवलपमेंट के लिए com.android.library प्लगिन का इस्तेमाल करना, Android Gradle Plugin API पर निर्भर करता है. ये एपीआई अब काम नहीं करते हैं. साथ ही, Android Gradle प्लगिन 9.0 और इसके बाद के वर्शन (साल 2025 की चौथी तिमाही) में, ऑप्ट-इन करना ज़रूरी है. इन एपीआई को Android Gradle प्लग इन 10.0 (साल 2026 की दूसरी छमाही) में हटा दिया जाएगा.
इस प्लगइन को लागू करने के लिए, Android-KMP प्लगइन लागू करना सेक्शन देखें. अगर आपको लेगसी एपीआई से माइग्रेट करना है, तो माइग्रेशन गाइड देखें.
मुख्य सुविधाएं और अंतर
Android-KMP प्लगिन को खास तौर पर KMP प्रोजेक्ट के लिए बनाया गया है. यह कई मामलों में, स्टैंडर्ड com.android.library प्लगिन से अलग है:
सिंगल वैरिएंट आर्किटेक्चर: यह प्लगिन, एक ही वैरिएंट का इस्तेमाल करता है. इससे ऐप्लिकेशन टाइप और बिल्ड के तरीके के लिए सहायता हट जाती है. इससे कॉन्फ़िगरेशन आसान हो जाता है और बिल्ड की परफ़ॉर्मेंस बेहतर हो जाती है.
KMP के लिए ऑप्टिमाइज़ किया गया: इस प्लगिन को KMP लाइब्रेरी के लिए डिज़ाइन किया गया है. इसमें शेयर किए गए Kotlin कोड और इंटरऑपरेबिलिटी पर फ़ोकस किया गया है. साथ ही, इसमें Android के लिए खास तौर पर बनाए गए नेटिव बिल्ड, एआईडीएल, और RenderScript के लिए सहायता शामिल नहीं है.
डिफ़ॉल्ट रूप से बंद टेस्ट: बिल्ड की स्पीड को बेहतर बनाने के लिए, यूनिट और डिवाइस (इंस्ट्रुमेंटेशन), दोनों टेस्ट डिफ़ॉल्ट रूप से बंद होते हैं. अगर ज़रूरी हो, तो इन्हें चालू किया जा सकता है.
कोई टॉप-लेवल Android एक्सटेंशन नहीं: कॉन्फ़िगरेशन को Gradle KMP DSL में मौजूद
androidLibraryब्लॉक से मैनेज किया जाता है. इससे KMP प्रोजेक्ट का स्ट्रक्चर एक जैसा बना रहता है. टॉप-लेवलandroidएक्सटेंशन ब्लॉक नहीं किया गया है.Java कंपाइलेशन के लिए ऑप्ट-इन करना: Java कंपाइलेशन डिफ़ॉल्ट रूप से बंद होता है. इसे चालू करने के लिए,
androidLibraryब्लॉक मेंwithJava()का इस्तेमाल करें. इससे Java कंपाइलेशन की ज़रूरत न होने पर, बिल्ड के समय में सुधार होता है.
Android-KMP लाइब्रेरी प्लगिन के फ़ायदे
Android-KMP प्लगिन, KMP प्रोजेक्ट के लिए ये फ़ायदे देता है:
बिल्ड की परफ़ॉर्मेंस और स्थिरता को बेहतर बनाया गया है: इसे KMP प्रोजेक्ट में, बिल्ड की स्पीड को ऑप्टिमाइज़ करने और स्थिरता को बेहतर बनाने के लिए डिज़ाइन किया गया है. KMP वर्कफ़्लो पर फ़ोकस करने से, बिल्ड प्रोसेस ज़्यादा असरदार और भरोसेमंद हो जाती है.
बेहतर आईडीई इंटिग्रेशन: यह KMP Android लाइब्रेरी के साथ काम करते समय, कोड को बेहतर तरीके से पूरा करने, नेविगेट करने, डीबग करने, और डेवलपर को बेहतर अनुभव देने की सुविधा देता है.
प्रोजेक्ट को आसानी से कॉन्फ़िगर करना: यह प्लगिन, KMP प्रोजेक्ट को आसानी से कॉन्फ़िगर करने में मदद करता है. इसके लिए, यह Android से जुड़ी जटिलताओं को दूर करता है. जैसे, बिल्ड वैरिएंट. इससे, बिल्ड फ़ाइलें ज़्यादा व्यवस्थित और रखरखाव में आसान हो जाती हैं. पहले, KMP प्रोजेक्ट में
com.android.libraryप्लगिन का इस्तेमाल करने पर, source set के नाम गलत हो सकते थे. जैसे,androidAndroidTest. नाम रखने का यह तरीका, स्टैंडर्ड KMP प्रोजेक्ट स्ट्रक्चर के बारे में जानने वाले डेवलपर के लिए कम सहज था.
ज़रूरी शर्तें
com.android.kotlin.multiplatform.library प्लगिन का इस्तेमाल करने के लिए, आपके प्रोजेक्ट में यहां दिए गए या इससे नए वर्शन कॉन्फ़िगर किए गए होने चाहिए:
- Android Gradle Plugin (AGP): 8.10.0
- Kotlin Gradle Plugin (KGP): 2.0.0
किसी मौजूदा मॉड्यूल पर Android-KMP प्लगिन लागू करना
किसी मौजूदा KMP लाइब्रेरी मॉड्यूल में Android-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 = "8.13.2" 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 टारगेट को कॉन्फ़िगर करें. Android टारगेट तय करने के लिए, Kotlin Multiplatform ब्लॉक (
kotlin) को कॉन्फ़िगर करें.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 के लिए खास तौर पर बनाए गए सोर्स सेट के लिए डिपेंडेंसी का एलान करना, एक सामान्य टास्क है. नए प्लगिन के लिए, इन कोड को sourceSets ब्लॉक में साफ़ तौर पर रखना ज़रूरी है. हालांकि, पहले इस्तेमाल किए गए सामान्य dependencies ब्लॉक में ऐसा नहीं था.
Android-KMP
नया प्लगिन, Android डिपेंडेंसी को androidMain सोर्स सेट में ग्रुप करके, बेहतर स्ट्रक्चर को बढ़ावा देता है. मुख्य सोर्स सेट के अलावा, दो टेस्ट सोर्स सेट होते हैं. इन्हें मांग पर बनाया जाता है:
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")
}
}
}
सोर्स सेट में, Kotlin के कंपाइलेशन होते हैं. इनके नाम main, deviceTest, और hostTest होते हैं. सोर्स सेट और कंपाइलेशन को बिल्ड स्क्रिप्ट में इस तरह कॉन्फ़िगर किया जा सकता है:
// 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 Resources (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 डायरेक्ट्री जोड़ी जा सकती है. इसके बाद, एक्सएमएल ड्रॉएबल, वैल्यू वगैरह जोड़ी जा सकती हैं.
// 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 ब्लॉक के अंदर टेस्ट चालू और कॉन्फ़िगर किए जाते हैं. इससे सेटअप ज़्यादा साफ़ तौर पर दिखता है और इस्तेमाल नहीं किए गए टेस्ट कॉम्पोनेंट नहीं बनते. test सोर्स सेट androidHostTest बन जाता है और androidTest, 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 = "ANDROIDX_TEST_ORCHESTRATOR"
}
}
}
// Project Structure (After Opt-in)
// └── src
// ├── androidHostTest
// └── androidDeviceTest
लेगसी प्लगिन
com.android.library प्लगिन की मदद से, test और androidTest सोर्स सेट डिफ़ॉल्ट रूप से बनाए गए थे. android ब्लॉक में, उनके व्यवहार को कॉन्फ़िगर किया जाता है. इसके लिए, आम तौर पर testOptions डीएसएल का इस्तेमाल किया जाता है.
// 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 = "ANDROIDX_TEST_ORCHESTRATOR"
}
}
// 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 टारगेट को android ब्लॉक में सेट किया गया था. इसके लिए, compileOptions का इस्तेमाल किया गया था.
// 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 एपीआई के ज़्यादातर फ़ंक्शन पहले जैसे ही हैं. हालांकि, 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 के लिए एक ही वैरिएंट बनाती है. हालांकि, ऐसा हो सकता है कि आप किसी स्टैंडर्ड Android लाइब्रेरी (com.android.library) पर निर्भर हों, जिसके कई वैरिएंट हों. जैसे, free/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 का इस्तेमाल करके, खोज के क्रम को तय करना होता था.
एपीआई के इस्तेमाल के बारे में ज़्यादा जानकारी के लिए, मिलान से जुड़ी गड़बड़ियां ठीक करना लेख पढ़ें.
7. झलक दिखाने की डिपेंडेंसी कंपोज़ करें
आम तौर पर, हम अपने लोकल डेवलपमेंट एनवायरमेंट के लिए कुछ खास लाइब्रेरी को स्कोप करना चाहते हैं, ताकि इंटरनल टूल को पब्लिश किए गए फ़ाइनल आर्टफ़ैक्ट में लीक होने से रोका जा सके. नए KMP Android प्लगिन के साथ यह एक चुनौती बन जाती है, क्योंकि यह बिल्ड टाइप आर्किटेक्चर को हटा देता है. इसका इस्तेमाल, डेवलपमेंट डिपेंडेंसी को रिलीज़ कोड से अलग करने के लिए किया जाता था.
Android-KMP
अगर आपको सिर्फ़ लोकल डेवलपमेंट और टेस्टिंग के लिए कोई डिपेंडेंसी जोड़नी है, तो उसे सीधे तौर पर मुख्य Android कंपाइलेशन के रनटाइम क्लासपाथ कॉन्फ़िगरेशन में जोड़ें. यह टॉप-लेवल dependencies ब्लॉक में होता है. इससे यह पक्का करने में मदद मिलती है कि रनटाइम के दौरान डिपेंडेंसी उपलब्ध हो. उदाहरण के लिए, Compose Preview जैसे टूल के लिए. हालांकि, यह आपकी लाइब्रेरी के कंपाइल क्लासपाथ या पब्लिश किए गए एपीआई का हिस्सा नहीं है.
// 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)
}
8. KMP Android टारगेट के लिए JVM टारगेट कॉन्फ़िगर करना
KMP Android प्लगिन, androidLibrary.compilerOptions.jvmTarget का इस्तेमाल करके JVM टारगेट सेट करता है. यह Java और Kotlin, दोनों पर लागू होता है. इससे कॉन्फ़िगरेशन आसान हो जाता है. ऐसा इसलिए, क्योंकि प्योर Android प्रोजेक्ट में अलग-अलग compileOptions और kotlinOptions ब्लॉक होते हैं.
Android-KMP
Android टारगेट वाले Kotlin Multiplatform (केएमपी) प्रोजेक्ट पर काम करते समय, आपके पास Kotlin और Java कंपाइलर, दोनों के लिए JVM टारगेट वर्शन को कॉन्फ़िगर करने के कई तरीके होते हैं. अपने प्रोजेक्ट के बाइटकोड के साथ काम करने की सुविधा को मैनेज करने के लिए, इन कॉन्फ़िगरेशन के स्कोप और क्रम को समझना ज़रूरी है.
यहां जेवीएम टारगेट सेट करने के तीन मुख्य तरीके दिए गए हैं. इन्हें सबसे कम से लेकर सबसे ज़्यादा प्राथमिकता के क्रम में रखा गया है. ज़्यादा प्राथमिकता वाली जेवीएम टारगेट वैल्यू, कॉन्फ़िगर किए गए टारगेट के छोटे सबसेट पर लागू होती हैं. साथ ही, कम प्राथमिकता वाली वैल्यू को बदल देती हैं. इसका मतलब है कि अपने प्रोजेक्ट में टारगेट और टारगेट के अंदर कंपाइलेशन के लिए, अलग-अलग जेवीएम वर्शन सेट किए जा सकते हैं.
Kotlin टूलचेन का इस्तेमाल करना (सबसे कम प्राथमिकता)
JVM टारगेट सेट करने का सबसे सामान्य तरीका यह है कि अपनी build.gradle.kts फ़ाइल के kotlin ब्लॉक में टूलचेन तय करें. इस तरीके से, आपके प्रोजेक्ट में JVM पर आधारित सभी टारगेट के लिए, Kotlin और Java, दोनों के कंपाइलेशन टास्क का टारगेट सेट किया जाता है. इसमें Android भी शामिल है.
// 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"
}
}
प्लगिन एपीआई का रेफ़रंस
नए प्लगिन का एपीआई, com.android.library से अलग है. नए डीएसएल और इंटरफ़ेस के बारे में ज़्यादा जानकारी के लिए, एपीआई के रेफ़रंस देखें:
KotlinMultiplatformAndroidLibraryExtensionKotlinMultiplatformAndroidLibraryTargetKotlinMultiplatformAndroidDeviceTestKotlinMultiplatformAndroidHostTestKotlinMultiplatformAndroidVariant
Android-KMP लाइब्रेरी प्लगिन में मौजूद समस्याएं
यहां कुछ ऐसी समस्याएं दी गई हैं जो नया com.android.kotlin.multiplatform.library प्लगिन लागू करने पर हो सकती हैं:
android-KMP प्लगिन का इस्तेमाल करने पर, कंपोज़ की झलक नहीं दिखती
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में ठीक किया गया
-
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में ठीक किया गया
ये सुविधाएं, Google Play Books के साथ काम नहीं करतीं
com.android.library प्लगिन के साथ KMP इंटिग्रेशन की तुलना में, com.android.kotlin.multiplatform.library प्लगिन में ये सुविधाएं मौजूद नहीं हैं:
डेटा बाइंडिंग और व्यू बाइंडिंग
ये Android के लिए खास तौर पर बनाए गए यूज़र इंटरफ़ेस (यूआई) फ़्रेमवर्क की सुविधाएं हैं. ये Android व्यू सिस्टम और एक्सएमएल लेआउट से जुड़ी हैं. हमारा सुझाव है कि Android-KMP लाइब्रेरी के नए प्लगिन में, यूज़र इंटरफ़ेस (यूआई) को मैनेज करने के लिए, Compose Multiplatform जैसे मल्टीप्लैटफ़ॉर्म फ़्रेमवर्क का इस्तेमाल करें. डेटा बाइंडिंग और व्यू बाइंडिंग को, फ़ाइनल Android ऐप्लिकेशन की लागू करने से जुड़ी जानकारी माना जाता है. इन्हें शेयर की जा सकने वाली लाइब्रेरी नहीं माना जाता.
नेटिव बिल्ड के लिए सहायता
नया प्लगिन, Android टारगेट के लिए स्टैंडर्ड एएआर बनाने पर फ़ोकस करता है. Kotlin Multiplatform में नेटिव कोड इंटिग्रेशन को सीधे तौर पर KMP के अपने नेटिव टारगेट (जैसे,
androidNativeArm64औरandroidNativeX86) और इसकी C-इंटरऑप क्षमताओं से मैनेज किया जाता है. अगर आपको नेटिव C/C++ कोड शामिल करना है, तो आपको इसे सामान्य या नेटिव सोर्स सेट के हिस्से के तौर पर तय करना चाहिए. साथ ही, Android के लिए खासkotlinमेकेनिज़्म का इस्तेमाल करने के बजाय,kotlinब्लॉक में C-interop को कॉन्फ़िगर करना चाहिए.externalNativeBuildइसके अलावा, अगर आपको नेटिव बिल्ड के लिए सहायता चाहिए, तो हमारा सुझाव है कि आप एक अलग स्टैंडअलोन
com.android.libraryबनाएं. इसमें नेटिव कोड को इंटिग्रेट किया जा सकता है. साथ ही, Kotlin Multiplatform लाइब्रेरी प्रोजेक्ट से स्टैंडअलोन लाइब्रेरी का इस्तेमाल किया जा सकता है.BuildConfigclassBuildConfigसुविधा, एक से ज़्यादा वैरिएंट वाले माहौल में सबसे ज़्यादा फ़ायदेमंद होती है. Kotlin Multiplatform लाइब्रेरी का नया प्लगिन, वैरिएंट के हिसाब से काम नहीं करता. साथ ही, इसमें बिल्ड टाइप और प्रॉडक्ट फ़्लेवर के लिए सहायता उपलब्ध नहीं है. इसलिए, इस सुविधा को लागू नहीं किया गया है. इसके अलावा, हम सभी टारगेट के लिए मेटाडेटा जनरेट करने के लिए,BuildKonfigप्लगिन या कम्यूनिटी के ऐसे ही अन्य समाधानों का इस्तेमाल करने का सुझाव देते हैं.
आपके लिए सुझाव
- ध्यान दें: JavaScript बंद होने पर लिंक का टेक्स्ट दिखता है
- अपना एनवायरमेंट सेट अप करना
- किसी प्रोजेक्ट में केएमपी मॉड्यूल जोड़ना