KMP के लिए, Android Gradle लाइब्रेरी प्लगिन सेट अप करना

com.android.kotlin.multiplatform.library Gradle प्लगिन, Kotlin Multiplatform (केएमपी) लाइब्रेरी मॉड्यूल में Android टारगेट जोड़ने के लिए आधिकारिक तौर पर इस्तेमाल किया जाने वाला टूल है. यह प्रोजेक्ट कॉन्फ़िगरेशन को आसान बनाता है, बिल्ड की परफ़ॉर्मेंस को बेहतर बनाता है, और Android Studio के साथ बेहतर इंटिग्रेशन की सुविधा देता है.

केएमपी डेवलपमेंट के लिए com.android.library प्लगिन का इस्तेमाल करना, Android Gradle प्लगिन के उन एपीआई पर निर्भर करता है जो अब काम नहीं करते. साथ ही, Android Gradle प्लगिन 9.0 और इसके बाद के वर्शन (2025 की चौथी तिमाही) में, ऑप्ट-इन करना ज़रूरी है. इन एपीआई को Android Gradle प्लगिन 10.0 (साल 2026 की दूसरी छमाही) से हटाया जा सकता है.

इस प्लगिन को लागू करने के लिए, Android-KMP प्लगिन लागू करें सेक्शन देखें. अगर आपको लेगसी एपीआई से माइग्रेट करना है, तो माइग्रेट करने से जुड़ी गाइड देखें.

AGP 9.0 या इसके बाद के वर्शन पर माइग्रेट करने में मदद पाने के लिए, JetBrains की ओर से केएमपी ऐप्लिकेशन के लिए बनाई गई एजेंट स्किल का इस्तेमाल किया जा सकता है. Android Studio में स्किल इस्तेमाल करने के बारे में ज़्यादा जानने के लिए, स्किल की मदद से एजेंट मोड को बेहतर बनाना लेख पढ़ें. ध्यान रखें कि एआई से मिलने वाले नतीजों का पूरी तरह से अनुमान नहीं लगाया जा सकता.

मुख्य सुविधाएं और अंतर

Android-KMP प्लगिन को खास तौर पर KMP प्रोजेक्ट के लिए बनाया गया है. यह स्टैंडर्ड com.android.library प्लगिन से कई मामलों में अलग है:

  • सिंगल वैरिएंट आर्किटेक्चर: यह प्लगिन, एक ही वैरिएंट का इस्तेमाल करता है. इससे ऐप्लिकेशन टाइप और बिल्ड के तरीके के लिए सहायता हट जाती है. इससे कॉन्फ़िगरेशन आसान हो जाता है और बिल्ड की परफ़ॉर्मेंस बेहतर हो जाती है.

  • KMP के लिए ऑप्टिमाइज़ किया गया: इस प्लगिन को KMP लाइब्रेरी के लिए डिज़ाइन किया गया है. इसमें शेयर किए गए Kotlin कोड और इंटरऑपरेबिलिटी पर फ़ोकस किया गया है. साथ ही, इसमें Android के लिए खास तौर पर बनाए गए नेटिव बिल्ड, एआईडीएल, और RenderScript के लिए सहायता शामिल नहीं है.

  • डिफ़ॉल्ट रूप से बंद टेस्ट: बिल्ड की स्पीड को बेहतर बनाने के लिए, यूनिट और डिवाइस (इंस्ट्रुमेंटेशन), दोनों टेस्ट डिफ़ॉल्ट रूप से बंद होते हैं. अगर ज़रूरी हो, तो इन्हें चालू किया जा सकता है.

  • कोई टॉप-लेवल Android एक्सटेंशन नहीं: कॉन्फ़िगरेशन को Gradle KMP डीएसएल में android ब्लॉक की मदद से मैनेज किया जाता है. इससे KMP प्रोजेक्ट का स्ट्रक्चर एक जैसा बना रहता है. टॉप-लेवल पर कोई android एक्सटेंशन ब्लॉक नहीं है.

  • Java कंपाइलेशन के लिए ऑप्ट-इन करना: Java कंपाइलेशन डिफ़ॉल्ट रूप से बंद होता है. इसे चालू करने के लिए, android ब्लॉक में withJava() का इस्तेमाल करें. इससे Java कंपाइलेशन की ज़रूरत न होने पर, बिल्ड के समय में सुधार होता है.

