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

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

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

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

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

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

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

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

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

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

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

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

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

   ग्रूवी

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

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

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

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

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

ग्रूवी

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

ग्रूवी

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

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

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

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

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

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

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

ग्रूवी

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

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

Kotlin

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

ग्रूवी

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

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

बिल्ड फ़ाइल, '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"
}

ग्रूवी

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