Gradle एक बिल्ड सिस्टम है जो Android एप्लिकेशन के कंपाइलेशन, परीक्षण और पैकेजिंग को स्वचालित करता है। Apache Ant या Maven के विपरीत, यह इन्क्रीमेंटल बिल्ड और परिणाम कैशिंग का समर्थन करता है। इसकी विशेषताओं के बारे में अधिक जानकारी के लिए आधिकारिक Gradle दस्तावेज़ देखें। 2013 से, यह टूल Android Studio में Android प्रोजेक्ट्स के लिए मानक बिल्ड सिस्टम के रूप में उपयोग किया जा रहा है।
मुख्य बिंदु
Gradle एक ओपन-सोर्स बिल्ड ऑटोमेशन टूल है जो Java में लिखा गया है और JVM पर चलता है। यह इनपुट के रूप में स्रोत कोड, निर्भरताएँ और संसाधन लेता है, और आउटपुट के रूप में एक तैयार एप्लिकेशन — Android के लिए APK या AAB — उत्पन्न करता है। इसके मूल में, Gradle कार्यों के निर्देशित चक्रीय ग्राफ (DAG) की अवधारणा का उपयोग करता है, जहाँ प्रत्येक कार्य काम की एक परमाणु इकाई है और उनके बीच संबंध निष्पादन क्रम निर्धारित करते हैं। Make या Ant के विपरीत, Gradle को चरणों के अनुक्रम को मैन्युअल रूप से वर्णित करने की आवश्यकता नहीं है: कार्यों के बीच निर्भरताएँ घोषित करना पर्याप्त है, और सिस्टम स्वयं इष्टतम क्रम निर्धारित करेगा। यह दृष्टिकोण Gradle को किसी भी आकार की परियोजनाओं के लिए लचीला और स्केलेबल बनाता है।
सिस्टम तीन निष्पादन चरणों का उपयोग करता है: आरंभीकरण (भाग लेने वाली परियोजनाओं की पहचान), कॉन्फ़िगरेशन (कार्य ग्राफ का निर्माण) और निष्पादन (आवश्यक क्रम में कार्य चलाना)। कॉन्फ़िगरेशन चरण Gradle की एक प्रमुख विशेषता है: संपूर्ण बिल्ड स्क्रिप्ट कार्य शुरू होने से पहले चलती है, जो शर्तों के आधार पर ग्राफ में गतिशील परिवर्तन की अनुमति देती है। यह संभव बनाता है, उदाहरण के लिए, कोड दोहराए बिना केवल विशिष्ट बिल्ड वेरिएंट के लिए कार्य जोड़ना। बिल्डर Groovy में लिखा गया है, लेकिन कॉन्फ़िगरेशन फ़ाइलें दो भाषाओं का समर्थन करती हैं: Groovy DSL और Kotlin DSL।
Gradle के लिए Android प्लगइन com.android.application और com.android.library से मिलकर बना है, जो Android टूल के साथ काम करने के लिए प्रोजेक्ट में कार्य जोड़ते हैं। जब कोई डेवलपर बिल्ड शुरू करता है, Gradle दर्जनों कार्यों को क्रमिक रूप से निष्पादित करता है: javac या kotlinc के माध्यम से Kotlin और Java का संकलन, AAPT2 के माध्यम से संसाधन प्रसंस्करण, R.java उत्पन्न करना, D8 या R8 के माध्यम से बाइटकोड का DEX में संकलन, APK पर हस्ताक्षर और ज़िप करना। प्रत्येक कार्य जाँचता है कि क्या उसका इनपुट डेटा बदल गया है, और यदि नहीं, तो कैश किए गए परिणाम का उपयोग करता है। इस तंत्र को इन्क्रीमेंटल बिल्ड कहा जाता है और यह पूर्ण पुनर्निर्माण की तुलना में पुनर्संकलन को 60–80% तक तेज़ करता है।
Android मॉड्यूल कॉन्फ़िगरेशन build.gradle.kts फ़ाइल के android ब्लॉक में सेट किया जाता है। ब्लॉक के अंदर, compileSdk, minSdk, targetSdk, ऐप संस्करण, हस्ताक्षर और अन्य पैरामीटर परिभाषित किए जाते हैं। Gradle स्वचालित रूप से प्रत्येक मॉड्यूल के लिए कई बिल्ड वेरिएंट बनाता है — प्रकार (release, debug) और फ्लेवर का संयोजन। उदाहरण के लिए, दो फ्लेवर और दो प्रकारों वाले मॉड्यूल के लिए, Gradle चार कार्य उत्पन्न करता है: assembleDemoDebug, assembleDemoRelease, assembleFullDebug, assembleFullRelease। इन सभी कार्यों को व्यक्तिगत रूप से निष्पादित किया जा सकता है या सभी वेरिएंट के लिए एक साथ एक ही कमांड से चलाया जा सकता है।
प्रत्येक Android प्रोजेक्ट में दो स्तरों का कॉन्फ़िगरेशन होता है: रूट build.gradle.kts (सभी मॉड्यूल के लिए सेटिंग्स) और मॉड्यूल-स्तरीय build.gradle.kts (एक विशिष्ट मॉड्यूल के लिए सेटिंग्स)। रूट फ़ाइल में प्लगइन्स को लागू किए बिना घोषित किया जाता है, रिपॉजिटरी और सामान्य चर। मॉड्यूल फ़ाइल में, प्लगइन्स विशिष्ट मॉड्यूल पर लागू होते हैं और बिल्ड पैरामीटर कॉन्फ़िगर किए जाते हैं। यह दृष्टिकोण संस्करण कैटलॉग या ext-ब्लॉक के माध्यम से निर्भरता संस्करणों के केंद्रीकृत प्रबंधन की अनुमति देता है।
@Suppress("UnstableApiUsage")
plugins {
id("com.android.application") version "8.2.2"
id("org.jetbrains.kotlin.android") version "1.9.22"
}
android {
namespace = "com.example.myapp"
compileSdk = 34
defaultConfig {
applicationId = "com.example.myapp"
minSdk = 24
targetSdk = 34
versionCode = 1
versionName = "1.0"
}
}dependencies ब्लॉक build.gradle.kts का एक और महत्वपूर्ण तत्व है। यह उन लाइब्रेरीज़, मॉड्यूल और फ़ाइल निर्भरताओं को सूचीबद्ध करता है जिनकी एप्लिकेशन को आवश्यकता है। Gradle कई निर्भरता कॉन्फ़िगरेशन का समर्थन करता है: implementation (केवल वर्तमान मॉड्यूल के लिए उपलब्ध), api (आश्रित मॉड्यूल के लिए भी उपलब्ध), testImplementation (केवल परीक्षणों के लिए), androidTestImplementation (इंस्ट्रुमेंटेड परीक्षणों के लिए) और compileOnly (केवल संकलन समय पर)। प्रत्येक कॉन्फ़िगरेशन निर्भरता ग्राफ में वर्ग दृश्यता का प्रबंधन करता है, जो बिल्ड समय और अंतिम आर्टिफैक्ट आकार को प्रभावित करता है।
dependencies {
implementation("androidx.core:core-ktx:1.12.0")
implementation("androidx.lifecycle:lifecycle-runtime-ktx:2.7.0")
implementation("androidx.activity:activity-compose:1.8.2")
testImplementation("junit:junit:4.13.2")
androidTestImplementation("androidx.test.ext:junit:1.1.5")
}Build variant बिल्ड प्रकार और उत्पाद फ्लेवर का संयोजन है जो अद्वितीय सेटिंग्स, कोड और संसाधनों के साथ ऐप संस्करण को परिभाषित करता है। बिल्ड प्रकार पैकेजिंग पैरामीटर परिभाषित करता है: debug (डिबगिंग और .debug प्रत्यय के साथ) या release (अस्पष्टीकरण और हस्ताक्षर के साथ)। उत्पाद फ्लेवर कार्यात्मक वेरिएंट परिभाषित करता है: उदाहरण के लिए, demo (सीमित संस्करण) और full (अतिरिक्त सुविधाओं वाला पूर्ण संस्करण)। Gradle स्वचालित रूप से प्रत्येक संयोजन के लिए कार्य उत्पन्न करता है, जिससे सभी संस्करणों को एक ही कमांड से बनाया जा सकता है।
android {
buildTypes {
release {
isMinifyEnabled = true
proguardFiles(
getDefaultProguardFile("proguard-android-optimize.txt"),
"proguard-rules.pro"
)
}
debug {
applicationIdSuffix = ".debug"
}
}
flavorDimensions += "version"
productFlavors {
create("demo") {
dimension = "version"
applicationIdSuffix = ".demo"
}
create("full") {
dimension = "version"
applicationIdSuffix = ".full"
}
}
}प्रत्येक build variant का एक अलग सोर्स सेट होता है। Gradle निर्देशिकाओं src/demo/release, src/full/debug और अन्य का उपयोग करता है, जो किसी विशिष्ट वेरिएंट के लिए अद्वितीय संसाधन, मेनिफेस्ट और स्रोत फ़ाइलें संग्रहीत करते हैं। सामान्य कोड src/main में रहता है। यह दृष्टिकोण मुख्य तर्क को पुन: उपयोग करने और केवल अलग-अलग भागों को बदलने की अनुमति देता है: स्ट्रिंग्स, आइकन, API एंडपॉइंट या कॉन्फ़िगरेशन फ़ाइलें। एक सोर्स सेट main से किसी भी संसाधन को ओवरराइड कर सकता है: मेनिफेस्ट, drawable, values या Kotlin क्लासेस भी। किसी विशिष्ट वेरिएंट का निर्माण करते समय, Gradle main और संबंधित सोर्स सेट से फ़ाइलों को मर्ज करता है, जिसमें वेरिएंट की फ़ाइलों को प्राथमिकता दी जाती है।
Gradle प्लगइन इकोसिस्टम Android एप्लिकेशन विकास के सभी चरणों को कवर करता है। Google के आधिकारिक प्लगइन्स में com.android.application (ऐप मॉड्यूल के लिए), com.android.library (लाइब्रेरी मॉड्यूल के लिए), com.android.test (परीक्षण मॉड्यूल के लिए) और JetBrains से Kotlin प्लगइन्स शामिल हैं। प्लगइन्स प्रोजेक्ट में नए कार्य जोड़ते हैं, DSL को नए कॉन्फ़िगरेशन ब्लॉक के साथ विस्तारित करते हैं और अतिरिक्त टूल कनेक्ट करते हैं। com.android.application प्लगइन के बिना, कोई प्रोजेक्ट APK नहीं बना सकता: यह प्लगइन सभी Android-विशिष्ट कार्यों को पंजीकृत करता है और उन्हें बिल्ड ग्राफ में जोड़ता है।
तृतीय-पक्ष प्लगइन्स अधिक विशिष्ट कार्यों को हल करते हैं। Google Services (com.google.gms.google-services) Firebase और Google Play Services को एकीकृत करता है, स्वचालित रूप से google-services.json को बिल्ड में सम्मिलित करता है। Hilt (dagger.hilt.android.plugin) संकलन समय पर निर्भरता इंजेक्शन कोड उत्पन्न करता है। Safe Args (androidx.navigation.safeargs.kotlin) फ़्रैगमेंट के बीच नेविगेशन के लिए टाइप-सेफ क्लास बनाता है। प्रत्येक प्लगइन रूट build.gradle.kts में प्लगइन ब्लॉक के माध्यम से जोड़ा जाता है और आमतौर पर न्यूनतम कॉन्फ़िगरेशन की आवश्यकता होती है। Gradle स्वचालित रूप से प्लगइन्स के बीच ट्रांज़िटिव निर्भरताओं को हल करता है और Bom फ़ाइलों और संस्करण कैटलॉग के माध्यम से संस्करण अनुकूलता सुनिश्चित करता है।
कार्य (task) Gradle में काम की एक परमाणु इकाई है। प्रत्येक कार्य में इनपुट डेटा, आउटपुट डेटा और एक क्रिया होती है। Android के लिए अंतर्निहित कार्यों में assemble (सभी वेरिएंट का निर्माण), lint (कोड जाँच), test (यूनिट परीक्षण चलाना) और clean (अस्थायी फ़ाइलों की सफाई) शामिल हैं। डेवलपर Groovy या Kotlin DSL का उपयोग करके अपने स्वयं के कार्य जोड़ सकते हैं। कस्टम कार्य नियमित संचालन को स्वचालित करने के लिए उपयोगी होते हैं: रिपोर्ट उत्पन्न करना, आर्टिफैक्ट कॉपी करना, परीक्षण उपकरणों पर तैनात करना या CI सिस्टम के साथ एकीकृत करना।
tasks.register("printBuildInfo") {
description = "बिल्ड जानकारी प्रदर्शित करता है"
group = "custom"
doLast {
println("Build variant: ${project.name}")
println("Version: ${android.defaultConfig.versionName}")
}
}प्रत्येक कार्य dependsOn तंत्र के माध्यम से अन्य कार्यों पर निर्भर हो सकता है। यदि कार्य A, कार्य B पर निर्भर है, Gradle गारंटी देता है कि B, A से पहले निष्पादित होगा। सिस्टम को प्रत्येक जोड़ी के लिए मैन्युअल रूप से क्रम निर्दिष्ट करने की आवश्यकता नहीं है — निर्भरताएँ घोषित करना पर्याप्त है, और Gradle स्वतंत्र कार्यों के समानांतर निष्पादन के लिए अनुकूलित एक निर्देशित ग्राफ बनाएगा। Android प्लगइन के अंतर्निहित कार्य पहले से ही आपस में जुड़े हुए हैं: lint संकलन पर निर्भर करता है, test assemble पर निर्भर करता है, assembleDebug compileDebugKotlin पर निर्भर करता है। डेवलपर dependsOn, mustRunAfter या shouldRunAfter का उपयोग करके ग्राफ के किसी भी नोड में अपने स्वयं के कार्य सम्मिलित कर सकते हैं।
एक सामान्य समस्या है निर्भरता संस्करण विरोध, जब दो लाइब्रेरीज़ को एक ही ट्रांज़िटिव निर्भरता के विभिन्न संस्करणों की आवश्यकता होती है। Gradle विरोध त्रुटि की रिपोर्ट करता है, लेकिन हमेशा स्वचालित समाधान प्रदान नहीं करता। निदान के लिए, ./gradlew :app:dependencies कमांड का उपयोग करें, जो पूर्ण निर्भरता वृक्ष आउटपुट करता है। resolutionStrategy ब्लॉक के माध्यम से विरोध करने वाली लाइब्रेरी के संस्करण को बलपूर्वक निर्दिष्ट करने की अनुशंसा की जाती है। एक अन्य सामान्य परिदृश्य है धीमा बिल्ड इन्क्रीमेंटल प्रोसेसिंग की कमी के कारण। सुनिश्चित करें कि सभी प्लगइन्स अपडेट हैं, Gradle Daemon सक्षम है (org.gradle.daemon=true) और gradle.properties में पर्याप्त मेमोरी सेट है: org.gradle.jvmargs=-Xmx4096m।
कैशिंग समस्याएँ निर्भरताएँ अपडेट करने के बाद उत्पन्न होती हैं: Gradle पुराने कैश का उपयोग कर सकता है और बिल्ड विफल हो जाता है। समाधान — --refresh-dependencies फ्लैग के साथ बिल्ड चलाना या ./gradlew cleanBuildCache के माध्यम से मैन्युअल रूप से कैश साफ़ करना। तीसरी सबसे आम त्रुटि है Android Gradle Plugin (AGP) और Gradle के बीच संस्करण असंगति। प्रत्येक AGP संस्करण को एक विशिष्ट न्यूनतम Gradle संस्करण की आवश्यकता होती है। अनुकूलता तालिका developer.android.com पर प्रकाशित की जाती है। यदि संस्करण असंगत हैं, Gradle कॉन्फ़िगरेशन चरण में न्यूनतम आवश्यक संस्करण के बारे में संदेश के साथ विफल हो जाता है। हमेशा जाँचें कि Gradle wrapper संस्करण AGP आवश्यकताओं से मेल खाता है।
अक्सर पूछे जाने वाले प्रश्न
Gradle परियोजनाओं के निर्माण के लिए एक प्रोग्राम-ऑटोमेटर है। यह Kotlin या Java में आपके स्रोत कोड को लेता है, इंटरनेट से लाइब्रेरीज़ कनेक्ट करता है, सब कुछ बाइटकोड में संकलित करता है और APK में पैकेज करता है। यह JVM पर चलता है और मैन्युअल निर्देशों के बजाय घोषणात्मक स्क्रिप्ट का उपयोग करता है। डेवलपर को केवल नियमों का वर्णन करने की आवश्यकता है, और Gradle बाकी करता है।
Build.gradle Groovy में लिखा जाता है — एक गतिशील भाषा जिसमें लचीला सिंटैक्स और कम कठोरता होती है। Build.gradle.kts Kotlin DSL का उपयोग करता है: मजबूत टाइपिंग, Android Studio में ऑटोकम्पलीट और संकलन समय पर त्रुटि जाँच। Google सभी नए प्रोजेक्ट्स के लिए Kotlin DSL की अनुशंसा करता है। Groovy फ़ाइलों को माइग्रेट करना आसान है, लेकिन Kotlin फ़ाइलें रखरखाव में अधिक विश्वसनीय हैं।
Gradle Daemon (org.gradle.daemon=true) और समानांतर बिल्ड (org.gradle.parallel=true) सक्षम करें। org.gradle.jvmargs के माध्यम से JVM मेमोरी को 4–8 GB तक बढ़ाएँ। ऑन-डिमांड प्रोजेक्ट कॉन्फ़िगरेशन (org.gradle.configureondemand=true) का उपयोग करें। Android प्रोजेक्ट्स के लिए, कार्य कैशिंग कॉन्फ़िगर करें और केवल आवश्यक ABI के लिए बिल्ड करें। Android Studio में, बाधाओं को खोजने के लिए Build Analyzer चलाएँ।
Build variant बिल्ड प्रकार (जैसे, debug या release) और उत्पाद फ्लेवर (जैसे, demo या full) का संयोजन है। प्रत्येक वेरिएंट का अपना पैकेज नाम, संस्करण, संसाधन और स्रोत फ़ाइलें हो सकती हैं। Gradle स्वचालित रूप से प्रत्येक वेरिएंट के लिए एक अलग बिल्ड कार्य बनाता है। यह एक ही प्रोजेक्ट से एप्लिकेशन के कई संस्करण बनाने की अनुमति देता है।
निर्भरताएँ build.gradle.kts फ़ाइल के dependencies ब्लॉक में जोड़ी जाती हैं। प्रारूप है: configuration("group:artifact:version")। उदाहरण के लिए, implementation("androidx.core:core-ktx:1.12.0")। परीक्षणों के लिए testImplementation का उपयोग करें, इंस्ट्रुमेंटेड परीक्षणों के लिए — androidTestImplementation। संस्करणों को libs.versions.toml फ़ाइल के माध्यम से एक अलग संस्करण कैटलॉग में रखना सुविधाजनक है।
सारांश
हम एक मोबाइल एप्लिकेशन टर्नकी विकसित करेंगे
IT Sectr 2017 से स्टार्टअप और व्यवसायों के लिए iOS और Android एप्लिकेशन बनाता है। हम आपको सलाह देंगे और सर्वोत्तम समाधान प्रस्तावित करेंगे।
यह भी पढ़ें