Android-KMP लाइब्रेरी प्लग इन के फ़ायदे

Android-KMP प्लगिन, KMP प्रोजेक्ट के लिए ये फ़ायदे देता है:

  • बेहतर बिल्ड परफ़ॉर्मेंस और स्थिरता: इसे केएमपी प्रोजेक्ट में, बिल्ड की स्पीड को ऑप्टिमाइज़ करने और स्थिरता को बेहतर बनाने के लिए डिज़ाइन किया गया है. केएमपी वर्कफ़्लो पर फ़ोकस करने से, बिल्ड प्रोसेस ज़्यादा असरदार और भरोसेमंद बनती है.

  • बेहतर आईडीई इंटिग्रेशन: यह KMP Android लाइब्रेरी के साथ काम करते समय, कोड को बेहतर तरीके से पूरा करने, नेविगेट करने, डीबग करने, और डेवलपर को बेहतर अनुभव देने की सुविधा देता है.

  • प्रोजेक्ट को आसानी से कॉन्फ़िगर करना: यह प्लगिन, KMP प्रोजेक्ट को आसानी से कॉन्फ़िगर करने में मदद करता है. इसके लिए, यह Android से जुड़ी जटिलताओं को दूर करता है. जैसे, बिल्ड वैरिएंट. इससे, बिल्ड फ़ाइलें ज़्यादा व्यवस्थित और रखरखाव में आसान हो जाती हैं. पहले, KMP प्रोजेक्ट में com.android.library प्लगिन का इस्तेमाल करने पर, source set के नाम गलत हो सकते थे. जैसे, androidAndroidTest. नाम रखने का यह तरीका, स्टैंडर्ड KMP प्रोजेक्ट स्ट्रक्चर के बारे में जानने वाले डेवलपर के लिए कम सहज था.

इस्तेमाल न की जा सकने वाली सुविधाओं के लिए समाधान

