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

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

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

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

नेटिव डिपेंडेंसी (आम तौर पर इस्तेमाल नहीं की जाती) को जोड़ने और मैनेज करने के बारे में जानने के लिए, नेटिव डिपेंडेंसी लेख पढ़ें.

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

1. डिपेंडेंसी के उस वर्शन के लिए कोई उपनाम जोड़ें जो आपको वर्शन कैटलॉग फ़ाइल के [versions] सेक्शन में चाहिए. इसे libs.versions.toml कहा जाता है. यह प्रोजेक्ट व्यू में gradle डायरेक्ट्री या Android व्यू में 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'
}

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

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 इस मेटाडेटा की जांच करता है. इससे, आपके ऐप्लिकेशन में इस्तेमाल किए गए एसडीके और डिपेंडेंसी से जुड़ी जानी-पहचानी समस्याओं के बारे में सूचनाएं मिलती हैं. साथ ही, कुछ मामलों में इन समस्याओं को हल करने के लिए कार्रवाई की जा सकने वाली प्रतिक्रिया मिलती है.

डेटा को कंप्रेस किया जाता है. साथ ही, 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
    }
}

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

एसडीके की अहम जानकारी

Android Studio, Google Play 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'
}