Android Studio में मौजूद Gradle बिल्ड सिस्टम की मदद से, अपने बिल्ड में डिपेंडेंसी के तौर पर बाहरी बाइनरी या अन्य लाइब्रेरी मॉड्यूल शामिल किए जा सकते हैं. डिपेंडेंसी आपकी मशीन या किसी रिमोट रिपॉज़िटरी में हो सकती हैं और उनके ज़रिए बताई गई सभी ट्रांज़िशन डिपेंडेंसी भी अपने-आप शामिल हो जाती हैं. इस पेज पर, Android प्रोजेक्ट में डिपेंडेंसी इस्तेमाल करने का तरीका बताया गया है. इसमें, Android Gradle प्लग इन (AGP) के हिसाब से व्यवहार और कॉन्फ़िगरेशन की जानकारी भी शामिल है. Gradle डिपेंडेंसी के बारे में गहराई से जानकारी पाने के लिए, आपको डिपेंडेंसी मैनेजमेंट के लिए Gradle गाइड भी देखनी चाहिए. हालांकि, याद रखें कि आपके Android प्रोजेक्ट में इस पेज पर बताए गए सिर्फ़ डिपेंडेंसी कॉन्फ़िगरेशन का इस्तेमाल किया जाना चाहिए.
कोई लाइब्रेरी या प्लगिन डिपेंडेंसी जोड़ना
वर्शन कैटलॉग का इस्तेमाल करके, बिल्ड डिपेंडेंसी जोड़ने और उन्हें मैनेज करने का सबसे अच्छा तरीका है. यह तरीका, नए प्रोजेक्ट डिफ़ॉल्ट रूप से इस्तेमाल करते हैं. इस सेक्शन में, Android प्रोजेक्ट के लिए इस्तेमाल किए जाने वाले सबसे सामान्य कॉन्फ़िगरेशन के बारे में बताया गया है. ज़्यादा विकल्पों के लिए, Gradle दस्तावेज़ देखें. वर्शन कैटलॉग का इस्तेमाल करने वाले ऐप्लिकेशन का उदाहरण देखने के लिए, अब Android में उपलब्ध है देखें. अगर आपने वर्शन कैटलॉग के बिना, पहले से ही बिल्ड डिपेंडेंसी सेट अप की हुई हैं और आपके पास एक से ज़्यादा मॉड्यूल वाला प्रोजेक्ट है, तो हमारा सुझाव है कि आप माइग्रेट करें.
नेटिव डिपेंडेंसी (आम तौर पर नहीं) जोड़ने और मैनेज करने के बारे में दिशा-निर्देश पाने के लिए, नेटिव डिपेंडेंसी देखें.
नीचे दिए गए उदाहरण में, हमने अपने प्रोजेक्ट में रिमोट बाइनरी डिपेंडेंसी (Jetpack Macrobenchmark लाइब्रेरी), लोकल लाइब्रेरी मॉड्यूल डिपेंडेंसी (myLibrary
), और एक प्लगिन डिपेंडेंसी (Android Gradle प्लग इन) जोड़ा है. अपने प्रोजेक्ट में इन डिपेंडेंसी को जोड़ने का सामान्य तरीका यहां दिया गया है:
डिपेंडेंसी के उस वर्शन के लिए कोई उपनाम जोड़ें जिसे आपको वर्शन कैटलॉग फ़ाइल के
[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" की डिफ़ॉल्ट वैल्यू बनाए रखें.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" }
कुछ लाइब्रेरी, पब्लिश किए गए बिल ऑफ़ मटीरियल (बीओएम) में उपलब्ध हैं. इनमें लाइब्रेरी के फ़ैमिली ग्रुप और उनके वर्शन को ग्रुप किया जाता है. आप अपने वर्शन कैटलॉग में कोई BOM शामिल कर सकते हैं और फ़ाइलें बना सकते हैं और उसे आपके लिए उन वर्शन को मैनेज करने दे सकते हैं. ज़्यादा जानकारी के लिए, बिल ऑफ मटीरियल का इस्तेमाल करना लेख पढ़ें.
जिन मॉड्यूल के लिए डिपेंडेंसी की ज़रूरत है उनकी बिल्ड स्क्रिप्ट में, डिपेंडेंसी के उपनाम का रेफ़रंस जोड़ें. किसी बिल्ड स्क्रिप्ट से किसी उपनाम का रेफ़रंस देते समय, उसके अंडरस्कोर और डैश को बिंदु में बदलें. हमारी मॉड्यूल-लेवल बिल्ड स्क्रिप्ट कुछ इस तरह दिखेगी:
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 को डिपेंडेंसी इस्तेमाल करने के अलग-अलग निर्देश देता है. नीचे दी गई टेबल में, उन सभी कॉन्फ़िगरेशन के बारे में बताया गया है जिनका इस्तेमाल, Android प्रोजेक्ट में डिपेंडेंसी के लिए किया जा सकता है.
कॉन्फ़िगरेशन | व्यवहार |
---|---|
implementation |
Gradle, डिपेंडेंसी को कंपाइल क्लासपाथ में जोड़ता है और डिपेंडेंसी को बिल्ड आउटपुट में पैकेज करता है. जब आपका
मॉड्यूल किसी implementation डिपेंडेंसी को कॉन्फ़िगर करता है, तो इससे Gradle को यह पता चलता है कि आपको कॉम्पाइल करने के समय, मॉड्यूल को दूसरे मॉड्यूल के लिए डिपेंडेंसी को लीक नहीं करना है. इसका मतलब है कि मौजूदा मॉड्यूल पर निर्भर
अन्य मॉड्यूल के लिए, डिपेंडेंसी
उपलब्ध नहीं कराई जाती.
|
api |
Gradle, कंपाइल क्लासपाथ और बिल्ड
आउटपुट में डिपेंडेंसी जोड़ता है. जब किसी मॉड्यूल में api डिपेंडेंसी शामिल होती है, तो इससे Gradle को यह पता चलता है कि मॉड्यूल उस डिपेंडेंसी को ट्रांज़िशन के तौर पर दूसरे मॉड्यूल में एक्सपोर्ट करना चाहता है, ताकि वह रनटाइम और कॉम्पाइल करने के समय, दोनों में उपलब्ध हो.
इस कॉन्फ़िगरेशन का इस्तेमाल सावधानी से करें. साथ ही, सिर्फ़ उन डिपेंडेंसी के साथ इस्तेमाल करें जिन्हें आपको अपस्ट्रीम के अन्य उपभोक्ताओं को ट्रांज़िशन के तौर पर एक्सपोर्ट करना है. अगर कोई
|
compileOnly |
Gradle, डिपेंडेंसी को सिर्फ़ कंपाइल क्लासपाथ में जोड़ता है
(यानी, इसे बिल्ड आउटपुट में नहीं जोड़ा जाता). यह तब काम आता है, जब कोई Android मॉड्यूल बनाया जा रहा हो और आपको कंपाइलेशन के दौरान डिपेंडेंसी की ज़रूरत हो. हालांकि, रनटाइम के दौरान इसे शामिल करना ज़रूरी नहीं है. उदाहरण के लिए, अगर आपने किसी ऐसी लाइब्रेरी का इस्तेमाल किया है जिसमें सिर्फ़ कंपाइल के समय के एनोटेशन शामिल हैं, तो उस लाइब्रेरी को compileOnly के तौर पर मार्क किया जा सकता है. आम तौर पर, एनोटेशन का इस्तेमाल कोड जनरेट करने के लिए किया जाता है, लेकिन अक्सर इसे बिल्ड आउटपुट में शामिल नहीं किया जाता.
अगर इस कॉन्फ़िगरेशन का इस्तेमाल किया जाता है, तो आपके लाइब्रेरी मॉड्यूल में रनटाइम की शर्त शामिल होनी चाहिए, ताकि यह देखा जा सके कि डिपेंडेंसी उपलब्ध है या नहीं. इसके बाद, इसके काम करने के तरीके में बदलाव करें, ताकि उपलब्ध न होने पर भी यह काम कर सके. इससे, फ़ाइनल ऐप्लिकेशन का साइज़ कम करने में मदद मिलती है. ऐसा, ज़रूरी न होने वाली ट्रांज़िशनल डिपेंडेंसी को न जोड़कर किया जाता है.
ध्यान दें: Android Archive (AAR) डिपेंडेंसी के साथ, |
runtimeOnly |
Gradle, डिपेंडेंसी को सिर्फ़ बिल्ड आउटपुट में जोड़ता है, ताकि उसे रनटाइम के दौरान इस्तेमाल किया जा सके. इसका मतलब है कि इसे कंपाइल क्लासपाथ में नहीं जोड़ा जाता.
Android पर इसका इस्तेमाल बहुत कम किया जाता है. हालांकि, आम तौर पर इसे सर्वर ऐप्लिकेशन में लॉगिंग लागू करने के लिए इस्तेमाल किया जाता है. उदाहरण के लिए, लाइब्रेरी ऐसे लॉगिंग एपीआई का इस्तेमाल कर सकती है जिसमें
लागू करने की प्रक्रिया शामिल न हो. उस लाइब्रेरी का इस्तेमाल करने वाले लोग, उसे implementation डिपेंडेंसी के तौर पर जोड़ सकते हैं. साथ ही, असल लॉगिंग लागू करने के लिए, runtimeOnly डिपेंडेंसी भी शामिल कर सकते हैं.
|
ksp |
ये कॉन्फ़िगरेशन ऐसी लाइब्रेरी उपलब्ध कराते हैं जो आपके कोड को कंपाइल करने से पहले उसमें एनोटेशन और दूसरे सिंबल को प्रोसेस करती हैं. आम तौर पर, ये आपके कोड की पुष्टि करते हैं या अतिरिक्त कोड जनरेट करते हैं. इससे, आपको कोड लिखने की ज़रूरत कम हो जाती है. ऐसी डिपेंडेंसी जोड़ने के लिए, आपको अगर इसकी JAR फ़ाइल में ये फ़ाइल शामिल हैं, तो 'Android Gradle प्लग इन' मानता है कि डिपेंडेंसी एक एनोटेशन प्रोसेसर है:
अगर प्लग इन को कोई ऐसा एनोटेशन प्रोसेसर मिलता है जो कंपाइल क्लासपाथ में मौजूद है, तो इससे बिल्ड में गड़बड़ी होती है.
यह तय करते समय कि किस कॉन्फ़िगरेशन का इस्तेमाल करना है, इन बातों का ध्यान रखें:
एनोटेशन प्रोसेसर का इस्तेमाल करने के बारे में ज़्यादा जानने के लिए, एनोटेशन प्रोसेसर जोड़ना लेख पढ़ें. |
lintChecks |
इस कॉन्फ़िगरेशन का इस्तेमाल करके, ऐसी लाइब्रेरी शामिल करें जिसमें lint की जांच शामिल हो. आपको Android ऐप्लिकेशन प्रोजेक्ट बनाते समय, Gradle को ये जांच करनी होंगी. ध्यान दें कि जिन AAR फ़ाइलों में |
lintPublish |
Android लाइब्रेरी प्रोजेक्ट में इस कॉन्फ़िगरेशन का इस्तेमाल करके, लिंट
की जांच को शामिल करें, ताकि Gradle को आपके AAR में मौजूद lint.jar फ़ाइल और पैकेज में इकट्ठा किया जा सके. इसकी वजह से, आपके एएआर का इस्तेमाल करने वाले प्रोजेक्ट,
लिंट जांच को भी लागू करते हैं. अगर आपने
पब्लिश किए गए एएआर में लिंट की जांच शामिल करने के लिए,
lintChecks डिपेंडेंसी कॉन्फ़िगरेशन का इस्तेमाल किया है, तो आपको lintPublish कॉन्फ़िगरेशन का
इस्तेमाल करने के लिए, उन डिपेंडेंसी को माइग्रेट करना होगा.
Kotlindependencies { // 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")) } Groovydependencies { // 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.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' }
हालांकि, इस स्थिति में कुछ कॉन्फ़िगरेशन का कोई मतलब नहीं निकलता. उदाहरण के लिए,
दूसरे मॉड्यूल 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
पर निर्भर करता है
फिर, फ़्लैट डिपेंडेंसी ऑर्डर इस तरह होगा:
LIB_A
LIB_D
LIB_B
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 टूल के लेखकों ने उन्हें पुराने के तौर पर मार्क किया हो.
- 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")) }
ग्रूवी
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" }
ग्रूवी
plugins { id 'com.android.application' version '8.3.0-rc02' }