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

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

ऐप्लिकेशन बनाते समय, एजीपी में ऐसा मेटाडेटा शामिल होता है जो आपके ऐप्लिकेशन में कंपाइल की गई लाइब्रेरी डिपेंडेंसी के बारे में बताता है. ऐप्लिकेशन अपलोड करते समय, 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
    }
}

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

SDK टूल से जुड़ी अहम जानकारी

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

• SDK टूल बनाने वाले डेवलपर ने उन्हें पुराने के तौर पर मार्क किया हो.
• एसडीके, Google 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'
}