टूल और लाइब्रेरी के बीच इंटरडिपेंडेंसी

बिल्ड डिपेंडेंसी, बाहरी कॉम्पोनेंट होते हैं. ये आपके प्रोजेक्ट को सही तरीके से बनाने के लिए ज़रूरी होते हैं. कोई बिल्ड, लाइब्रेरी, प्लगिन, सबप्रोजेक्ट, Android SDK, Kotlin और Java कंपाइलर जैसे टूल, Android Studio जैसे डेवलपमेंट एनवायरमेंट, और Gradle पर निर्भर हो सकता है.

हर डिपेंडेंसी को खुद अन्य डिपेंडेंसी की ज़रूरत हो सकती है. हम इन्हें ट्रांज़िटिव डिपेंडेंसी कहते हैं. ये आपके ऐप्लिकेशन में इस्तेमाल की जाने वाली कुल डिपेंडेंसी को तेज़ी से बढ़ा सकती हैं. जब आपको किसी डिपेंडेंसी को अपग्रेड करना हो, चाहे वह कोई लाइब्रेरी, टूल या Android SDK हो, तो वह अपग्रेड कई अन्य डिपेंडेंसी को भी अपग्रेड कर सकता है.

आम तौर पर, इससे कोई समस्या नहीं होगी, क्योंकि कई लाइब्रेरी सिमैंटिक वर्शनिंग नाम की स्कीम का इस्तेमाल करती हैं. ये लाइब्रेरी, अपने पुराने वर्शन के साथ काम करने के लिए, किए जाने वाले बदलावों को सीमित करती हैं.

सिमेंटिक वर्शनिंग, major.minor.patch फ़ॉर्मैट का इस्तेमाल करती है. उदाहरण के लिए, वर्शन नंबर 4.8.3 में, 4 major वर्शन है, 8 minor वर्शन है, और 3 patch नंबर है. major वाले हिस्से में बदलाव होने पर, हो सकता है कि लाइब्रेरी के एपीआई या व्यवहार में नुकसान पहुंचा सकने वाले बदलाव हों. इससे आपके बिल्ड या ऐप्लिकेशन के काम करने के तरीके पर असर पड़ सकता है.

जब minor (नई सुविधाएं) या patch (गड़बड़ी ठीक करना) वाले हिस्से बदलते हैं, तो लाइब्रेरी डेवलपर आपको बताते हैं कि लाइब्रेरी अब भी काम कर रही है और इससे आपके ऐप्लिकेशन पर कोई असर नहीं पड़ना चाहिए.

ध्यान दें: कुछ लाइब्रेरी, एक्सपेरिमेंटल या ऑप्ट-इन एपीआई दिखा सकती हैं. इन एपीआई में बदलाव हो सकता है. भले ही, ये छोटे या पैच रिलीज़ हों. इन एपीआई की मदद से, डेवलपर नई सुविधाओं या एपीआई में किए गए बदलावों को आज़मा सकते हैं. साथ ही, वे इन सुविधाओं या बदलावों के स्टेबल होने के दौरान, सुझाव/राय दे सकते हैं या शिकायत कर सकते हैं. इन एपीआई का इस्तेमाल सावधानी से करें, क्योंकि इनमें बदलाव हो सकता है. साथ ही, आपको minor और patch अपग्रेड के बीच अपने कोड में बदलाव करना पड़ सकता है.

आपके बिल्ड में मौजूद रिलेशनशिप

Android बिल्ड में इनके बीच संबंध होते हैं:

• सोर्स कोड - ऐसा कोड और संसाधन जिन पर आपका कंट्रोल हो
• लाइब्रेरी डिपेंडेंसी - बाहरी लाइब्रेरी या मॉड्यूल, जिन्हें आपका प्रोजेक्ट और सबप्रोजेक्ट, बिल्ड करते समय शामिल करते हैं
• टूल - कंपाइलर, प्लग इन, और एसडीके टूल, जो आपके सोर्स को ऐप्लिकेशन या लाइब्रेरी में बदलते हैं

पहली इमेज. रिश्ते बनाएं

सोर्स कोड

आपका सोर्स कोड, Kotlin या Java कोड होता है. इसे आपके ऐप्लिकेशन या लाइब्रेरी में लिखा जाता है. (C++ का इस्तेमाल करने के बारे में ज़्यादा जानने के लिए, Android एनडीके देखें.)

सोर्स कोड, लाइब्रेरी (Kotlin और Java रनटाइम लाइब्रेरी के साथ-साथ) और Android SDK पर निर्भर करता है. साथ ही, इसके लिए Kotlin या Java कंपाइलर की ज़रूरत होती है.

कुछ सोर्स कोड में ऐसे एनोटेशन शामिल होते हैं जिन्हें प्रोसेस करने के लिए अतिरिक्त समय की ज़रूरत होती है. उदाहरण के लिए, अगर Jetpack Compose कोड लिखा जा रहा है, तो आपको @Composable जैसे एनोटेशन जोड़ने होंगे. इन्हें Compose Kotlin कंपाइलर प्लग इन से प्रोसेस करना ज़रूरी है. अन्य एनोटेशन को Kotlin सिंबल प्रोसेसर (केएसपी) या अलग-अलग एनोटेशन-प्रोसेसिंग टूल से प्रोसेस किया जा सकता है.

लाइब्रेरी डिपेंडेंसी

