बिल्ड डिपेंडेंसी जोड़ना

Android Studio में मौजूद Gradle बिल्ड सिस्टम की मदद से, अपने बिल्ड में डिपेंडेंसी के तौर पर बाहरी बाइनरी या अन्य लाइब्रेरी मॉड्यूल शामिल किए जा सकते हैं. डिपेंडेंसी आपकी मशीन या किसी रिमोट रिपॉज़िटरी में हो सकती हैं. साथ ही, वे ट्रांज़िशन डिपेंडेंसी भी अपने-आप शामिल कर लेती हैं. इस पेज पर, Android प्रोजेक्ट में डिपेंडेंसी इस्तेमाल करने का तरीका बताया गया है. इसमें, Android Gradle प्लग इन (AGP) के खास व्यवहार और कॉन्फ़िगरेशन के बारे में जानकारी भी शामिल है. Gradle डिपेंडेंसी के बारे में ज़्यादा जानने के लिए, डिपेंडेंसी मैनेजमेंट के लिए Gradle गाइड देखें. हालांकि, ध्यान रखें कि आपके Android प्रोजेक्ट में सिर्फ़ इस पेज पर बताए गए डिपेंडेंसी कॉन्फ़िगरेशन का इस्तेमाल किया जाना चाहिए.

लाइब्रेरी या प्लग इन डिपेंडेंसी जोड़ना

वर्शन कैटलॉग का इस्तेमाल करके, बिल्ड डिपेंडेंसी जोड़ने और उन्हें मैनेज करने का सबसे अच्छा तरीका है. यह तरीका, नए प्रोजेक्ट डिफ़ॉल्ट रूप से इस्तेमाल करते हैं. इस सेक्शन में, Android प्रोजेक्ट के लिए इस्तेमाल किए जाने वाले सबसे सामान्य कॉन्फ़िगरेशन के बारे में बताया गया है. ज़्यादा विकल्पों के लिए, Gradle दस्तावेज़ देखें. वर्शन कैटलॉग का इस्तेमाल करने वाले ऐप्लिकेशन का उदाहरण देखने के लिए, अब Android में उपलब्ध है लेख पढ़ें. अगर आपने पहले से ही वर्शन कैटलॉग के बिना, बिल्ड डिपेंडेंसी सेट अप की हुई हैं और आपके पास एक से ज़्यादा मॉड्यूल वाला प्रोजेक्ट है, तो हमारा सुझाव है कि आप माइग्रेट करें.

नेटिव डिपेंडेंसी (सामान्य नहीं) जोड़ने और मैनेज करने के बारे में दिशा-निर्देश पाने के लिए, नेटिव डिपेंडेंसी देखें.

नीचे दिए गए उदाहरण में, हम अपने प्रोजेक्ट में रिमोट बाइनरी डिपेंडेंसी (Jetpack Macrobenchmark लाइब्रेरी), लोकल लाइब्रेरी मॉड्यूल डिपेंडेंसी (myLibrary), और प्लग इन डिपेंडेंसी (Android Gradle प्लग इन) जोड़ते हैं. अपने प्रोजेक्ट में इन डिपेंडेंसी को जोड़ने के सामान्य तरीके यहां दिए गए हैं:

1. अपनी पसंद के डिपेंडेंसी वर्शन के लिए, वर्शन कैटलॉग फ़ाइल के [versions] सेक्शन में एक दूसरा नाम जोड़ें. इसे libs.versions.toml कहा जाता है. यह नाम, Android व्यू में gradle डायरेक्ट्री या प्रोजेक्ट व्यू में Gradle स्क्रिप्ट में मौजूद होता है:

   [versions]
   agp = "8.3.0"
   androidx-macro-benchmark = "1.2.2"
   my-library = "1.4"
   
   [libraries]
   ...
   
   [plugins]
   ...
   

   उपनामों में डैश या अंडरस्कोर शामिल किए जा सकते हैं. ये उपनाम नेस्ट की गई वैल्यू जनरेट करते हैं, जिनका रेफ़रंस बिल्ड स्क्रिप्ट में दिया जा सकता है. रेफ़रंस, कैटलॉग के नाम से शुरू होते हैं, जो libs.versions.toml का libs हिस्सा होता है. हमारा सुझाव है कि एक वर्शन वाले कैटलॉग का इस्तेमाल करते समय, "libs" की डिफ़ॉल्ट वैल्यू को बनाए रखें.