com.android.library प्लगिन के साथ केएमपी इंटिग्रेशन की तुलना में, com.android.kotlin.multiplatform.library प्लगिन में कुछ सुविधाएं मौजूद नहीं हैं. यहां उन सुविधाओं के लिए समाधान दिए गए हैं जो काम नहीं करतीं:

  • बिल्ड के वैरिएंट

    बिल्ड टाइप और ऐप्लिकेशन टाइप का इस्तेमाल नहीं किया जा सकता. ऐसा इसलिए होता है, क्योंकि नया प्लगिन, सिंगल वैरिएंट आर्किटेक्चर का इस्तेमाल करता है. इससे कॉन्फ़िगरेशन आसान हो जाता है और बिल्ड की परफ़ॉर्मेंस बेहतर हो जाती है.

    अगर आपको बिल्ड के वैरिएंट चाहिए, तो हमारा सुझाव है कि आप com.android.library प्लगिन का इस्तेमाल करके, अलग से स्टैंडअलोन Android लाइब्रेरी मॉड्यूल बनाएं. साथ ही, उस मॉड्यूल में बिल्ड टाइप और ऐप्लिकेशन टाइप कॉन्फ़िगर करें. इसके बाद, Kotlin मल्टीप्लैटफ़ॉर्म लाइब्रेरी के androidMain सोर्स सेट से, इसे स्टैंडर्ड प्रोजेक्ट डिपेंडेंसी के तौर पर इस्तेमाल करें. ज़्यादा जानकारी के लिए, Android लाइब्रेरी बनाना और बिल्ड के वैरिएंट कॉन्फ़िगर करना लेख पढ़ें.

  • डेटा बाइंडिंग और व्यू बाइंडिंग

    ये Android के लिए खास तौर पर बनाई गई यूज़र इंटरफ़ेस (यूआई) फ़्रेमवर्क की सुविधाएं हैं. ये Android व्यू सिस्टम और एक्सएमएल लेआउट से जुड़ी हैं. नए Android-KMP लाइब्रेरी प्लगिन के साथ, हमारा सुझाव है कि आप Compose Multiplatform जैसे मल्टीप्लैटफ़ॉर्म फ़्रेमवर्क का इस्तेमाल करके, यूज़र इंटरफ़ेस (यूआई) को मैनेज करें. डेटा बाइंडिंग और व्यू बाइंडिंग को, Android ऐप्लिकेशन के फ़ाइनल वर्शन को लागू करने की जानकारी माना जाता है, न कि शेयर की जा सकने वाली लाइब्रेरी.

  • नेटिव बिल्ड के लिए सहायता

    नया प्लगिन, Android टारगेट के लिए स्टैंडर्ड एएआर बनाने पर फ़ोकस करता है. Kotlin Multiplatform में नेटिव कोड इंटिग्रेशन को सीधे तौर पर केएमपी के नेटिव टारगेट (जैसे, androidNativeArm64 और androidNativeX86) और इसकी C-इंटरऑप क्षमताओं से मैनेज किया जाता है. अगर आपको नेटिव C/C++ कोड शामिल करना है, तो आपको इसे सामान्य या नेटिव सोर्स सेट के हिस्से के तौर पर तय करना चाहिए. साथ ही, Android के लिए खास तौर पर बनाए गए externalNativeBuild तरीके का इस्तेमाल करने के बजाय, kotlin ब्लॉक में C-interop को कॉन्फ़िगर करना चाहिए.

    इसके अलावा, अगर आपको externalNativeBuild के ज़रिए नेटिव बिल्ड की सुविधा चाहिए, तो हमारा सुझाव है कि आप एक अलग स्टैंडअलोन com.android.library मॉड्यूल बनाएं. इसमें नेटिव कोड को इंटिग्रेट किया जा सकता है. साथ ही, Kotlin मल्टीप्लैटफ़ॉर्म लाइब्रेरी प्रोजेक्ट के androidMain सोर्स सेट से, उस स्टैंडअलोन लाइब्रेरी का इस्तेमाल किया जा सकता है. ज़्यादा जानकारी के लिए, Android लाइब्रेरी बनाना और अपने प्रोजेक्ट में C और C++ कोड जोड़ना लेख पढ़ें.

  • BuildConfig क्लास

    BuildConfig सुविधा, कई वैरिएंट वाले एनवायरमेंट में सबसे ज़्यादा काम आती है. Kotlin Multiplatform लाइब्रेरी का नया प्लगिन, वैरिएंट के हिसाब से काम नहीं करता. साथ ही, इसमें बिल्ड टाइप और ऐप्लिकेशन टाइप के लिए सहायता उपलब्ध नहीं है. इसलिए, इस सुविधा को लागू नहीं किया गया है. इसके बजाय, हमारा सुझाव है कि आप सभी टारगेट के लिए मेटाडेटा जनरेट करने के लिए, BuildKonfig प्लगिन या कम्यूनिटी के ऐसे ही अन्य समाधानों का इस्तेमाल करें.

ज़रूरी शर्तें

com.android.kotlin.multiplatform.library प्लगिन का इस्तेमाल करने के लिए, आपके प्रोजेक्ट को इन कम से कम वर्शन या इसके बाद के वर्शन के साथ कॉन्फ़िगर किया जाना चाहिए:

  • Android Gradle प्लगिन (एजीपी): 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.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. केएमपी लाइब्रेरी मॉड्यूल की बिल्ड फ़ाइल में प्लगिन लागू करें. अपने केएमपी लाइब्रेरी मॉड्यूल में 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 टारगेट को कॉन्फ़िगर करें. Android टारगेट तय करने के लिए, Kotlin Multiplatform ब्लॉक (kotlin) को कॉन्फ़िगर करें. 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/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 के लिए खास तौर पर बनाए गए सोर्स सेट के लिए डिपेंडेंसी तय करना है. नए प्लगिन के लिए, इन्हें साफ़ तौर पर sourceSets ब्लॉक में रखना ज़रूरी है. यह पहले इस्तेमाल किए गए सामान्य dependencies ब्लॉक से अलग है.

