Android बिल्ड सिस्टम, ऐप्लिकेशन के रिसॉर्स और सोर्स कोड और पैकेज को APKs या Android ऐप्लिकेशन बंडल में इकट्ठा करता है. इनकी जांच की जा सकती है, इन्हें डिप्लॉय किया जा सकता है, और साइन किया जा सकता है. साथ ही, इन्हें अन्य ऐप्लिकेशन में शेयर भी किया जा सकता है.
Gradle बिल्ड की खास जानकारी और Android बिल्ड स्ट्रक्चर में, हमने बिल्ड के सिद्धांतों और Android ऐप्लिकेशन के स्ट्रक्चर के बारे में चर्चा की. अब बिल्ड को कॉन्फ़िगर करने का समय आ गया है.
Android बिल्ड शब्दावली
Gradle और Android Gradle प्लग इन की मदद से, अपने बिल्ड के इन पहलुओं को कॉन्फ़िगर किया जा सकता है:
- बिल्ड के टाइप
-
बिल्ड टाइप से कुछ खास प्रॉपर्टी तय होती हैं. Gradle, आपके ऐप्लिकेशन को बिल्ड और पैकेज करते समय इन प्रॉपर्टी का इस्तेमाल करता है. आम तौर पर, बिल्ड टाइप को डेवलपमेंट लाइफ़साइकल के अलग-अलग चरणों के लिए कॉन्फ़िगर किया जाता है.
उदाहरण के लिए, डीबग बिल्ड टाइप, डीबग करने के विकल्प चालू करता है और डीबग पासकोड से ऐप्लिकेशन पर हस्ताक्षर करता है. वहीं, रिलीज़ बिल्ड टाइप, डिस्ट्रिब्यूशन के लिए आपके ऐप्लिकेशन को छोटा कर सकता है, उसे गलत बना सकता है, और रिलीज़ पासकोड से उस पर हस्ताक्षर कर सकता है.
अपना ऐप्लिकेशन बनाने के लिए, आपको कम से कम एक बिल्ड टाइप तय करना होगा. Android Studio, डिफ़ॉल्ट रूप से डीबग और रिलीज़ बिल्ड टाइप बनाता है. अपने ऐप्लिकेशन के लिए पैकेजिंग की सेटिंग को पसंद के मुताबिक बनाना शुरू करने के लिए, बिल्ड टाइप को कॉन्फ़िगर करने का तरीका जानें.
- प्रॉडक्ट के अलग-अलग स्वाद
- प्रॉडक्ट फ़्लेवर, आपके ऐप्लिकेशन के उन अलग-अलग वर्शन के बारे में बताते हैं जिन्हें उपयोगकर्ताओं के लिए रिलीज़ किया जा सकता है. जैसे, मुफ़्त और पैसे चुकाकर डाउनलोड किए जाने वाले वर्शन. अपने ऐप्लिकेशन के सभी वर्शन के लिए उपलब्ध पार्ट शेयर और दोबारा इस्तेमाल करते समय, अलग-अलग कोड और संसाधनों का इस्तेमाल करने के लिए, प्रॉडक्ट के फ़्लेवर को पसंद के मुताबिक बनाया जा सकता है. प्रॉडक्ट के फ़्लेवर ज़रूरी नहीं हैं और आपको उन्हें मैन्युअल तरीके से बनाना होगा. अपने ऐप्लिकेशन के अलग-अलग वर्शन बनाने के लिए, प्रॉडक्ट के फ़्लेवर कॉन्फ़िगर करने का तरीका जानें.
- वैरिएंट बनाना
- बिल्ड वैरिएंट, बिल्ड टाइप और प्रॉडक्ट फ़्लेवर का क्रॉस-प्रॉडक्ट होता है. साथ ही, यह वह कॉन्फ़िगरेशन होता है जिसका इस्तेमाल Gradle आपके ऐप्लिकेशन को बनाने के लिए करता है. बिल्ड वैरिएंट का इस्तेमाल करके, डेवलपमेंट के दौरान अपने प्रॉडक्ट फ़्लेवर का डीबग वर्शन और डिस्ट्रिब्यूशन के लिए, अपने प्रॉडक्ट फ़्लेवर के साइन किए गए रिलीज़ वर्शन बनाए जा सकते हैं. बिल्ड के वैरिएंट सीधे तौर पर कॉन्फ़िगर नहीं किए जाते हैं. हालांकि, उनमें इस्तेमाल किए जाने वाले बिल्ड टाइप और प्रॉडक्ट के फ़्लेवर कॉन्फ़िगर किए जा सकते हैं. अतिरिक्त बिल्ड टाइप या प्रॉडक्ट फ़्लेवर बनाने पर, अतिरिक्त बिल्ड वैरिएंट भी बन जाते हैं. बिल्ड वैरिएंट बनाने और मैनेज करने का तरीका जानने के लिए, बिल्ड वैरिएंट कॉन्फ़िगर करें से जुड़ी खास जानकारी पढ़ें.
- मेनिफ़ेस्ट एंट्री
- बिल्ड वैरिएंट कॉन्फ़िगरेशन में, मेनिफ़ेस्ट फ़ाइल की कुछ प्रॉपर्टी के लिए वैल्यू तय की जा सकती हैं. ये बिल्ड वैल्यू, मेनिफ़ेस्ट फ़ाइल में मौजूदा वैल्यू को बदल देती हैं. यह तब फ़ायदेमंद होता है, जब आपको अपने ऐप्लिकेशन के कई वैरिएंट जनरेट करने हों. इसके लिए, ऐप्लिकेशन का कोई दूसरा नाम, SDK टूल का कम से कम वर्शन या SDK टूल का टारगेट वर्शन इस्तेमाल किया जा सकता है. एक से ज़्यादा मेनिफ़ेस्ट मौजूद होने पर, मेनिफ़ेस्ट मर्जर टूल, मेनिफ़ेस्ट सेटिंग को मर्ज करता है.
- डिपेंडेंसी
- बिल्ड सिस्टम, आपके लोकल फ़ाइल सिस्टम और रिमोट रिपॉज़िटरी से प्रोजेक्ट की डिपेंडेंसी मैनेज करता है. इसका मतलब है कि आपको अपनी प्रोजेक्ट डायरेक्ट्री में, अपनी डिपेंडेंसी के बाइनरी पैकेज को मैन्युअल तरीके से खोजने, डाउनलोड करने, और कॉपी करने की ज़रूरत नहीं है. ज़्यादा जानकारी के लिए, बिल्ड डिपेंडेंसी जोड़ना लेख पढ़ें.
- साइन इन करना
- बिल्ड सिस्टम की मदद से, बिल्ड कॉन्फ़िगरेशन में साइन करने की सेटिंग तय की जा सकती है. साथ ही, यह बिल्ड प्रोसेस के दौरान आपके ऐप्लिकेशन को अपने-आप साइन कर सकता है. बिल्ड सिस्टम, डीबग वर्शन को डिफ़ॉल्ट पासकोड और सर्टिफ़िकेट के साथ साइन करता है. इसके लिए, यह जाने-पहचाने क्रेडेंशियल का इस्तेमाल करता है, ताकि बिल्ड के समय पासवर्ड के अनुरोध से बचा जा सके. रिलीज़ वर्शन पर तब तक साइन नहीं किया जाता, जब तक कि आपने इस बिल्ड के लिए साइन करने का कॉन्फ़िगरेशन साफ़ तौर पर तय न कर दिया हो. अगर आपके पास कोई रिलीज़ पासकोड नहीं है, तो अपने ऐप्लिकेशन पर हस्ताक्षर करें सेक्शन में दिए गए तरीके से एक रिलीज़ पासकोड जनरेट किया जा सकता है. ज़्यादातर ऐप स्टोर पर ऐप्लिकेशन उपलब्ध कराने के लिए, साइन किए हुए रिलीज़ बिल्ड ज़रूरी होते हैं.
- कोड और रिसॉर्स को छोटा करना
- बिल्ड सिस्टम की मदद से, हर बिल्ड वैरिएंट के लिए ProGuard के नियमों की अलग-अलग फ़ाइल तय की जा सकती है. आपका ऐप्लिकेशन बनाते समय, बिल्ड सिस्टम नियमों के सही सेट को लागू करता है, ताकि R8 जैसे पहले से मौजूद, छोटा करने वाले टूल का इस्तेमाल करके आपके कोड और संसाधनों को छोटा किया जा सके. अपने कोड और संसाधनों को छोटा करने से, APK या एएबी का साइज़ कम करने में मदद मिल सकती है.
- एक से ज़्यादा APK काम करते हैं
- बिल्ड सिस्टम की मदद से, अलग-अलग APK अपने-आप बन जाते हैं. इनमें से हर APK में, सिर्फ़ किसी खास स्क्रीन डेंसिटी या ऐप्लिकेशन बाइनरी इंटरफ़ेस (एबीआई) के लिए ज़रूरी कोड और संसाधन होते हैं. ज़्यादा जानकारी के लिए एक से ज़्यादा APK बनाना देखें. हालांकि, एक एएबी रिलीज़ करने का सुझाव दिया जाता है. ऐसा इसलिए, क्योंकि यह स्क्रीन की सघनता और एबीआई के साथ-साथ, भाषा के हिसाब से बांटने की सुविधा देता है. साथ ही, Google Play पर कई आर्टफ़ैक्ट अपलोड करने की ज़रूरत नहीं पड़ती. अगस्त 2021 के बाद सबमिट किए जाने वाले सभी नए ऐप्लिकेशन के लिए, एएबी का इस्तेमाल करना ज़रूरी है.
Android बिल्ड में Java के वर्शन
भले ही, आपका सोर्स कोड Java, Kotlin या दोनों में लिखा गया हो, फिर भी आपको अपने बिल्ड के लिए JDK या Java भाषा का वर्शन चुनना होगा. ज़्यादा जानकारी के लिए, Android बिल्ड में Java के वर्शन देखें.
कॉन्फ़िगरेशन फ़ाइलें बनाना
कस्टम बिल्ड कॉन्फ़िगरेशन बनाने के लिए, आपको एक या उससे ज़्यादा बिल्ड कॉन्फ़िगरेशन फ़ाइलों में बदलाव करने होंगे. ये प्लैन-टेक्स्ट फ़ाइलें, डोमेन के हिसाब से बनी भाषा (डीएसएल) का इस्तेमाल करती हैं. इनका मकसद, Kotlin स्क्रिप्ट का इस्तेमाल करके, बिल्ड लॉजिक के बारे में बताना और उसमें बदलाव करना है. Kotlin स्क्रिप्ट, Kotlin भाषा का एक फ़्लेवर है. अपने बिल्ड कॉन्फ़िगर करने के लिए, Groovy का भी इस्तेमाल किया जा सकता है. यह Java Virtual Machine (JVM) भाषा के लिए एक डाइनैमिक भाषा है.
अपने बिल्ड को कॉन्फ़िगर करना शुरू करने के लिए, आपको Kotlin स्क्रिप्ट या ग्रूवी के बारे में जानने की ज़रूरत नहीं है, क्योंकि 'Android Gradle प्लग इन' में आपकी ज़रूरत के ज़्यादातर डीएसएल एलिमेंट मौजूद होते हैं. 'Android Gradle प्लग इन DSL' के बारे में ज़्यादा जानने के लिए, DSL से जुड़े संदर्भ वाले दस्तावेज़ पढ़ें. Kotlin स्क्रिप्ट, इसमें बुनियादी Gradle Kotlin DSL का भी इस्तेमाल करती है
नया प्रोजेक्ट शुरू करते समय, Android Studio आपके लिए इनमें से कुछ फ़ाइलें अपने-आप बनाता है और उन्हें सही डिफ़ॉल्ट सेटिंग के हिसाब से अपने-आप भर देता है. बनाई गई फ़ाइलों की खास जानकारी के लिए, Android बिल्ड स्ट्रक्चर देखें.
Gradle Wrapper फ़ाइल
Gradle रैपर (gradlew
) एक छोटा ऐप्लिकेशन है, जो आपके सोर्स कोड में शामिल होता है. यह Gradle खुद डाउनलोड और लॉन्च करता है.
इससे, बिल्ड को एक्ज़ीक्यूट करने की प्रोसेस एक जैसी हो जाती है. डेवलपर, ऐप्लिकेशन के सोर्स
को डाउनलोड करते हैं और gradlew
को चलाते हैं. इससे, ज़रूरी Gradle डिस्ट्रिब्यूशन डाउनलोड हो जाता है और आपका ऐप्लिकेशन बनाने के लिए, Gradle लॉन्च हो जाता है.
gradle/wrapper/gradle-wrapper.properties
फ़ाइल में एक प्रॉपर्टी, distributionUrl
होती है. इससे पता चलता है कि आपके बिल्ड को चलाने के लिए, Gradle के किस वर्शन का इस्तेमाल किया जाता है.
distributionBase=GRADLE_USER_HOME
distributionPath=wrapper/dists
distributionUrl=https\://services.gradle.org/distributions/gradle-8.0-bin.zip
zipStoreBase=GRADLE_USER_HOME
zipStorePath=wrapper/dists
Gradle की सेटिंग फ़ाइल
settings.gradle.kts
फ़ाइल (Kotlin DSL के लिए) या
settings.gradle
फ़ाइल (Groovy DSL के लिए), प्रोजेक्ट की रूट डायरेक्ट्री में होती है. यह सेटिंग फ़ाइल, प्रोजेक्ट-लेवल की रिपॉज़िटरी सेटिंग तय करती है और Gradle को बताती है कि आपके ऐप्लिकेशन को बिल्ड करते समय किन मॉड्यूल को शामिल करना चाहिए. कई मॉड्यूल वाले प्रोजेक्ट के लिए, हर उस मॉड्यूल की जानकारी देनी ज़रूरी है जिसे फ़ाइनल बिल्ड में शामिल करना है.
ज़्यादातर प्रोजेक्ट के लिए, फ़ाइल डिफ़ॉल्ट रूप से इस तरह दिखती है:
Kotlin
pluginManagement { /** * The pluginManagement.repositories block configures the * repositories Gradle uses to search or download the Gradle plugins and * their transitive dependencies. Gradle pre-configures support for remote * repositories such as JCenter, Maven Central, and Ivy. You can also use * local repositories or define your own remote repositories. Here we * define the Gradle Plugin Portal, Google's Maven repository, * and the Maven Central Repository as the repositories Gradle should use to look for its * dependencies. */ repositories { gradlePluginPortal() google() mavenCentral() } } dependencyResolutionManagement { /** * The dependencyResolutionManagement.repositories * block is where you configure the repositories and dependencies used by * all modules in your project, such as libraries that you are using to * create your application. However, you should configure module-specific * dependencies in each module-level build.gradle file. For new projects, * Android Studio includes Google's Maven repository and the Maven Central * Repository by default, but it does not configure any dependencies (unless * you select a template that requires some). */ repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS) repositories { google() mavenCentral() } } rootProject.name = "My Application" include(":app")
Groovy
pluginManagement { /** * The pluginManagement.repositories block configures the * repositories Gradle uses to search or download the Gradle plugins and * their transitive dependencies. Gradle pre-configures support for remote * repositories such as JCenter, Maven Central, and Ivy. You can also use * local repositories or define your own remote repositories. Here we * define the Gradle Plugin Portal, Google's Maven repository, * and the Maven Central Repository as the repositories Gradle should use to look for its * dependencies. */ repositories { gradlePluginPortal() google() mavenCentral() } } dependencyResolutionManagement { /** * The dependencyResolutionManagement.repositories * block is where you configure the repositories and dependencies used by * all modules in your project, such as libraries that you are using to * create your application. However, you should configure module-specific * dependencies in each module-level build.gradle file. For new projects, * Android Studio includes Google's Maven repository and the Maven Central * Repository by default, but it does not configure any dependencies (unless * you select a template that requires some). */ repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS) repositories { google() mavenCentral() } } rootProject.name = "My Application" include ':app'
टॉप लेवल की बिल्ड फ़ाइल
टॉप-लेवल की build.gradle.kts
फ़ाइल (Kotlin DSL के लिए) या
build.gradle
फ़ाइल (ग्रूवी डीएसएल के लिए), रूट प्रोजेक्ट डायरेक्ट्री में मौजूद होती है. आम तौर पर, यह आपके प्रोजेक्ट में मॉड्यूल के इस्तेमाल किए जाने वाले प्लग इन के सामान्य वर्शन तय करता है.
यहां दिए गए कोड सैंपल में, नया प्रोजेक्ट बनाने के बाद, टॉप-लेवल वाली बिल्ड स्क्रिप्ट में मौजूद डिफ़ॉल्ट सेटिंग और डीएसएल एलिमेंट के बारे में बताया गया है:
Kotlin
plugins { /** * Use `apply false` in the top-level build.gradle file to add a Gradle * plugin as a build dependency but not apply it to the current (root) * project. Don't use `apply false` in sub-projects. For more information, * see Applying external plugins with same version to subprojects. */ id("com.android.application") version "8.7.0" apply false id("com.android.library") version "8.7.0" apply false id("org.jetbrains.kotlin.android") version "2.0.20" apply false }
ग्रूवी
plugins { /** * Use `apply false` in the top-level build.gradle file to add a Gradle * plugin as a build dependency but not apply it to the current (root) * project. Don't use `apply false` in sub-projects. For more information, * see Applying external plugins with same version to subprojects. */ id 'com.android.application' version '8.7.0' apply false id 'com.android.library' version '8.7.0' apply false id 'org.jetbrains.kotlin.android' version '2.0.20' apply false }
मॉड्यूल-लेवल बिल्ड फ़ाइल
Kotlin DSL के लिए मॉड्यूल-लेवल build.gradle.kts
या
build.gradle
फ़ाइल (Groovy DSL के लिए) हर
project/module/
डायरेक्ट्री में मौजूद होती है. इससे आपको उस मॉड्यूल के लिए बिल्ड सेटिंग कॉन्फ़िगर करने में मदद मिलेगी जिसमें यह मौजूद है. इन बिल्ड सेटिंग को कॉन्फ़िगर करने पर, आपको कस्टम पैकेजिंग के विकल्प मिलते हैं. जैसे, बिल्ड के अन्य टाइप और प्रॉडक्ट फ़्लेवर. साथ ही, main/
ऐप्लिकेशन मेनिफ़ेस्ट या टॉप-लेवल बिल्ड स्क्रिप्ट में सेटिंग को बदला जा सकता है.
Android SDK की सेटिंग
आपके ऐप्लिकेशन के लिए मॉड्यूल-लेवल की बिल्ड फ़ाइल में ऐसी सेटिंग शामिल होती हैं जिनसे पता चलता है कि कंपाइल करने, प्लैटफ़ॉर्म के व्यवहार को चुनने, और आपके ऐप्लिकेशन के लिए कम से कम वर्शन तय करने के दौरान, Android SDK टूल के किन वर्शन का इस्तेमाल किया गया है.
-
compileSdk
-
compileSdk
से यह तय होता है कि आपके सोर्स कोड को कंपाइल करते समय, कौनसे Android और Java एपीआई उपलब्ध हैं. Android की नई सुविधाओं का इस्तेमाल करने के लिए, संकलन करते समय Android SDK के सबसे नए वर्शन का इस्तेमाल करें.ऐसा हो सकता है कि Android प्लैटफ़ॉर्म के कुछ एपीआई, पुराने एपीआई लेवल में उपलब्ध न हों. आप कुछ शर्तों के साथ नई सुविधाओं के इस्तेमाल को सुरक्षित रख सकते हैं या AndroidX के साथ काम करने वाली लाइब्रेरी का इस्तेमाल करके, Android के एपीआई लेवल को कम करके नई सुविधाओं का इस्तेमाल कर सकते हैं.
हर Android SDK, आपके ऐप्लिकेशन में इस्तेमाल करने के लिए Java API का सबसेट उपलब्ध कराता है. अपने Java या Kotlin सोर्स कोड में कौनसे Java API इस्तेमाल किए जा सकते हैं के नीचे दी गई टेबल में, यह जानकारी मिलती है कि Android SDK टूल के वर्शन के आधार पर, कौनसा Java API लेवल उपलब्ध है. नए Java API, Android के पुराने वर्शन पर काम करते हैं. इसके लिए, डिसगैरिंग की सुविधा का इस्तेमाल किया जाता है. यह सुविधा आपके बिल्ड में चालू होनी चाहिए.
अगर आपका
compileSdk
, Android Studio, AGP के मौजूदा वर्शन या आपके प्रोजेक्ट की लाइब्रेरी डिपेंडेंसी की ज़रूरी शर्तों के साथ संघर्ष करता है, तो Android Studio चेतावनियां दिखाता है. -
minSdk
-
minSdk
से यह पता चलता है कि आपका ऐप्लिकेशन, Android के किस सबसे कम वर्शन पर काम करता है.minSdk
सेटिंग से यह तय किया जा सकता है कि आपका ऐप्लिकेशन किन डिवाइसों पर इंस्टॉल किया जा सकता है.Android के पुराने वर्शन के साथ काम करने के लिए, आपको अपने कोड में और शर्तों के साथ जांच करनी पड़ सकती है. इसके अलावा, AndroidX के साथ काम करने वाली लाइब्रेरी का ज़्यादा इस्तेमाल करना पड़ सकता है. आपको पुराने वर्शन के लिए बने रखरखाव के खर्च को, उन वर्शन का इस्तेमाल करने वाले उपयोगकर्ताओं के प्रतिशत से तुलना करनी चाहिए. मौजूदा वर्शन के इस्तेमाल के प्रतिशत के लिए, Android Studio के नए प्रोजेक्ट विज़र्ड में वर्शन चार्ट देखें.
Android Studio में कोड में बदलाव करते समय या बिल्ड के दौरान जांच करते समय, lint आपके इस्तेमाल किए जाने वाले उन एपीआई के बारे में चेतावनी देगा जो
minSdk
में उपलब्ध नहीं हैं. आपको इन गड़बड़ियों को ठीक करना चाहिए. इसके लिए, नई सुविधाओं को शर्तों के हिसाब से बनाएं या पुराने सिस्टम के साथ काम करने की सुविधा के लिए,Appcompat
का इस्तेमाल करें. -
targetSdk
-
targetSdk
दो मकसद के लिए है:- यह आपके ऐप्लिकेशन का रनटाइम व्यवहार सेट करता है.
- इससे यह पता चलता है कि आपने Android के किस वर्शन पर टेस्ट किया है.
अगर आपका ऐप्लिकेशन किसी ऐसे डिवाइस पर चलता है जो आपके
targetSdk
के मुकाबले, Android के नए वर्शन का इस्तेमाल करता है, तो Android आपके ऐप्लिकेशन को काम करने के लिए, उस वर्शन के हिसाब से काम करने वाले मोड में चलाता है जो आपकेtargetSdk
में बताया गया है. उदाहरण के लिए, जब API 23 में रनटाइम अनुमतियों का मॉडल पेश किया गया, तो सभी ऐप्लिकेशन इसे तुरंत अपनाने के लिए तैयार नहीं थे.targetSdk
को 22 पर सेट करने पर, ये ऐप्लिकेशन एपीआई 23 डिवाइसों पर, रनटाइम की अनुमतियों का इस्तेमाल किए बिना चल सकते हैं. साथ ही, ये ऐप्लिकेशनcompileSdk
के नए वर्शन में शामिल सुविधाओं का इस्तेमाल कर सकते हैं. Google Play के डिस्ट्रिब्यूशन की नीति, टारगेट एपीआई लेवल पर अन्य नीतियां लागू करती है.targetSdk
की वैल्यू,compileSdk
की वैल्यू से कम या इसके बराबर होनी चाहिए.
ध्यान दें: compileSdk
और targetSdk
की वैल्यू
एक जैसी नहीं होनी चाहिए. इन बुनियादी सिद्धांतों को ध्यान में रखें:
compileSdk
से आपको नए एपीआई का ऐक्सेस मिलता हैtargetSdk
आपके ऐप्लिकेशन के रनटाइम व्यवहार को सेट करता हैtargetSdk
,compileSdk
से कम या उसके बराबर होना चाहिए
ऐप्लिकेशन-मॉड्यूल बिल्ड स्क्रिप्ट का सैंपल
Android ऐप्लिकेशन मॉड्यूल की इस सैंपल बिल्ड स्क्रिप्ट में, डीएसएल के कुछ बुनियादी एलिमेंट और सेटिंग के बारे में बताया गया है:
Kotlin
/** * The first section in the build configuration applies the Android Gradle plugin * to this build and makes the android block available to specify * Android-specific build options. */ plugins { id("com.android.application") } /** * Locate (and possibly download) a JDK used to build your kotlin * source code. This also acts as a default for sourceCompatibility, * targetCompatibility and jvmTarget. Note that this does not affect which JDK * is used to run the Gradle build itself, and does not need to take into * account the JDK version required by Gradle plugins (such as the * Android Gradle Plugin) */ kotlin { jvmToolchain(11) } /** * The android block is where you configure all your Android-specific * build options. */ android { /** * The app's namespace. Used primarily to access app resources. */ namespace = "com.example.myapp" /** * compileSdk specifies the Android API level Gradle should use to * compile your app. This means your app can use the API features included in * this API level and lower. */ compileSdk = 33 /** * The defaultConfig block encapsulates default settings and entries for all * build variants and can override some attributes in main/AndroidManifest.xml * dynamically from the build system. You can configure product flavors to override * these values for different versions of your app. */ defaultConfig { // Uniquely identifies the package for publishing. applicationId = "com.example.myapp" // Defines the minimum API level required to run the app. minSdk = 21 // Specifies the API level used to test the app. targetSdk = 33 // Defines the version number of your app. versionCode = 1 // Defines a user-friendly version name for your app. versionName = "1.0" } /** * The buildTypes block is where you can configure multiple build types. * By default, the build system defines two build types: debug and release. The * debug build type is not explicitly shown in the default build configuration, * but it includes debugging tools and is signed with the debug key. The release * build type applies ProGuard settings and is not signed by default. */ buildTypes { /** * By default, Android Studio configures the release build type to enable code * shrinking, using minifyEnabled, and specifies the default ProGuard rules file. */ getByName("release") { isMinifyEnabled = true // Enables code shrinking for the release build type. proguardFiles( getDefaultProguardFile("proguard-android.txt"), "proguard-rules.pro" ) } } /** * The productFlavors block is where you can configure multiple product flavors. * This lets you create different versions of your app that can * override the defaultConfig block with their own settings. Product flavors * are optional, and the build system does not create them by default. * * This example creates a free and paid product flavor. Each product flavor * then specifies its own application ID, so that they can exist on the Google * Play Store or an Android device simultaneously. * * If you declare product flavors, you must also declare flavor dimensions * and assign each flavor to a flavor dimension. */ flavorDimensions += "tier" productFlavors { create("free") { dimension = "tier" applicationId = "com.example.myapp.free" } create("paid") { dimension = "tier" applicationId = "com.example.myapp.paid" } } /** * To override source and target compatibility (if different from the * toolchain JDK version), add the following. All of these * default to the same value as kotlin.jvmToolchain. If you're using the * same version for these values and kotlin.jvmToolchain, you can * remove these blocks. */ //compileOptions { // sourceCompatibility = JavaVersion.VERSION_11 // targetCompatibility = JavaVersion.VERSION_11 //} //kotlinOptions { // jvmTarget = "11" //} } /** * The dependencies block in the module-level build configuration file * specifies dependencies required to build only the module itself. * To learn more, go to Add build dependencies. */ dependencies { implementation(project(":lib")) implementation("androidx.appcompat:appcompat:1.7.0") implementation(fileTree(mapOf("dir" to "libs", "include" to listOf("*.jar")))) }
ग्रूवी
/** * The first line in the build configuration applies the Android Gradle plugin * to this build and makes the android block available to specify * Android-specific build options. */ plugins { id 'com.android.application' } /** * Locate (and possibly download) a JDK used to build your kotlin * source code. This also acts as a default for sourceCompatibility, * targetCompatibility and jvmTarget. Note that this does not affect which JDK * is used to run the Gradle build itself, and does not need to take into * account the JDK version required by Gradle plugins (such as the * Android Gradle Plugin) */ kotlin { jvmToolchain 11 } /** * The android block is where you configure all your Android-specific * build options. */ android { /** * The app's namespace. Used primarily to access app resources. */ namespace 'com.example.myapp' /** * compileSdk specifies the Android API level Gradle should use to * compile your app. This means your app can use the API features included in * this API level and lower. */ compileSdk 33 /** * The defaultConfig block encapsulates default settings and entries for all * build variants and can override some attributes in main/AndroidManifest.xml * dynamically from the build system. You can configure product flavors to override * these values for different versions of your app. */ defaultConfig { // Uniquely identifies the package for publishing. applicationId 'com.example.myapp' // Defines the minimum API level required to run the app. minSdk 21 // Specifies the API level used to test the app. targetSdk 33 // Defines the version number of your app. versionCode 1 // Defines a user-friendly version name for your app. versionName "1.0" } /** * The buildTypes block is where you can configure multiple build types. * By default, the build system defines two build types: debug and release. The * debug build type is not explicitly shown in the default build configuration, * but it includes debugging tools and is signed with the debug key. The release * build type applies ProGuard settings and is not signed by default. */ buildTypes { /** * By default, Android Studio configures the release build type to enable code * shrinking, using minifyEnabled, and specifies the default ProGuard rules file. */ release { minifyEnabled true // Enables code shrinking for the release build type. proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro' } } /** * The productFlavors block is where you can configure multiple product flavors. * This lets you create different versions of your app that can * override the defaultConfig block with their own settings. Product flavors * are optional, and the build system does not create them by default. * * This example creates a free and paid product flavor. Each product flavor * then specifies its own application ID, so that they can exist on the Google * Play Store or an Android device simultaneously. * * If you declare product flavors, you must also declare flavor dimensions * and assign each flavor to a flavor dimension. */ flavorDimensions "tier" productFlavors { free { dimension "tier" applicationId 'com.example.myapp.free' } paid { dimension "tier" applicationId 'com.example.myapp.paid' } } /** * To override source and target compatibility (if different from the * tool chain JDK version), add the following. All of these * default to the same value as kotlin.jvmToolchain. If you're using the * same version for these values and kotlin.jvmToolchain, you can * remove these blocks. */ //compileOptions { // sourceCompatibility JavaVersion.VERSION_11 // targetCompatibility JavaVersion.VERSION_11 //} //kotlinOptions { // jvmTarget = '11' //} } /** * The dependencies block in the module-level build configuration file * specifies dependencies required to build only the module itself. * To learn more, go to Add build dependencies. */ dependencies { implementation project(":lib") implementation 'androidx.appcompat:appcompat:1.7.0' implementation fileTree(dir: 'libs', include: ['*.jar']) }
Gradle प्रॉपर्टी की फ़ाइलें
Gradle में दो प्रॉपर्टी फ़ाइलें भी शामिल होती हैं. ये आपके रूट प्रोजेक्ट डायरेक्ट्री में होती हैं. इनका इस्तेमाल, Gradle बिल्ड टूलकिट की सेटिंग तय करने के लिए किया जा सकता है:
-
gradle.properties
- यहां से पूरे प्रोजेक्ट के लिए Gradle सेटिंग कॉन्फ़िगर की जा सकती है. जैसे, Gradle डीमन का ज़्यादा से ज़्यादा हीप साइज़. ज़्यादा जानकारी के लिए, एनवायरमेंट बनाएं लेख पढ़ें.
-
local.properties
-
बिल्ड सिस्टम के लिए लोकल एनवायरमेंट की प्रॉपर्टी कॉन्फ़िगर करता है. इनमें
ये प्रॉपर्टी भी शामिल हैं:
ndk.dir
- NDK का पाथ. यह प्रॉपर्टी अब काम नहीं करती. NDK के डाउनलोड किए गए वर्शन, Android SDK डायरेक्ट्री में मौजूदndk
डायरेक्ट्री में इंस्टॉल किए जाते हैं.sdk.dir
- Android SDK टूल का पाथ.cmake.dir
- CMake का पाथ.ndk.symlinkdir
- Android Studio 3.5 और इसके बाद के वर्शन में, NDK के लिए एक लिंक बनाया जाता है. यह लिंक, इंस्टॉल किए गए NDK पाथ से छोटा हो सकता है.
NDK को छोटे पाथ पर फिर से मैप करना (सिर्फ़ Windows के लिए)
Windows में, इंस्टॉल किए गए एनडीके फ़ोल्डर, जैसे कि ld.exe
में मौजूद टूल लंबे पाथ के साथ काम करते हैं. ये टूल, लंबे पाथ के साथ ठीक से काम नहीं करते.
छोटा पाथ बनाने के लिए, local.properties
में प्रॉपर्टी ndk.symlinkdir
सेट करें. इससे, Android Gradle प्लग इन, NDK के लिए एक सिमलिंक बनाएगा. उस सिमलिंक का पाथ, मौजूदा NDK फ़ोल्डर से छोटा हो सकता है.
उदाहरण के लिए, ndk.symlinkdir = C:\
से यह सिमलिंक बनता है:
C:\ndk\19.0.5232133
प्रोजेक्ट को Gradle फ़ाइलों के साथ सिंक करना
अपने प्रोजेक्ट की बिल्ड कॉन्फ़िगरेशन फ़ाइलों में बदलाव करने पर, Android Studio के लिए यह ज़रूरी है कि आप अपनी प्रोजेक्ट फ़ाइलें सिंक करें. इससे, आपके बिल्ड कॉन्फ़िगरेशन में किए गए बदलावों को इंपोर्ट किया जा सकेगा. साथ ही, कुछ जांच करके यह पक्का किया जा सकेगा कि आपके कॉन्फ़िगरेशन से, बिल्ड से जुड़ी गड़बड़ियां न हों.
प्रोजेक्ट की फ़ाइलों को सिंक करने के लिए, बदलाव करने पर दिखने वाले सूचना बार में, अभी सिंक करें पर क्लिक करें, जैसा कि दूसरे चित्र में दिखाया गया है. इसके अलावा, मेन्यू बार में जाकर, प्रोजेक्ट सिंक करें पर भी क्लिक किया जा सकता है. अगर Android Studio को आपके कॉन्फ़िगरेशन में कोई गड़बड़ी मिलती है, तो मैसेज विंडो में समस्या के बारे में बताया जाता है. उदाहरण के लिए, आपका सोर्स कोड, एपीआई की उन सुविधाओं का इस्तेमाल करता है जो सिर्फ़ compileSdkVersion
के बाद के एपीआई लेवल पर उपलब्ध हैं.
सोर्स सेट
Android Studio, हर मॉड्यूल के सोर्स कोड और रिसॉर्स को
सोर्स सेट में ग्रुप करता है. कोई नया मॉड्यूल बनाने पर, Android Studio
मॉड्यूल में main/
सोर्स सेट बना देता है. मॉड्यूल के main/
सोर्स सेट में ऐसे कोड और संसाधन शामिल होते हैं जिनका इस्तेमाल इसके सभी बिल्ड वैरिएंट के लिए किया जाता है.
अतिरिक्त सोर्स सेट डायरेक्ट्री ज़रूरी नहीं हैं. साथ ही, नए बिल्ड वैरिएंट कॉन्फ़िगर करने पर, Android Studio उन्हें आपके लिए अपने-आप नहीं बनाता. हालांकि, main/
की तरह ही सोर्स सेट बनाने से, उन फ़ाइलों और संसाधनों को
व्यवस्थित करने में मदद मिलती है जिनका इस्तेमाल Gradle को आपके ऐप्लिकेशन के कुछ खास वर्शन बनाने के दौरान ही करना चाहिए:
-
src/main/
- इस सोर्स सेट में ऐसे कोड और संसाधन शामिल हैं जो बिल्ड के सभी वैरिएंट के लिए सामान्य हैं.
-
src/buildType/
- इस सोर्स को इस तरह से सेट करें कि उसमें सिर्फ़ खास बिल्ड टाइप के लिए, कोड और संसाधन शामिल किए जा सकें.
-
src/productFlavor/
-
इस सोर्स को इस तरह से सेट करें कि उसमें सिर्फ़ किसी खास प्रॉडक्ट के फ़्लेवर के लिए कोड और संसाधन
शामिल किए जा सकें.
ध्यान दें: अगर आपने अपने बिल्ड को एक से ज़्यादा प्रॉडक्ट फ़्लेवर को जोड़ने के लिए कॉन्फ़िगर किया है, तो फ़्लेवर डाइमेंशन के बीच, प्रॉडक्ट फ़्लेवर के हर कॉम्बिनेशन के लिए सोर्स सेट डायरेक्ट्री बनाई जा सकती हैं:
src/productFlavor1ProductFlavor2/
. -
src/productFlavorBuildType/
- सिर्फ़ किसी खास बिल्ड वैरिएंट के लिए कोड और संसाधन शामिल करने के लिए, यह सोर्स सेट बनाएं.
उदाहरण के लिए, आपके ऐप्लिकेशन का "fullDebug" वर्शन जनरेट करने के लिए, बिल्ड सिस्टम इन सोर्स सेट से कोड, सेटिंग, और रिसॉर्स को मर्ज करता है:
-
src/fullDebug/
(बिल्ड वैरिएंट का सोर्स सेट) -
src/debug/
(बिल्ड टाइप सोर्स सेट) -
src/full/
(प्रॉडक्ट फ़्लेवर का सोर्स सेट) -
src/main/
(मुख्य सोर्स सेट)
ध्यान दें: Android Studio में नई फ़ाइल या डायरेक्ट्री बनाते समय, किसी खास सोर्स सेट के लिए इसे बनाने के लिए, फ़ाइल > नई मेन्यू के विकल्पों का इस्तेमाल करें. आपके पास जिन सोर्स सेट में से चुनने का विकल्प होता है वे आपके बिल्ड कॉन्फ़िगरेशन पर आधारित होते हैं. साथ ही, अगर ज़रूरी डायरेक्ट्री पहले से मौजूद नहीं हैं, तो Android Studio अपने-आप उन्हें बना देता है.
अगर अलग-अलग सोर्स सेट में एक ही फ़ाइल के अलग-अलग वर्शन हैं, तो यह तय करते समय कि किस फ़ाइल का इस्तेमाल करना है, Gradle, प्राथमिकता के इस क्रम का इस्तेमाल करता है. बाईं ओर मौजूद सोर्स सेट, दाईं ओर मौजूद सोर्स सेट की फ़ाइलों और सेटिंग को बदल देते हैं:
बिल्ड वैरिएंट > बिल्ड टाइप > प्रॉडक्ट फ़्लेवर > मुख्य सोर्स सेट > लाइब्रेरी डिपेंडेंसी
इससे Gradle, उन फ़ाइलों का इस्तेमाल कर सकता है जो आपके ऐप्लिकेशन के अन्य वर्शन में मौजूद गतिविधियों, ऐप्लिकेशन लॉजिक, और संसाधनों का फिर से इस्तेमाल करते समय, आपके बिल्ड वैरिएंट के लिए खास तौर पर बनाई गई हैं.
एक से ज़्यादा मेनिफ़ेस्ट को मर्ज करते समय, Gradle उसी प्राथमिकता क्रम का इस्तेमाल करता है, ताकि हर बिल्ड वैरिएंट, फ़ाइनल मेनिफ़ेस्ट में अलग-अलग कॉम्पोनेंट या अनुमतियां तय कर सके. कस्टम सोर्स सेट बनाने के बारे में ज़्यादा जानने के लिए, सोर्स सेट बनाना लेख पढ़ें.
वर्शन कैटलॉग
अगर आपके बिल्ड में एक जैसी डिपेंडेंसी वाले कई मॉड्यूल हैं या आपके पास एक जैसी डिपेंडेंसी वाले कई अलग-अलग प्रोजेक्ट हैं, तो हमारा सुझाव है कि आप एक जैसे वर्शन की जानकारी देने के लिए, वर्शन कैटलॉग या बिल ऑफ़ मटीरियल (बीओएम) का इस्तेमाल करें.
अन्य बिल्ड सिस्टम
Bazel की मदद से Android ऐप्लिकेशन बनाए जा सकते हैं, लेकिन आधिकारिक तौर पर यह सुविधा उपलब्ध नहीं है. Android Studio में, आधिकारिक तौर पर Bazel प्रोजेक्ट काम नहीं करते.
Bazel की मदद से बिल्ड करने की मौजूदा सीमाओं को बेहतर तरीके से समझने के लिए, पहले से मौजूद समस्याएं देखें.