लाइब्रेरी में बाइट कोड होता है, जिसे आपके ऐप्लिकेशन के हिस्से के तौर पर शामिल किया जाता है. यह Java JAR, Android लाइब्रेरी (AAR) या आपके बिल्ड में मौजूद कोई सबप्रोजेक्ट हो सकता है. कई लाइब्रेरी, सिमैंटिक वर्शनिंग का इस्तेमाल करती हैं. इससे आपको यह समझने में मदद मिल सकती है कि अपग्रेड किए जाने पर, वे कब काम करती हैं या कब नहीं.

लाइब्रेरी में अक्सर दूसरी लाइब्रेरी पर ट्रांज़िटिव डिपेंडेंसी होती हैं. इससे आपको साफ़ तौर पर मैनेज की जाने वाली चीज़ों की संख्या कम हो जाती है. आपको डायरेक्ट डिपेंडेंसी तय करनी होती हैं और Gradle उन्हें ट्रांज़िटिव डिपेंडेंसी के साथ खींच लेता है. डायरेक्ट डिपेंडेंसी को अपग्रेड करने से, उनकी ट्रांज़िटिव डिपेंडेंसी भी अपग्रेड हो सकती हैं.

कभी-कभी किसी लाइब्रेरी को रनटाइम (minSdk) या कंपाइल के समय (compileSdk) Android SDK के कम से कम वर्शन की ज़रूरत पड़ सकती है. ऐसा तब ज़रूरी होता है, जब कोई लाइब्रेरी, Android SDK या उसके उपलब्ध कराए गए JDK एपीआई में शामिल फ़ंक्शन का इस्तेमाल करती है. आपके ऐप्लिकेशन का असरदार minSdk, आपके ऐप्लिकेशन और उसकी सभी डायरेक्ट और ट्रांज़िटिव लाइब्रेरी डिपेंडेंसी के लिए अनुरोध किया गया सबसे ज़्यादा minSdk होता है.

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

टूल

ग्रेडल	Gradle, बिल्ड टूल है. यह आपकी बिल्ड फ़ाइलों को पढ़ता है और आपका ऐप्लिकेशन या लाइब्रेरी जनरेट करता है. साथ ही, यह प्लगिन के लिए एपीआई को एक्सपोज़ करता है, ताकि इसकी क्षमताओं को बढ़ाया जा सके. Gradle, एक या उससे ज़्यादा Java वर्चुअल मशीनों पर कई प्रोसेस चलाता है. साथ ही, इसके Java प्लग इन, JDK में मौजूद Java टूल को कॉल करते हैं.
Gradle प्लगिन	Gradle प्लगिन, नए टास्क और कॉन्फ़िगरेशन तय करके Gradle को बेहतर बनाते हैं. अपने बिल्ड में कोई प्लग इन लागू करने से, बिल्ड की कुछ खास सुविधाएं चालू हो जाती हैं. इन्हें आपकी बिल्ड स्क्रिप्ट में डेटा के तौर पर कॉन्फ़िगर किया जाता है. Android बिल्ड के लिए, सबसे ज़रूरी Gradle प्लगिन Android Gradle प्लगिन (AGP) है.
संकलनकर्ता	Kotlin या Java कंपाइलर, आपके सोर्स कोड को एक्ज़ीक्यूटेबल बाइट कोड में बदल देता है. Kotlin कंपाइलर, प्लगिन एपीआई को एक्सपोज़ करता है. इससे बाहरी विश्लेषण और कोड जनरेशन को सीधे कंपाइलर के अंदर चलाया जा सकता है. साथ ही, पार्स किए गए कोड स्ट्रक्चर को ऐक्सेस किया जा सकता है.
कंपाइलर प्लगिन	कंपाइलर प्लग इन, Kotlin कंपाइलर के अंदर विश्लेषण और कोड जनरेशन करते हैं. ऐसा तब होता है, जब Kotlin कंपाइलर आपके कोड का विश्लेषण कर रहा होता है. साथ ही, ये तब इंस्टॉल होते हैं, जब बिल्ड में उनके Gradle प्लग इन लागू किए जाते हैं.
Android SDK	Android SDK में, Android के किसी खास वर्शन के लिए Android प्लैटफ़ॉर्म और Java API के साथ-साथ, उससे जुड़े टूल शामिल होते हैं. इन टूल की मदद से, SDK टूल को मैनेज किया जा सकता है, ऐप्लिकेशन बनाए जा सकते हैं, और Android डिवाइसों के साथ कम्यूनिकेट किया जा सकता है. साथ ही, Android डिवाइसों को एम्युलेट किया जा सकता है. Android SDK का हर वर्शन, Java के ऐसे एपीआई उपलब्ध कराता है जिन्हें आपका सोर्स कोड ऐक्सेस कर सकता है. साथ ही, Android के पुराने वर्शन पर उन एपीआई का इस्तेमाल करने के लिए, डिशुगरिंग की सुविधा देता है.
जेडीके	Java Development Kit में Java लाइब्रेरी और एक्ज़ीक्यूटेबल फ़ाइलें होती हैं. इनकी मदद से, Java सोर्स को कंपाइल किया जाता है और Java ऐप्लिकेशन चलाए जाते हैं. Android बिल्ड में कई जेडीके इस्तेमाल किए जाते हैं. ज़्यादा जानकारी के लिए, Android बिल्ड में Java के वर्शन देखें.

Gradle स्कोप

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

उदाहरण के लिए, एजीपी 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)
}

Groovy

// In a module-level build script
// Using a version catalog
plugins {
    alias(libs.plugins.example.plugin)
}

dependencies {
    implementation libs.example.library
}