Android-KMP

नया प्लग इन, Android डिपेंडेंसी को androidMain सोर्स सेट में ग्रुप करके, स्ट्रक्चर को बेहतर बनाता है. मुख्य सोर्स सेट के अलावा, दो टेस्ट सोर्स सेट होते हैं, जो ज़रूरत के हिसाब से बनाए जाते हैं: 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")
        }
    }
}

सोर्स सेट में Kotlin के कंपाइलेशन होते हैं. इनके नाम main, deviceTest, और 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")
}

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 डायरेक्ट्री जोड़ी जा सकती है. साथ ही, एक्सएमएल ड्रॉएबल, वैल्यू वगैरह जोड़ना शुरू किया जा सकता है.

// 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 सोर्स सेट डिफ़ॉल्ट रूप से बनाए जाते हैं. 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 = "HOST"
  }
}

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

6. Java सोर्स कंपाइलेशन की सुविधा चालू करना

अगर आपकी KMP लाइब्रेरी को अपने Android टारगेट के लिए Java सोर्स कंपाइल करने हैं, तो आपको नए प्लगिन की मदद से इस सुविधा को साफ़ तौर पर चालू करना होगा. ध्यान दें कि इससे आपके प्रोजेक्ट में मौजूद Java फ़ाइलों को कंपाइल किया जा सकता है, न कि उसकी डिपेंडेंसी को. Java और Kotlin कंपाइलर के जेवीएम टारगेट वर्शन को सेट करने का तरीका भी बदल जाता है.

Android-KMP

Java कंपाइलेशन के लिए ऑप्ट-इन करने के लिए, आपको withJava() को कॉल करना होगा. जेवीएम टारगेट को अब सीधे 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 एपीआई का ज़्यादातर हिस्सा पहले जैसा ही है. हालांकि, 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 लाइब्रेरी डिपेंडेंसी के वैरिएंट चुनें

आपकी केएमपी लाइब्रेरी, Android के लिए एक वैरिएंट बनाती है. हालांकि, हो सकता है कि आप किसी ऐसी स्टैंडर्ड Android लाइब्रेरी (com.android.library) पर निर्भर हों जिसमें कई वैरिएंट (जैसे, free/paid ऐप्लिकेशन टाइप) हों. यह कंट्रोल करना कि आपका प्रोजेक्ट, उस डिपेंडेंसी से वैरिएंट कैसे चुनता है, एक सामान्य ज़रूरत है.

Android-KMP

नया प्लग इन, इस लॉजिक को kotlin.android.localDependencySelection ब्लॉक में एक जगह पर रखता है और साफ़ तौर पर समझाता है. इससे यह साफ़ तौर पर पता चलता है कि सिंगल-वैरिएंट केएमपी लाइब्रेरी के लिए, बाहरी डिपेंडेंसी के कौनसे वैरिएंट चुने जाएंगे.

// 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 का इस्तेमाल किया जाता था.

एपीआई के इस्तेमाल के बारे में ज़्यादा जानकारी के लिए, मिलान से जुड़ी गड़बड़ियों को ठीक करना लेख पढ़ें.

9. Compose की झलक वाली डिपेंडेंसी जोड़ना

आम तौर पर, हम चाहते हैं कि कुछ खास लाइब्रेरी हमारे लोकल डेवलपमेंट एनवायरमेंट तक ही सीमित रहें. इससे इंटरनल टूल, पब्लिश किए गए फ़ाइनल आर्टफ़ैक्ट में लीक नहीं होते. नए KMP Android प्लगिन के साथ ऐसा करना मुश्किल हो जाता है. इसकी वजह यह है कि यह उस बिल्ड टाइप आर्किटेक्चर को हटा देता है जिसका इस्तेमाल, डेवलपमेंट डिपेंडेंसी को रिलीज़ कोड से अलग करने के लिए किया जाता है.