2. libs.versions.toml फ़ाइल के [libraries] (रिमोट बाइनरी या लोकल लाइब्रेरी मॉड्यूल के लिए) या [plugins] (प्लग इन के लिए) सेक्शन में, डिपेंडेंसी के लिए कोई दूसरा नाम जोड़ें.

   [versions]
   ...
   
   [libraries]
   androidx-benchmark-macro = { group = "androidx.benchmark", name = "benchmark-macro-junit4", version.ref = "androidx-macro-benchmark" }
   my-library = { group = "com.myapplication", name = "mylibrary", version.ref = "my-library" }
   
   [plugins]
   androidApplication = { id = "com.android.application", version.ref = "agp" }
   

   कुछ लाइब्रेरी, पब्लिश किए गए बिल ऑफ़ मटीरियल (बीओएम) में उपलब्ध होती हैं. इसमें लाइब्रेरी की फ़ैमिली और उनके वर्शन को ग्रुप किया जाता है. आपके पास अपने वर्शन कैटलॉग और बिल्ड फ़ाइलों में बीओएम शामिल करने का विकल्प है. साथ ही, उसे उन वर्शन को मैनेज करने की अनुमति भी दी जा सकती है. ज़्यादा जानकारी के लिए, बिल ऑफ मटीरियल का इस्तेमाल करना लेख पढ़ें.

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

   Kotlin

   plugins {
     alias(libs.plugins.androidApplication)
   }
   
   dependencies {
     implementation(libs.androidx.benchmark.macro)
     implementation(libs.my.library)
   }

   Groovy

   plugins {
     alias 'libs.plugins.androidApplication'
   }
   
   dependencies {
     implementation libs.androidx.benchmark.macro
     implementation libs.my.library
   }

   प्लग इन के रेफ़रंस में, कैटलॉग के नाम के बाद plugins शामिल होता है. वहीं, वर्शन के रेफ़रंस में, कैटलॉग के नाम के बाद versions शामिल होता है. वर्शन के रेफ़रंस आम तौर पर नहीं होते. वर्शन के रेफ़रंस के उदाहरणों के लिए, एक जैसे वर्शन नंबर वाली डिपेंडेंसी देखें. लाइब्रेरी के रेफ़रंस में libraries क्वालिफ़ायर शामिल नहीं होता. इसलिए, लाइब्रेरी के किसी दूसरा नाम के शुरू में versions या plugins का इस्तेमाल नहीं किया जा सकता.

डिपेंडेंसी कॉन्फ़िगर करना

dependencies ब्लॉक में, कई अलग-अलग डिपेंडेंसी कॉन्फ़िगरेशन (जैसे, पहले दिखाया गया implementation) में से किसी एक का इस्तेमाल करके, लाइब्रेरी डिपेंडेंसी का एलान किया जा सकता है. हर डिपेंडेंसी कॉन्फ़िगरेशन, Gradle को डिपेंडेंसी इस्तेमाल करने के अलग-अलग निर्देश देता है. नीचे दी गई टेबल में, उन सभी कॉन्फ़िगरेशन के बारे में बताया गया है जिनका इस्तेमाल, Android प्रोजेक्ट में डिपेंडेंसी के लिए किया जा सकता है.

dependencies {
  // Executes lint checks from the ":checks" project at build time.
  lintChecks(project(":checks"))
  // Compiles lint checks from the ":checks-to-publish" into a
  // lint.jar file and publishes it to your Android library.
  lintPublish(project(":checks-to-publish"))
}

dependencies {
  // Executes lint checks from the ':checks' project at build time.
  lintChecks project(':checks')
  // Compiles lint checks from the ':checks-to-publish' into a
  // lint.jar file and publishes it to your Android library.
  lintPublish project(':checks-to-publish')
}

किसी खास बिल्ड वैरिएंट के लिए डिपेंडेंसी कॉन्फ़िगर करना

ऊपर दिए गए सभी कॉन्फ़िगरेशन, सभी बिल्ड वैरिएंट पर डिपेंडेंसी लागू करते हैं. अगर आपको सिर्फ़ किसी खास बिल्ड वैरिएंट सोर्स सेट या टेस्टिंग सोर्स सेट के लिए डिपेंडेंसी का एलान करना है, तो आपको कॉन्फ़िगरेशन के नाम को कैपिटल लेटर में लिखना होगा और उसके आगे बिल्ड वैरिएंट या टेस्टिंग सोर्स सेट का नाम जोड़ना होगा.

उदाहरण के लिए, implementation कॉन्फ़िगरेशन का इस्तेमाल करके, सिर्फ़ अपने "मुफ़्त" प्रॉडक्ट के फ़्लेवर में रिमोट बाइनरी डिपेंडेंसी जोड़ने के लिए, यह तरीका अपनाएं:

dependencies {
    freeImplementation("com.google.firebase:firebase-ads:21.5.1")
}

dependencies {
    freeImplementation 'com.google.firebase:firebase-ads:21.5.1'
}

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

// Initializes a placeholder for the freeDebugImplementation dependency configuration.
val freeDebugImplementation by configurations.creating

dependencies {
    freeDebugImplementation(project(":free-support"))
}

configurations {
    // Initializes a placeholder for the freeDebugImplementation dependency configuration.
    freeDebugImplementation {}
}

dependencies {
    freeDebugImplementation project(":free-support")
}

अपने लोकल टेस्ट और इंस्ट्रूमेंट किए गए टेस्ट के लिए implementation डिपेंडेंसी जोड़ने के लिए, यह तरीका अपनाएं:

dependencies {
    // Adds a remote binary dependency only for local tests.
    testImplementation("junit:junit:4.12")

    // Adds a remote binary dependency only for the instrumented test APK.
    androidTestImplementation("androidx.test.espresso:espresso-core:3.6.1")
}

dependencies {
    // Adds a remote binary dependency only for local tests.
    testImplementation 'junit:junit:4.12'

    // Adds a remote binary dependency only for the instrumented test APK.
    androidTestImplementation 'androidx.test.espresso:espresso-core:3.6.1'
}

हालांकि, इस स्थिति में कुछ कॉन्फ़िगरेशन काम के नहीं होते. उदाहरण के लिए, androidTestApi कॉन्फ़िगरेशन का इस्तेमाल करने पर, आपको यह चेतावनी दिखती है, क्योंकि अन्य मॉड्यूल androidTest पर निर्भर नहीं हो सकते:

WARNING: Configuration 'androidTestApi' is obsolete and has been replaced with
'androidTestImplementation'.

डिपेंडेंसी का क्रम

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

उदाहरण के लिए, अगर आपके प्रोजेक्ट में यह जानकारी दी गई है:

• LIB_A और LIB_B पर निर्भरता (इसी क्रम में)
• साथ ही, LIB_A, LIB_C और LIB_D पर निर्भर करता है (इसी क्रम में)
• साथ ही, LIB_B भी LIB_C पर निर्भर करता है

इसके बाद, फ़्लैट डिपेंडेंसी ऑर्डर इस तरह होगा:

1. LIB_A
2. LIB_D
3. LIB_B
4. LIB_C

इससे यह पक्का होता है कि LIB_A और LIB_B, दोनों LIB_C को बदल सकते हैं. साथ ही, LIB_D अब भी LIB_B से ज़्यादा प्राथमिकता वाला है, क्योंकि LIB_A (जो उस पर निर्भर करता है) की प्राथमिकता LIB_B से ज़्यादा है.

अलग-अलग प्रोजेक्ट के सोर्स/डिपेंडेंसी से मेनिफ़ेस्ट को मर्ज करने के तरीके के बारे में ज़्यादा जानने के लिए, एक से ज़्यादा मेनिफ़ेस्ट फ़ाइलें मर्ज करना लेख पढ़ें.

Play Console के लिए डिपेंडेंसी की जानकारी

आपका ऐप्लिकेशन बनाते समय, AGP में मेटाडेटा शामिल होता है. इसमें, आपके ऐप्लिकेशन में कोड पैकेज के लिए इस्तेमाल की जाने वाली लाइब्रेरी डिपेंडेंसी के बारे में जानकारी होती है. आपका ऐप्लिकेशन अपलोड करते समय, Play Console इस मेटाडेटा की जांच करता है. इससे, आपके ऐप्लिकेशन में इस्तेमाल किए जाने वाले SDK टूल और डिपेंडेंसी से जुड़ी समस्याओं के बारे में सूचनाएं दी जा सकती हैं. साथ ही, कुछ मामलों में उन समस्याओं को हल करने के लिए सुझाव भी दिए जा सकते हैं.

इस डेटा को Google Play की साइनिंग पासकोड की मदद से, कंप्रेस और एन्क्रिप्ट किया जाता है. साथ ही, इसे आपके रिलीज़ किए गए ऐप्लिकेशन के साइनिंग ब्लॉक में सेव किया जाता है. हमारा सुझाव है कि उपयोगकर्ताओं को सुरक्षित और बेहतर अनुभव देने के लिए, इस डिपेंडेंसी फ़ाइल को बनाए रखें. अपने मॉड्यूल की build.gradle.kts फ़ाइल में, यहां दिया गया dependenciesInfo ब्लॉक शामिल करके ऑप्ट आउट किया जा सकता है.

