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

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

चेतावनी: डिपेंडेंसी की जानकारी देते समय, आपको 'com.android.tools.build:gradle:3.+' जैसे डाइनैमिक वर्शन नंबर का इस्तेमाल नहीं करना चाहिए. इस सुविधा का इस्तेमाल करने से, वर्शन के अनचाहे अपडेट हो सकते हैं. साथ ही, वर्शन के बीच के अंतर को हल करने में समस्या आ सकती है और परफ़ॉर्मेंस खराब हो सकती है.

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

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

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

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

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

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

कॉन्फ़िगरेशन	व्यवहार
implementation	Gradle, डिपेंडेंसी को कंपाइल क्लासपाथ में जोड़ता है और डिपेंडेंसी को बिल्ड आउटपुट में पैकेज करता है. जब आपका मॉड्यूल किसी implementation डिपेंडेंसी को कॉन्फ़िगर करता है, तो इससे Gradle को यह पता चलता है कि आपको कॉम्पाइल करने के समय, मॉड्यूल को दूसरे मॉड्यूल के लिए डिपेंडेंसी को लीक नहीं करना है. इसका मतलब है कि डिपेंडेंसी को उन अन्य मॉड्यूल के लिए उपलब्ध नहीं कराया जाता है जो मौजूदा मॉड्यूल पर निर्भर करते हैं. api के बजाय इस डिपेंडेंसी कॉन्फ़िगरेशन का इस्तेमाल करने से, बिल्ड में लगने वाले समय में काफ़ी सुधार हो सकता है. ऐसा इसलिए, क्योंकि इससे उन मॉड्यूल की संख्या कम हो जाती है जिन्हें बिल्ड सिस्टम को फिर से कंपाइल करना पड़ता है. उदाहरण के लिए, अगर implementation डिपेंडेंसी अपने एपीआई में बदलाव करती है, तो Gradle, सिर्फ़ उसी डिपेंडेंसी और सीधे इस पर निर्भर मॉड्यूल को फिर से इकट्ठा करता है. ज़्यादातर ऐप्लिकेशन और टेस्ट मॉड्यूल को इस कॉन्फ़िगरेशन का इस्तेमाल करना चाहिए.
api	Gradle, कंपाइल क्लासपाथ और बिल्ड आउटपुट में डिपेंडेंसी जोड़ता है. जब किसी मॉड्यूल में api डिपेंडेंसी शामिल होती है, तो इससे Gradle को यह पता चलता है कि मॉड्यूल उस डिपेंडेंसी को ट्रांज़िशन के तौर पर दूसरे मॉड्यूल में एक्सपोर्ट करना चाहता है, ताकि वह रनटाइम और कॉम्पाइल करने के समय, दोनों में उपलब्ध हो. इस कॉन्फ़िगरेशन का इस्तेमाल सावधानी से करें और सिर्फ़ उन डिपेंडेंसी के साथ करें जिन्हें आपको अन्य अपस्ट्रीम उपभोक्ताओं को ट्रांज़िट रूप से एक्सपोर्ट करने की ज़रूरत है. अगर कोई api डिपेंडेंसी अपना एक्सटर्नल एपीआई बदलती है, तो Gradle उन सभी मॉड्यूल को फिर से कॉम्पाइल करता है जिनके पास कॉम्पाइल करने के समय उस डिपेंडेंसी का ऐक्सेस होता है. api डिपेंडेंसी की संख्या ज़्यादा होने पर, बिल्ड में काफ़ी समय लग सकता है. अगर आपको किसी डिपेंडेंसी के एपीआई को किसी अलग मॉड्यूल के लिए एक्सपोज़ नहीं करना है, तो लाइब्रेरी मॉड्यूल के लिए implementation डिपेंडेंसी का इस्तेमाल करें.
compileOnly	Gradle, डिपेंडेंसी को सिर्फ़ कंपाइल क्लासपाथ में जोड़ता है (यानी, इसे बिल्ड आउटपुट में नहीं जोड़ा जाता). यह तब काम आता है, जब कोई Android मॉड्यूल बनाया जा रहा हो और आपको कंपाइलेशन के दौरान डिपेंडेंसी की ज़रूरत हो. हालांकि, रनटाइम के दौरान इसे शामिल करना ज़रूरी नहीं है. उदाहरण के लिए, अगर आपने किसी ऐसी लाइब्रेरी का इस्तेमाल किया है जिसमें सिर्फ़ कंपाइल के समय के एनोटेशन शामिल हैं, तो उस लाइब्रेरी को compileOnly के तौर पर मार्क किया जा सकता है. आम तौर पर, एनोटेशन का इस्तेमाल कोड जनरेट करने के लिए किया जाता है, लेकिन अक्सर इसे बिल्ड आउटपुट में शामिल नहीं किया जाता. इस कॉन्फ़िगरेशन का इस्तेमाल करने पर, आपके लाइब्रेरी मॉड्यूल में रनटाइम की शर्त शामिल होनी चाहिए, ताकि यह पता लगाया जा सके कि डिपेंडेंसी उपलब्ध है या नहीं. इसके बाद, डिपेंडेंसी उपलब्ध न होने पर भी लाइब्रेरी के काम करने के तरीके में बदलाव किया जा सकता है. इससे, फ़ाइनल ऐप्लिकेशन का साइज़ कम करने में मदद मिलती है. ऐसा, ज़रूरी न होने वाली ट्रांज़िशनल डिपेंडेंसी को न जोड़कर किया जाता है. ध्यान दें: Android Archive (AAR) डिपेंडेंसी के साथ, compileOnly कॉन्फ़िगरेशन का इस्तेमाल नहीं किया जा सकता.
runtimeOnly	Gradle, डिपेंडेंसी को सिर्फ़ बिल्ड आउटपुट में जोड़ता है, ताकि उसे रनटाइम के दौरान इस्तेमाल किया जा सके. इसका मतलब है कि उसे कंपाइल क्लास पाथ में नहीं जोड़ा गया है. Android पर इसका इस्तेमाल बहुत कम किया जाता है. हालांकि, आम तौर पर इसे सर्वर ऐप्लिकेशन में लॉगिंग लागू करने के लिए इस्तेमाल किया जाता है. उदाहरण के लिए, कोई लाइब्रेरी, लॉगिंग एपीआई का इस्तेमाल कर सकती है जिसमें लागू करने की सुविधा शामिल नहीं है. उस लाइब्रेरी का इस्तेमाल करने वाले लोग, उसे implementation डिपेंडेंसी के तौर पर जोड़ सकते हैं. साथ ही, असल लॉगिंग लागू करने के लिए, runtimeOnly डिपेंडेंसी भी शामिल कर सकते हैं.
ksp kapt annotationProcessor	ये कॉन्फ़िगरेशन, लाइब्रेरी उपलब्ध कराते हैं. ये लाइब्रेरी, आपके कोड को कॉम्पाइल करने से पहले, एनोटेशन और अन्य सिंबल को प्रोसेस करती हैं. आम तौर पर, ये आपके कोड की पुष्टि करते हैं या अतिरिक्त कोड जनरेट करते हैं. इससे, आपको कम कोड लिखना पड़ता है. ऐसी डिपेंडेंसी जोड़ने के लिए, आपको ksp, kapt या annotationProcessor कॉन्फ़िगरेशन का इस्तेमाल करके, एनोटेशन प्रोसेसर क्लासपाथ में जोड़ना होगा. इन कॉन्फ़िगरेशन का इस्तेमाल करने से, एनोटेशन प्रोसेसर क्लासपाथ से कंपाइल क्लासपाथ को अलग करके, बिल्ड की परफ़ॉर्मेंस बेहतर होती है. अगर Gradle को कंपाइल क्लासपाथ पर एनोटेशन प्रोसेसर मिलते हैं, तो यह कंपाइलेशन से बचने की सुविधा को बंद कर देता है. इससे बिल्ड के समय पर बुरा असर पड़ता है (Gredle 5.0 और उसके बाद के वर्शन, कंपाइल क्लासपाथ पर मिले एनोटेशन प्रोसेसर को अनदेखा करते हैं). अगर किसी डिपेंडेंसी की JAR फ़ाइल में यह फ़ाइल शामिल है, तो Android Gradle प्लग इन यह मान लेता है कि वह एनोटेशन प्रोसेसर है: META-INF/services/javax.annotation.processing.Processor अगर प्लग इन को कोई ऐसा एनोटेशन प्रोसेसर मिलता है जो कंपाइल क्लासपाथ में मौजूद है, तो इससे बिल्ड में गड़बड़ी होती है. ksp एक Kotlin सिंबल प्रोसेसर है और इसे Kotlin कंपाइलर चलाता है. kapt और apt अलग-अलग टूल हैं. ये Kotlin या Java कंपाइलर के काम करने से पहले, एनोटेशन को प्रोसेस करते हैं. यह तय करते समय कि किस कॉन्फ़िगरेशन का इस्तेमाल करना है, इन बातों का ध्यान रखें: अगर कोई प्रोसेसर, Kotlin सिंबल प्रोसेसर के तौर पर उपलब्ध है, तो उसका इस्तेमाल ksp डिपेंडेंसी के तौर पर करें. Kotlin सिंबल प्रोसेसर का इस्तेमाल करने के बारे में जानकारी पाने के लिए, kapt से ksp पर माइग्रेट करना देखें. अगर प्रोसेसर, Kotlin सिंबल प्रोसेसर के तौर पर उपलब्ध नहीं है, तो: अगर आपके प्रोजेक्ट में Kotlin सोर्स शामिल है (हालांकि, इसमें Java सोर्स भी शामिल हो सकता है), तो उसे शामिल करने के लिए kapt का इस्तेमाल करें. अगर आपके प्रोजेक्ट में सिर्फ़ Java सोर्स का इस्तेमाल किया जाता है, तो उसे शामिल करने के लिए annotationProcessor का इस्तेमाल करें. एनोटेशन प्रोसेसर का इस्तेमाल करने के बारे में ज़्यादा जानने के लिए, एनोटेशन प्रोसेसर जोड़ना देखें.
lintChecks	इस कॉन्फ़िगरेशन का इस्तेमाल करके, ऐसी लाइब्रेरी शामिल करें जिसमें lint की जांच शामिल हो. आपको Android ऐप्लिकेशन प्रोजेक्ट बनाते समय, Gradle को ये जांच करनी होंगी. ध्यान दें कि जिन AAR में lint.jar फ़ाइल होती है वे उस lint.jar फ़ाइल में बताई गई जांच अपने-आप चलाएंगी; आपको साफ़ तौर पर lintChecks डिपेंडेंसी जोड़ने की ज़रूरत नहीं है. इससे, एक ही डिपेंडेंसी में लाइब्रेरी और उनसे जुड़ी लिंट जांच तय की जा सकती है. इससे यह पक्का होता है कि जब लोग आपकी लाइब्रेरी का इस्तेमाल करते हैं, तब आपकी जांच की जाती है.
lintPublish	Android लाइब्रेरी प्रोजेक्ट में इस कॉन्फ़िगरेशन का इस्तेमाल करके, लिंट की जांच को शामिल करें, ताकि Gradle को आपके AAR में मौजूद lint.jar फ़ाइल और पैकेज में इकट्ठा किया जा सके. इसकी वजह से, आपके एएआर का इस्तेमाल करने वाले प्रोजेक्ट, लिंट जांच को भी लागू करते हैं. अगर आपने पब्लिश किए गए AAR में, लिंट की जांच शामिल करने के लिए, पहले lintChecks डिपेंडेंसी कॉन्फ़िगरेशन का इस्तेमाल किया था, तो आपको lintPublish कॉन्फ़िगरेशन का इस्तेमाल करने के लिए, उन डिपेंडेंसी को माइग्रेट करना होगा. Kotlin 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")) } Groovy 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 कॉन्फ़िगरेशन का इस्तेमाल करके, सिर्फ़ अपने "मुफ़्त" प्रॉडक्ट के फ़्लेवर में रिमोट बाइनरी डिपेंडेंसी जोड़ने के लिए, यह तरीका अपनाएं:

Kotlin

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

Groovy

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

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

Kotlin

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

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

Groovy

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

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

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

Kotlin

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")
}

Groovy

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 टूल, Google Play की नीतियों का उल्लंघन करते हैं.

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

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

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

Kotlin

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"))
}

Groovy

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 वर्शन पर डिपेंडेंसी का एलान किया गया है. रिमोट बाइनरी डिपेंडेंसी का एलान, इनके लिए शॉर्टहैंड है:

Kotlin

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

Groovy

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 ब्लॉक के अलावा कुछ नहीं होता.

Kotlin

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

ग्रूवी

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

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

Kotlin

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

Groovy

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