Android-KMP

सिर्फ़ लोकल डेवलपमेंट और टेस्टिंग के लिए डिपेंडेंसी जोड़ने के लिए, डिपेंडेंसी को सीधे मुख्य Android कंपाइलेशन के रनटाइम क्लासपाथ कॉन्फ़िगरेशन (टॉप-लेवल dependencies ब्लॉक में) में जोड़ें. इससे यह पक्का करने में मदद मिलती है कि डिपेंडेंसी, रनटाइम के दौरान उपलब्ध हो. उदाहरण के लिए, Compose Preview जैसे टूल के लिए. हालांकि, यह कंपाइल क्लासपाथ या आपकी लाइब्रेरी के पब्लिश किए गए एपीआई का हिस्सा नहीं होती.

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

लेगसी प्लग इन

Kotlin Multiplatform के ऐसे प्रोजेक्ट जो Android टारगेट के लिए com.android.library प्लगिन का इस्तेमाल करते हैं उन्हें debugImplementation कॉन्फ़िगरेशन का इस्तेमाल करना चाहिए. इससे डिपेंडेंसी, डीबग के लिए बिल्ड टाइप तक सीमित हो जाती है. साथ ही, इसे उपभोक्ताओं के इस्तेमाल किए जाने वाले लाइब्रेरी के रिलीज़ वैरिएंट में शामिल होने से रोका जाता है.

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

10. केएमपी Android टारगेट के लिए, जेवीएम टारगेट को कॉन्फ़िगर करना

KMP Android प्लगिन, android.compilerOptions.jvmTarget का इस्तेमाल करके जेवीएम टारगेट सेट करता है. यह Java और Kotlin, दोनों पर लागू होता है. इससे, Android प्रोजेक्ट में अलग-अलग compileOptions और kotlinOptions ब्लॉक की तुलना में कॉन्फ़िगरेशन आसान हो जाता है.

Android-KMP

Kotlin Multiplatform (केएमपी) प्रोजेक्ट पर काम करते समय, Kotlin और Java कंपाइलर, दोनों के लिए जेवीएम टारगेट वर्शन को कॉन्फ़िगर करने के कई तरीके हैं. इस प्रोजेक्ट में Android टारगेट शामिल होता है. अपने प्रोजेक्ट के बाइट कोड की कंपैटबिलिटी को मैनेज करने के लिए, इन कॉन्फ़िगरेशन के स्कोप और क्रम को समझना ज़रूरी है.

जेवीएम टारगेट सेट करने के तीन मुख्य तरीके यहां दिए गए हैं. इन्हें सबसे कम से लेकर सबसे ज़्यादा प्राथमिकता के क्रम में लगाया गया है. जेवीएम टारगेट की ऐसी वैल्यू जो ज़्यादा प्राथमिकता लेती हैं, वे आपके कॉन्फ़िगर किए गए टारगेट के छोटे सबसेट पर लागू होती हैं. साथ ही, वे ऐसी वैल्यू को बदल देती हैं जो कम प्राथमिकता लेती हैं. इसका मतलब है कि अपने प्रोजेक्ट में अलग-अलग टारगेट और टारगेट के अंदर कंपाइलेशन के लिए, अलग-अलग जेवीएम वर्शन सेट किए जा सकते हैं.

Kotlin टूलचेन का इस्तेमाल करना (सबसे कम प्राथमिकता)

जेवीएम टारगेट सेट करने का सबसे सामान्य तरीका, अपनी build.gradle.kts फ़ाइल के kotlin ब्लॉक में टूलचेन तय करना है. इस तरीके से, आपके प्रोजेक्ट में मौजूद सभी जेवीएम-आधारित टारगेट के लिए, Kotlin और Java, दोनों के कंपाइलेशन टास्क का टारगेट सेट हो जाता है. इसमें Android भी शामिल है.

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