android {
    dependenciesInfo {
        // Disables dependency metadata when building APKs.
        includeInApk = false
        // Disables dependency metadata when building Android App Bundles.
        includeInBundle = false
    }
}

हमारी नीतियों और डिपेंडेंसी से जुड़ी संभावित समस्याओं के बारे में ज़्यादा जानने के लिए, अपने ऐप्लिकेशन में तीसरे पक्ष के SDK टूल इस्तेमाल करने से जुड़ा हमारा सहायता पेज देखें.

SDK टूल के बारे में अहम जानकारी

Android Studio, वर्शन कैटलॉग फ़ाइल में लिंट से जुड़ी चेतावनियां दिखाता है. साथ ही, Google Play SDK Index में मौजूद सार्वजनिक SDK टूल के लिए, प्रोजेक्ट के स्ट्रक्चर वाले डायलॉग बॉक्स में भी ये चेतावनियां दिखाता है. ऐसा तब होता है, जब ये समस्याएं होती हैं:

• SDK टूल के लेखकों ने उन्हें पुराने के तौर पर मार्क किया हो.
• SDK टूल, Play की नीतियों का उल्लंघन करते हैं.

चेतावनियां इस बात का संकेत हैं कि आपको उन डिपेंडेंसी को अपडेट करना चाहिए. ऐसा इसलिए, क्योंकि पुराने वर्शन का इस्तेमाल करने पर, आने वाले समय में Google Play Console पर पब्लिश करने में समस्या आ सकती है.

वर्शन कैटलॉग के बिना बिल्ड डिपेंडेंसी जोड़ना

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

plugins {
    id("com.android.application")
}

android { ... }

dependencies {
    // Dependency on a remote binary
    implementation("com.example.android:app-magic:12.3")
    // Dependency on a local library module
    implementation(project(":mylibrary"))
}

plugins {
    id 'com.android.application'
}

android { ... }

dependencies {
    // Dependency on a remote binary
    implementation 'com.example.android:app-magic:12.3'
    // Dependency on a local library module
    implementation project(':mylibrary')
}

इस बिल्ड फ़ाइल में, "com.example.android" नेमस्पेस ग्रुप में "app-magic" लाइब्रेरी के 12.3 वर्शन पर डिपेंडेंसी का एलान किया गया है. रिमोट बाइनरी डिपेंडेंसी का एलान, इनके लिए शॉर्टहैंड है:

implementation(group = "com.example.android", name = "app-magic", version = "12.3")

implementation group: 'com.example.android', name: 'app-magic', version: '12.3'

बिल्ड फ़ाइल में, "mylibrary" नाम के Android लाइब्रेरी मॉड्यूल पर डिपेंडेंसी का एलान भी किया गया है. यह नाम, आपकी settings.gradle.kts फ़ाइल में include: के साथ तय की गई लाइब्रेरी के नाम से मेल खाना चाहिए. ऐप्लिकेशन बनाने पर, बिल्ड सिस्टम लाइब्रेरी मॉड्यूल को संकलित करता है और संकलित किए गए कॉन्टेंट को ऐप्लिकेशन में पैकेज करता है.

बिल्ड फ़ाइल में, Android Gradle प्लग इन (com.application.android) पर डिपेंडेंसी का एलान भी किया जाता है. अगर आपके पास एक ही प्लग इन का इस्तेमाल करने वाले कई मॉड्यूल हैं, तो सभी मॉड्यूल के बिल्ड क्लासपाथ पर, प्लग इन का सिर्फ़ एक वर्शन हो सकता है. हर मॉड्यूल की बिल्ड स्क्रिप्ट में वर्शन बताने के बजाय, आपको रूट बिल्ड स्क्रिप्ट में वर्शन के साथ प्लग इन की डिपेंडेंसी शामिल करनी चाहिए. साथ ही, यह भी बताना चाहिए कि इसे लागू न करें. apply false जोड़ने से, Gradle को प्लग इन के वर्शन को नोट करने के लिए कहा जाता है, लेकिन उसे रूट बिल्ड में इस्तेमाल नहीं किया जाता. आम तौर पर, रूट बिल्ड स्क्रिप्ट में इस plugins ब्लॉक के अलावा कुछ नहीं होता.

plugins {
    id("org.jetbrains.kotlin.android") version "1.9.0" apply false
}

plugins {
    id ‘com.android.application’ version ‘8.3.0-rc02’ apply false
}

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

plugins {
    id("com.android.application") version "8.3.0"
}

plugins {
    id 'com.android.application' version '8.3.0-rc02'
}