बिल्ड डिपेंडेंसी, आपके प्रोजेक्ट को सही तरीके से बनाने के लिए ज़रूरी बाहरी कॉम्पोनेंट हैं. बिल्ड लाइब्रेरी, प्लगिन, सबप्रोजेक्ट, Android SDK, Kotlin और Java कंपाइलर जैसे टूल, Android Studio, और Gradle जैसे डेवलपमेंट एनवायरमेंट पर निर्भर करता है.
हर डिपेंडेंसी के लिए अन्य डिपेंडेंसी की ज़रूरत हो सकती है. हम इन्हें ट्रांज़िशन डिपेंडेंसी कहते हैं. इनसे आपके ऐप्लिकेशन में इस्तेमाल होने वाली कुल डिपेंडेंसी की संख्या तेज़ी से बढ़ सकती है. अगर आपको किसी डिपेंडेंसी को अपग्रेड करना है, चाहे वह लाइब्रेरी, टूल हो या Android SDK
आम तौर पर, इससे कोई समस्या नहीं होती, क्योंकि कई लाइब्रेरी सेमांटिक वर्शनिंग नाम की स्कीम का इस्तेमाल करती हैं. ये लाइब्रेरी, अपने पुराने वर्शन के साथ काम करने के लिए, किए जाने वाले बदलावों पर पाबंदी लगाती हैं.
सिमेंटिक वर्शन, major.minor.patch
फ़ॉर्मैट का इस्तेमाल करता है. उदाहरण के लिए, वर्शन नंबर 4.8.3 में, 4 major
वर्शन, 8 minor
, और 3 patch
नंबर है. major
वाला हिस्सा बदलने पर, लाइब्रेरी में एपीआई या उसके व्यवहार में काफ़ी बदलाव हो सकते हैं. इससे आपके बिल्ड या ऐप्लिकेशन के व्यवहार पर असर पड़ सकता है.
जब minor
(नई सुविधाएं) या patch
(बग ठीक करना) वाले हिस्से बदलते हैं, तो लाइब्रेरी के डेवलपर आपको बता रहे हैं कि लाइब्रेरी अब भी काम करती है और इससे आपके ऐप्लिकेशन पर कोई असर नहीं पड़ेगा.
इस तरह के बदलावों पर नज़र बनाए रखना ज़रूरी है. इसमें कई डिपेंडेंसी अपग्रेड टूल मदद कर सकते हैं.
आपके बिल्ड में संबंध
Android बिल्ड में इनके बीच संबंध होते हैं:
- सोर्स कोड - वह कोड और संसाधन जिन पर आपका कंट्रोल है
- लाइब्रेरी डिपेंडेंसी - बाहरी लाइब्रेरी या मॉड्यूल, जिन्हें आपके प्रोजेक्ट और सब-प्रोजेक्ट में शामिल किया जाता है
- टूल - कंपाइलर, प्लग इन, और SDK टूल, जो आपके सोर्स को ऐप्लिकेशन या लाइब्रेरी में बदलते हैं
सोर्स कोड
आपका सोर्स कोड, Kotlin या Java कोड है, जिसे अपने ऐप्लिकेशन या लाइब्रेरी में लिखा जाता है. C++ का इस्तेमाल करने के बारे में जानकारी पाने के लिए, Android NDK देखें.
सोर्स कोड, लाइब्रेरी (इनमें Kotlin और Java रनटाइम लाइब्रेरी शामिल हैं) और Android SDK टूल पर निर्भर करता है. साथ ही, इसके लिए Kotlin या Java कंपाइलर की ज़रूरत होती है.
कुछ सोर्स कोड में ऐसे एनोटेशन शामिल होते हैं जिन्हें अतिरिक्त प्रोसेसिंग की ज़रूरत होती है. उदाहरण के लिए, अगर Jetpack Compose कोड लिखा जा रहा है, तो @Composable
जैसे एनोटेशन जोड़े जा सकते हैं. इन एनोटेशन को Compose Kotlin कंपाइलर प्लगिन की मदद से प्रोसेस करना पड़ता है. अन्य एनोटेशन को Kotlin Symbol प्रोसेसर (केएसपी) या अलग एनोटेशन-प्रोसेसिंग टूल की मदद से प्रोसेस किया जा सकता है.
लाइब्रेरी डिपेंडेंसी
लाइब्रेरी में, आपके ऐप्लिकेशन के हिस्से के तौर पर खींचा गया बाइटकोड होता है. यह आपके बिल्ड में, एक Java JAR, Android लाइब्रेरी (AAR) या सब-प्रोजेक्ट हो सकता है. कई लाइब्रेरी, सेमेंटिक वर्शनिंग का इस्तेमाल करती हैं. इससे आपको यह समझने में मदद मिलती है कि अपग्रेड करने पर वे काम करती हैं या नहीं.
लाइब्रेरी, दोबारा इस्तेमाल के लिए दूसरी लाइब्रेरी पर निर्भर हो सकती हैं, जिसे ट्रांज़िव डिपेंडेंसी कहा जाता है. इससे उन डिपेंडेंसी की संख्या कम हो जाती है जिन्हें आपको साफ़ तौर पर मैनेज करना होगा. आप उन डिपेंडेंसी के बारे में बताते हैं जिनका सीधे तौर पर इस्तेमाल किया जाता है और Gradle उन्हें ट्रांज़िशन डिपेंडेंसी के साथ खींचता है. ध्यान रखें कि सीधे तौर पर डिपेंड करने वाले पैकेज को अपग्रेड करने पर, ट्रांज़िशन के तौर पर डिपेंड करने वाले पैकेज भी अपग्रेड हो सकते हैं.
कभी-कभी किसी लाइब्रेरी को रनटाइम (minSdk
) या कंपाइल करने के समय (compileSdk
) Android SDK टूल के कम से कम वर्शन की ज़रूरत पड़ सकती है. ऐसा तब ज़रूरी होता है, जब कोई लाइब्रेरी Android SDK टूल या इसके दिए गए JDK API में शामिल फ़ंक्शन का इस्तेमाल करती है. आपके ऐप्लिकेशन का असरदार minSdk
, आपके ऐप्लिकेशन और उसकी सभी डायरेक्ट और ट्रांज़िशन लाइब्रेरी डिपेंडेंसी के लिए अनुरोध किया गया सबसे ज़्यादा minSdk
होता है.
कुछ लाइब्रेरी का इस्तेमाल करने के लिए, खास Gradle प्लग इन की ज़रूरत पड़ सकती है. ये हेल्पर प्लग इन, अक्सर Kotlin सिंबल प्रोसेसर या अन्य एनोटेशन प्रोसेसर इंस्टॉल करते हैं. ये प्रोसेसर, कोड जनरेट करते हैं या लाइब्रेरी की सुविधाओं का इस्तेमाल करने के लिए, आपके सोर्स के कंपाइलेशन में बदलाव करते हैं. उदाहरण के लिए, Jetpack Room में एनोटेशन और एक KSP शामिल है, जो उन्हें जनरेट किए गए कोड में बदल देता है, ताकि डेटाबेस में डेटा को वापस पाया और उसमें बदलाव किया जा सके. Jetpack Compose के लिए, Compose कंपाइलर प्लग इन की ज़रूरत होती है, ताकि एनोटेट किए गए फ़ंक्शन में बदलाव किया जा सके. इससे यह मैनेज किया जा सकता है कि फ़ंक्शन को फिर से कब और कैसे चलाया जाए.
टूल
Gradle |
Gradle एक बिल्ड टूल है, जो आपकी बिल्ड फ़ाइलों को पढ़ता है और आपका ऐप्लिकेशन या लाइब्रेरी जनरेट करता है. साथ ही, प्लग इन के लिए एपीआई भी उपलब्ध कराता है, ताकि उनकी सुविधाओं को बढ़ाया जा सके. Gradle, एक या उससे ज़्यादा Java वर्चुअल मशीनों पर कई प्रोसेस चलाता है और इसके Java प्लगिन, JDK में Java टूल को कॉल करते हैं. |
Gradle प्लग इन |
Gradle प्लगिन, नए टास्क और कॉन्फ़िगरेशन तय करके Gradle को बेहतर बनाते हैं. अपने बिल्ड में प्लग इन लागू करने से, बिल्ड की खास सुविधाएं चालू हो जाती हैं. ये सुविधाएं, आपकी बिल्ड स्क्रिप्ट में डेटा के तौर पर कॉन्फ़िगर की जाती हैं. Android बिल्ड के लिए, Android Gradle प्लग इन (AGP) सबसे ज़रूरी Gradle प्लग इन है. |
संकलनकर्ता |
Kotlin या Java कंपाइलर आपके सोर्स कोड को एक्ज़ीक्यूटेबल बाइटकोड में बदल देता है. Kotlin कंपाइलर एक प्लगिन एपीआई दिखाता है, जो बाहरी विश्लेषण और कोड जनरेशन को सीधे कंपाइलर के अंदर चलाने की सुविधा देता है. साथ ही, यह पार्स किए गए कोड स्ट्रक्चर को ऐक्सेस करता है. |
कंपाइलर प्लगिन |
जब Kotlin कंपाइलर आपके कोड का विश्लेषण कर रहा होता है, तब कंपाइलर प्लगिन, Kotlin कंपाइलर के अंदर विश्लेषण और कोड जनरेशन करते हैं. साथ ही, जब आपके कोड बिल्ड में उनके Gradle प्लग इन लागू करते हैं, तब ये इंस्टॉल होते हैं. |
Android SDK |
Android SDK टूल में, Android के खास वर्शन और उससे जुड़े टूल के लिए, Android प्लैटफ़ॉर्म और Java API शामिल होते हैं. इन टूल की मदद से, SDK टूल को मैनेज किया जा सकता है, ऐप्लिकेशन बनाए जा सकते हैं, और Android डिवाइसों से संपर्क किया जा सकता है. साथ ही, इनकी मदद से Android डिवाइसों को एमुलेट भी किया जा सकता है. Android SDK टूल के हर वर्शन में खास Java API होते हैं, जिन्हें आपका सोर्स कोड ऐक्सेस कर सकता है. साथ ही, Android के पुराने वर्शन पर उन एपीआई का इस्तेमाल करने के लिए, डिसगूअरिंग की सुविधा भी मिलती है. |
जेडीके |
Java डेवलपमेंट किट, जिसमें Java लाइब्रेरी और Java सोर्स को कंपाइल करने और Java ऐप्लिकेशन चलाने के लिए, एक्ज़ीक्यूटेबल शामिल होते हैं. Android बिल्ड में कई JDK काम करते हैं. ज़्यादा जानकारी के लिए, Android बिल्ड में Java के वर्शन देखें. |
Gradle स्कोप
Gradle ग्रुप, लाइब्रेरी डिपेंडेंसी को अलग-अलग दायरों में रखा जाता है (जिन्हें Gradle API में कॉन्फ़िगरेशन कहा जाता है). इससे आपको अपने बिल्ड के अलग-अलग हिस्सों में इस्तेमाल की जाने वाली लाइब्रेरी डिपेंडेंसी के अलग-अलग सेट तय करने की सुविधा मिलती है. उदाहरण के लिए, हो सकता है कि आप अपने पब्लिश किए गए ऐप्लिकेशन या लाइब्रेरी में, JUnit जैसी टेस्ट लाइब्रेरी शामिल न करना चाहें. हालांकि, यूनिट टेस्ट बनाने और उन्हें लागू करने के दौरान, आपको इन लाइब्रेरी की ज़रूरत पड़ सकती है. अपने कोड का विश्लेषण करने के लिए, सिंबल या ऐनोटेशन प्रोसेसर को जोड़ने के लिए स्कोप का इस्तेमाल किया जाता है.
उदाहरण के लिए, AGP implementation
और api
स्कोप तय करता है. इनसे यह तय किया जाता है कि किसी डिपेंडेंसी को आपके सब-प्रोजेक्ट के उपयोगकर्ताओं को दिखाया जाना चाहिए या नहीं.
Android बिल्ड में इस्तेमाल किए गए इन और अन्य स्कोप के ब्यौरे के लिए, डिपेंडेंसी कॉन्फ़िगर करना देखें.
अपनी बिल्ड फ़ाइलों के dependencies
ब्लॉक में, लाइब्रेरी डिपेंडेंसी जोड़ें. ऐसा या तो group:artifact:version
स्ट्रिंग के तौर पर करें:
Kotlin
// In a module-level build script // explicit dependency strings ("group:artifact:version") dependencies { implementation("com.example:library1:1.2.3") api("com.example:library2:1.1.1") }
Groovy
// In a module-level build script // explicit dependency strings ("group:artifact:version") dependencies { implementation 'com.example:library1:1.2.3' api 'com.example:library2:1.1.1' }
या वर्शन कैटलॉग में:
# Version catalog - gradle/libs.versions.toml
[versions]
exampleLib = "1.2.3"
examplePlugin = "2.3.4"
[libraries]
example-library = { group = "com.example", name = "library", version.ref = "exampleLib" }
[plugins]
example-plugin = { id = "com.example.plugin", version.ref = "examplePlugin" }
और अपनी बिल्ड फ़ाइलों में जनरेट किए गए वैरिएबल की जानकारी दें:
Kotlin
// In a module-level build script // Using a version catalog plugins { alias(libs.plugins.example.plugin) } dependencies { implementation(libs.example.library) }
ग्रूवी
// In a module-level build script // Using a version catalog plugins { alias(libs.plugins.example.plugin) } dependencies { implementation libs.example.library }