इस कॉन्फ़िगरेशन से, kotlinc और javac, दोनों JVM 21 को टारगेट करते हैं. यह आपके पूरे प्रोजेक्ट के लिए एक जैसी बेसलाइन सेट करने का बेहतरीन तरीका है.

Android टारगेट-लेवल कंपाइलर के विकल्पों का इस्तेमाल करना (मध्यम प्राथमिकता)

android ब्लॉक में, Android केएमपी टारगेट के लिए जेवीएम टारगेट तय किया जा सकता है. यह सेटिंग, पूरे प्रोजेक्ट के लिए तय किए गए jvmToolchain कॉन्फ़िगरेशन को बदल देती है. साथ ही, Android के सभी कंपाइलेशन पर लागू होती है.

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

इस मामले में, भले ही jvmToolchain को किसी दूसरे वर्शन पर सेट किया गया हो, लेकिन Android टारगेट के Kotlin और Java कोड को JVM 11 को टारगेट करने के लिए कंपाइल किया जाएगा.

कंपाइलेशन-लेवल के कंपाइलर विकल्पों का इस्तेमाल करना (सबसे ज़्यादा प्राथमिकता)

सबसे ज़्यादा बारीकी से कंट्रोल करने के लिए, कंपाइलर के विकल्पों को हर कंपाइलेशन के हिसाब से कॉन्फ़िगर किया जा सकता है. उदाहरण के लिए, सिर्फ़ androidMain या androidHostTest पर. यह तब काम आता है, जब किसी खास कंपाइलेशन को किसी दूसरे जेवीएम वर्शन को टारगेट करना हो. यह सेटिंग, Kotlin टूलचेन और Android टारगेट-लेवल के विकल्पों, दोनों को बदल देती है.

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

इस कॉन्फ़िगरेशन से यह पक्का करने में मदद मिलती है कि Android टारगेट में मौजूद सभी कंपाइलेशन, जेवीएम 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 के लिए अलग-अलग ब्लॉक का इस्तेमाल करके, जेवीएम टारगेट कॉन्फ़िगर करने होंगे.

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

    kotlinOptions {
        jvmTarget = "11"
    }
}

11. उपभोक्ता के लिए निजी डेटा के रखरखाव के नियम पब्लिश करना

अगर आपकी केएमपी लाइब्रेरी को अपने उपभोक्ताओं के लिए, उपभोक्ता के लिए बनाए रखने के नियम (जैसे, 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 के स्टैंडर्ड पब्लिशिंग मैकेनिज़्म के साथ इंटिग्रेट होता है. केएमपी लाइब्रेरी को पब्लिश करने की स्टैंडर्ड प्रोसेस के अलावा, Android के लिए कोई खास तरीका अपनाने की ज़रूरत नहीं है.

अपनी लाइब्रेरी पब्लिश करने के लिए, JetBrains के आधिकारिक दस्तावेज़ में दिया गया तरीका अपनाएं: मल्टीप्लैटफ़ॉर्म लाइब्रेरी के लिए पब्लिश करने की सुविधा सेट अप करना.

लेगसी प्लग इन

KMP प्रोजेक्ट में Android टारगेट के लिए com.android.library का इस्तेमाल करते समय, आपको Android लाइब्रेरी पब्लिश करने की स्टैंडर्ड गाइड का पालन करना होगा. इससे, Android के लिए खास आर्टफ़ैक्ट (.aar) को तैयार और पब्लिश किया जा सकेगा.

ज़्यादा जानकारी के लिए, अपनी लाइब्रेरी को रिलीज़ के लिए तैयार करना लेख पढ़ें.

प्लगिन एपीआई का संदर्भ

नए प्लग इन का एपीआई प्लैटफ़ॉर्म, com.android.library से अलग है. नए डीएसएल और इंटरफ़ेस के बारे में ज़्यादा जानकारी के लिए, एपीआई का संदर्भ देखें:

Android-KMP लाइब्रेरी प्लग इन से जुड़ी आम समस्याएं

com.android.kotlin.multiplatform.library प्लग इन का नया वर्शन लागू करने पर, आपको ये समस्याएं आ सकती हैं: