Android का बिल्ड सिस्टम, ऐप्लिकेशन के रिसॉर्स के साथ-साथ सोर्स कोड और पैकेज को इकट्ठा करता है उन्हें APK या Android ऐप्लिकेशन बंडल में बदलकर टेस्ट कर सकते हैं, डिप्लॉय कर सकते हैं, साइन कर सकते हैं और डिस्ट्रिब्यूट करना.
Android Studio, अपने-आप काम करने के लिए, Gradle का इस्तेमाल करता है, जो कि एक बेहतर बिल्ड टूलकिट है. और आपको ज़रूरत के मुताबिक, अपनी पसंद के मुताबिक बनाने की सुविधा देते हुए बिल्ड प्रोसेस को मैनेज करने की सुविधा मिलती है बिल्ड कॉन्फ़िगरेशन. हर बिल्ड कॉन्फ़िगरेशन कोड का अपना सेट तय कर सकता है और संसाधनों को फिर से इस्तेमाल करें. 'Android Gradle प्लग इन', बिल्ड टूलकिट के साथ काम करता है, ताकि ऐसी प्रोसेस और कॉन्फ़िगर की जा सकने वाली सेटिंग जिन्हें खास तौर पर बनाया और टेस्ट किया जाता है Android ऐप्लिकेशन.
Gradle और 'Android Gradle प्लग इन', Android Studio से अलग काम करते हैं. यह इसका मतलब है कि आपको Android Studio में अपने Android ऐप्लिकेशन बनाने होंगे, या उन मशीनों पर जहां Android Studio नहीं है, कमांड लाइन सेट करें. इंस्टॉल किए गए हैं, जैसे कि लगातार इंटिग्रेशन सर्वर.
अगर आप इसका इस्तेमाल नहीं कर रहे हैं, तो Android Studio में जाकर, अपना ऐप्लिकेशन बनाने और उसे चलाने का तरीका जान सकते हैं. इसके लिए, कमांड लाइन लिखें. बिल्ड का आउटपुट एक जैसा ही रहता है, चाहे आप किसी भी स्थिति में हों कमांड लाइन से, रिमोट मशीन पर या किसी अन्य सिस्टम का इस्तेमाल करके प्रोजेक्ट बनाना Android Studio.
ध्यान दें: क्योंकि Gradle और 'Android Gradle प्लग इन' चलते हैं अगर आपको Android Studio स्वतंत्र रूप से काम करना है, तो आपको बिल्ड टूल अपडेट करना होगा. अलग करना होगा. Gredle को अपडेट करने का तरीका जानने के लिए, प्रॉडक्ट की जानकारी पढ़ें और 'Android Gradle प्लग इन' होना चाहिए.
Android बिल्ड सिस्टम की सुविधाओं की मदद से, अपनी पसंद के मुताबिक कॉन्फ़िगरेशन बनाने के लिए किया जा सकता है. यह इस पेज से, आपको यह समझने में मदद मिलती है कि Android का बिल्ड सिस्टम कैसे काम करता है और इससे आपको एक से ज़्यादा बिल्ड कॉन्फ़िगरेशन को अपने-आप ऑप्टिमाइज़ करने में मदद मिल सकती है. अगर आपको अगर आपको अपने ऐप्लिकेशन को डिप्लॉय करने के बारे में ज़्यादा जानना है, तो ऐप्लिकेशन बनाना और चलाना लेख पढ़ें. कस्टम बनाने के लिए कॉन्फ़िगरेशन तुरंत बनाएं Android Studio में जाकर, बिल्ड कॉन्फ़िगर करें वैरिएंट के बारे में ज़्यादा जानें.
बिल्ड प्रोसेस
बिल्ड प्रोसेस में ऐसे कई टूल और प्रोसेस शामिल होती हैं जो आपके प्रोजेक्ट को बदल देती हैं को Android ऐप्लिकेशन पैकेज (APK) या Android ऐप्लिकेशन बंडल (एएबी) में एक्सपोर्ट कर सकते हैं.
'Android Gradle प्लग इन' आपके लिए ज़्यादातर बिल्ड प्रोसेस को पूरा करता है, लेकिन यह बनाने की प्रोसेस के कुछ पहलुओं को समझने में मदद मिलती है. इससे आपको यह समझने में मदद मिलेगी कि आपकी ज़रूरतें पूरी करने के लिए तैयार करें.
अलग-अलग प्रोजेक्ट के बिल्ड लक्ष्य अलग-अलग हो सकते हैं. उदाहरण के लिए, तीसरे पक्ष की लाइब्रेरी, Android Archive (AAR) या Java संग्रह (JAR) बनाती है लाइब्रेरी. हालांकि, सबसे सामान्य तरह का प्रोजेक्ट ऐप्लिकेशन होता है और ऐप्लिकेशन का बिल्ड प्रोजेक्ट, आपके ऐप्लिकेशन का डीबग या रिलीज़ APK या एएबी बनाता है, जिसे डिप्लॉय किया जा सकता है, टेस्ट करें या बाहरी उपयोगकर्ताओं के लिए रिलीज़ करें.
यह पेज ऐप्लिकेशन डेवलपमेंट पर फ़ोकस करता है, लेकिन बिल्ड के कई तरीके और कॉन्सेप्ट, ज़्यादातर बिल्ड टाइप में आम हैं.
Android बिल्ड शब्दावली
Gradle और 'Android Gradle प्लग इन', नीचे दिए गए पहलुओं को कॉन्फ़िगर करने में आपकी मदद करते हैं बिल्ड का साइज़:
- बिल्ड के टाइप
-
बिल्ड टाइप ऐसी कुछ प्रॉपर्टी तय करता है जिनका इस्तेमाल Gradle, इमारत बनाते समय करता है और अपने ऐप्लिकेशन को पैकेजिंग के लिए तैयार करना. बिल्ड टाइप आम तौर पर, अलग-अलग आपके डेवलपमेंट के लाइफ़साइकल के अलग-अलग स्टेज होते हैं.
उदाहरण के लिए, डीबग बिल्ड टाइप डीबग विकल्पों को चालू करता है और ऐप्लिकेशन को डीबग कुंजी से साइन करता है, जबकि रिलीज़ का बिल्ड टाइप छोटा हो सकता है, उसे उलझा सकता है, और रिलीज़ के साथ आपके ऐप्लिकेशन पर साइन किया जा सकता है वितरण के लिए कुंजी.
आपको कम से कम एक बिल्ड टाइप तय करना होगा अपना ऐप्लिकेशन बनाना. Android Studio, डीबग और रिलीज़ बिल्ड टाइप बनाता है डिफ़ॉल्ट रूप से. अपने ऐप्लिकेशन के लिए पैकेजिंग की सेटिंग को पसंद के मुताबिक बनाना शुरू करने के लिए, इसका तरीका जानें बिल को कॉन्फ़िगर करने के लिए टाइप.
- प्रॉडक्ट के फ़्लेवर
- अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है प्रॉडक्ट के फ़्लेवर आपके ऐप्लिकेशन के अलग-अलग वर्शन दिखाते हैं, जिन्हें उपयोगकर्ताओं के लिए उपलब्ध कराया जाता है, जैसे कि मुफ़्त और पैसे चुकाकर खरीदे जाने वाले वर्शन. आप शेयर करते समय, अलग-अलग कोड और संसाधनों का इस्तेमाल करने के लिए, प्रॉडक्ट के फ़्लेवर को पसंद के मुताबिक बनाएं और उन हिस्सों का फिर से इस्तेमाल करना जो आपके ऐप्लिकेशन के सभी वर्शन में आम हैं. प्रॉडक्ट फ़्लेवर की वैल्यू देना ज़रूरी नहीं है और आपको उन्हें मैन्युअल तरीके से बनाना होगा. वीडियो बनाने के लिए आपके ऐप्लिकेशन के अलग-अलग वर्शन, दोनों को कॉन्फ़िगर करने का तरीका जानें प्रॉडक्ट के फ़्लेवर के बारे में ज़्यादा जानें.
- वैरिएंट बनाना
- अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है बिल्ड वैरिएंट, बिल्ड टाइप और प्रॉडक्ट फ़्लेवर का एक क्रॉस-प्रॉडक्ट होता है और वह कॉन्फ़िगरेशन है जिसका इस्तेमाल Gradle आपका ऐप्लिकेशन बनाने के लिए करता है. बिल्ड के वैरिएंट का इस्तेमाल करके, तो आपके पास डेवलपमेंट के दौरान अपने प्रॉडक्ट फ़्लेवर का डीबग वर्शन बनाने का विकल्प होता है और डिस्ट्रिब्यूशन के लिए, अपने प्रॉडक्ट के फ़्लेवर के साइन किए गए वर्शन वर्शन इस्तेमाल करें. बिल्ड वैरिएंट सीधे तौर पर कॉन्फ़िगर नहीं किए जाते, लेकिन आपने अलग-अलग तरह के और प्रॉडक्ट फ़्लेवर बनाने की सुविधा मिलती है. अतिरिक्त बिल्ड बनाया जा रहा है टाइप या प्रॉडक्ट के फ़्लेवर की मदद से, अन्य बिल्ड वैरिएंट भी बनाए जाते हैं. सीखने में बिल्ड के वैरिएंट बनाने और उन्हें मैनेज करने का तरीका जानने के लिए, बिल्ड वैरिएंट कॉन्फ़िगर करना लेख पढ़ें समीक्षा करें.
- मेनिफ़ेस्ट में जोड़ी गई एंट्री
- अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है बिल्ड में मेनिफ़ेस्ट फ़ाइल की कुछ प्रॉपर्टी के लिए वैल्यू तय की जा सकती है वैरिएंट कॉन्फ़िगरेशन. ये बिल्ड वैल्यू, मेनिफ़ेस्ट फ़ाइल में सेव किया जाएगा. अगर आपको एक से ज़्यादा वैरिएंट जनरेट करने हैं, तो यह तरीका मददगार होता है अपने ऐप्लिकेशन को किसी दूसरे नाम, SDK टूल के कम से कम वर्शन या टारगेट SDK टूल का वर्शन. एक से ज़्यादा मेनिफ़ेस्ट मौजूद होने पर, मर्जर टूल मेनिफ़ेस्ट सेटिंग को मर्ज करती है.
- डिपेंडेंसी
- अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है बिल्ड सिस्टम, आपके लोकल फ़ाइल सिस्टम से प्रोजेक्ट डिपेंडेंसी मैनेज करता है डेटा स्टोर करने की सुविधा देता है. इसका मतलब है कि आपको मैन्युअल तरीक़े से अपनी डिपेंडेंसी के बाइनरी पैकेज खोजें, डाउनलोड करें, और कॉपी करें प्रोजेक्ट डायरेक्ट्री में मौजूद डेटा. ज़्यादा जानकारी के लिए, बिल्ड जोड़ना वाला सेक्शन देखें डिपेंडेंसी.
- साइन इन करना
- अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है बिल्ड सिस्टम आपको बिल्ड में साइनिंग सेटिंग तय करने देता है कॉन्फ़िगरेशन और बिल्ड के दौरान यह आपके ऐप्लिकेशन को अपने-आप साइन कर सकता है प्रोसेस. बिल्ड सिस्टम, डीबग वर्शन को डिफ़ॉल्ट पासकोड से साइन करता है और बिल्ड पर पासवर्ड के प्रॉम्प्ट से बचने के लिए, जाने-पहचाने क्रेडेंशियल का इस्तेमाल करने वाला सर्टिफ़िकेट समय. बिल्ड सिस्टम तब तक रिलीज़ वर्शन पर हस्ताक्षर नहीं करता, जब तक आप इस बिल्ड के लिए साइनिंग कॉन्फ़िगरेशन को साफ़ तौर पर तय करें. अगर आपको अगर आपके पास रिलीज़ पासकोड है, तो अपने ऐप्लिकेशन पर हस्ताक्षर करें सेक्शन में बताए गए तरीके से इसे जनरेट किया जा सकता है. हस्ताक्षर की हुई रिलीज़ के बिल्ड ज़्यादातर ऐप स्टोर से ऐप्लिकेशन उपलब्ध कराने के लिए ज़रूरी है.
- कोड और संसाधन का दायरा कम करना
- अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है बिल्ड सिस्टम आपको इसके लिए एक अलग ProGuard नियमों वाली फ़ाइल तय करने देता है बिल्ड के हर वैरिएंट के लिए तैयार हो. आपका ऐप्लिकेशन बनाते समय, बिल्ड सिस्टम कम करने के लिए नियमों का सही सेट अपने कोड और संसाधन के लिए, पहले से मौजूद टूल, जैसे कि R8. अपने कोड और संसाधनों को छोटा करने से, APK या एएबी का साइज़ कम करने में मदद मिल सकती है.
- एक से ज़्यादा APK काम करते हैं
- अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है बिल्ड सिस्टम से आपको अपने-आप ऐसे अलग-अलग APKs बनाने की सुविधा मिलती है जो हर रिपोर्ट में, सिर्फ़ ज़रूरी कोड और संसाधन मौजूद होते हैं का इस्तेमाल किया जा सकता है. और जानकारी के लिए देखें कई APK बनाएं. हालांकि, एक एएबी रिलीज़ करना इसका इस्तेमाल करने का सुझाव दिया जाता है, क्योंकि इसमें अलग-अलग भाषाओं के साथ-साथ साथ ही, स्क्रीन की सघनता और एबीआई के साथ-साथ, कोई भी अपलोड करने की ज़रूरत नहीं पड़ती कई आर्टफ़ैक्ट को Google Play से जोड़ना है. अगस्त 2021 के बाद सबमिट किए गए सभी नए ऐप्लिकेशन एएबी का इस्तेमाल करना ज़रूरी है.
Android बिल्ड में Java वर्शन
चाहे आपका सोर्स कोड Java, Kotlin या दोनों में लिखा हो, ऐसी कई जगहें हैं जहां आपको JDK या Java भाषा चुननी होगी वर्शन बनाने की ज़रूरत नहीं है. Android बिल्ड में Java वर्शन देखें देखें.
बिल्ड कॉन्फ़िगरेशन फ़ाइलें
कस्टम बिल्ड कॉन्फ़िगरेशन बनाने के लिए, आपको इनमें से किसी एक में बदलाव करना होगा या और बिल्ड कॉन्फ़िगरेशन फ़ाइलें शामिल करें. ये सामान्य टेक्स्ट वाली फ़ाइलों में, जानकारी देने के लिए डोमेन स्पेसिफ़िक लैंग्वेज (DSL) का इस्तेमाल किया जाता है. इसका इस्तेमाल करके बिल्ड लॉजिक में बदलाव करें Kotlin स्क्रिप्ट, यह Kotlin लैंग्वेज की स्टाइल है. Google आपके यूआरएल पैरामीटर को कैसे इस्तेमाल करेगा, यह तय करने के लिए ग्रूवी, जो कि डाइनैमिक भाषा का इस्तेमाल करें.
अपने विज्ञापनों को कॉन्फ़िगर करना शुरू करने के लिए, आपको Kotlin स्क्रिप्ट या Groovy की ज़रूरत नहीं है बनाना आसान है, क्योंकि 'Android Gradle प्लग इन', ज़्यादातर DSL एलीमेंट . 'Android Gradle प्लग इन DSL' के बारे में ज़्यादा जानने के लिए, डीएसएल के लिए रेफ़रंस दस्तावेज़. Kotlin स्क्रिप्ट भी अंदरूनी Gradle Kotlin DSL.
नया प्रोजेक्ट शुरू करने पर, Android Studio अपने-आप इनमें से कुछ प्रोजेक्ट बना देता है आपके लिए इन फ़ाइलों को सेव कर देता है और सही डिफ़ॉल्ट सेटिंग के हिसाब से उन्हें भरता है. प्रोजेक्ट फ़ाइल का लेआउट इस तरह का है:
└── MyApp/ # Project ├── gradle/ │ └── wrapper/ │ └── gradle-wrapper.properties ├── build.gradle(.kts) ├── settings.gradle(.kts) └── app/ # Module │ ├── build.gradle(.kts) │ ├── build/ │ ├── libs/ │ └── src/ │ └── main/ # Source set │ ├── java/ │ │ └── com.example.myapp │ ├── res/ │ │ ├── drawable/ │ │ ├── values/ │ │ └── ... │ └── AndroidManifest.xml
ऐसी कुछ Gradle बिल्ड कॉन्फ़िगरेशन फ़ाइलें हैं जो 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
फ़ाइल (ग्रूवी डीएसएल के लिए) रूट में मौजूद है
प्रोजेक्ट डायरेक्ट्री में मौजूद डेटा. यह सेटिंग फ़ाइल, प्रोजेक्ट-लेवल रिपॉज़िटरी के बारे में बताती है
सेटिंग और 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. The code below * defines 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")
ग्रूवी
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. The code below * defines 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
फ़ाइल (ग्रूवी डीएसएल के लिए) रूट में मौजूद है
प्रोजेक्ट डायरेक्ट्री में मौजूद डेटा. यह आम तौर पर, इस्तेमाल किए जाने वाले प्लगिन के सामान्य वर्शन के बारे में बताता है
मॉड्यूल के हिसाब से तय करें.
नीचे दिया गया कोड सैंपल, इसमें डिफ़ॉल्ट सेटिंग और DSL एलिमेंट के बारे में बताता है नया प्रोजेक्ट बनाने के बाद टॉप लेवल बिल्ड स्क्रिप्ट:
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.5.0" apply false id("com.android.library") version "8.5.0" apply false id("org.jetbrains.kotlin.android") version "1.9.23" 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.5.0' apply false id 'com.android.library' version '8.5.0' apply false id 'org.jetbrains.kotlin.android' version '1.9.23' apply false }
मॉड्यूल-लेवल बिल्ड फ़ाइल
मॉड्यूल-लेवल build.gradle.kts
(Kotlin DSL के लिए) या
build.gradle
फ़ाइल (ग्रूवी डीएसएल के लिए) हर
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 के पुराने वर्शन पर इसके ज़रिए काम करते हैं desugaring, जो कि आपके बिल्ड में चालू रहे.
compileSdk
से जुड़ी समस्याएं होने पर, Android Studio चेतावनियां दिखाता है जिसमें Android Studio, AGP के मौजूदा वर्शन या आपके प्रोजेक्ट की लाइब्रेरी का इस्तेमाल किया गया हो डिपेंडेंसी से जुड़ी ज़रूरी शर्तें. -
minSdk
-
minSdk
, Android के उस सबसे पुराने वर्शन के बारे में बताता है जिसे आपने इंस्टॉल किया है चाहते हैं कि आपका ऐप्लिकेशन मदद करे.minSdk
को सेट करने पर, यह पाबंदी लगाई जा सकती है कि डिवाइस पर आपका ऐप्लिकेशन इंस्टॉल हो सकता है.Android के पुराने वर्शन के साथ काम करने के लिए, कुछ शर्तों के साथ ज़्यादा जांच की ज़रूरत पड़ सकती है या AndroidX कंपैटबिलिटी लाइब्रेरी का ज़्यादा इस्तेमाल करने में. आपको ऐसा करना चाहिए कम वर्शन वाले वर्शन के साथ काम करने की तुलना में, पुराने वर्शन का अब भी इस्तेमाल कर रहे उपयोगकर्ताओं का प्रतिशत. ज़्यादा जानकारी के लिए, Android Studio के नए प्रोजेक्ट विज़र्ड में वर्शन चार्ट प्रतिशत में दिखाया जा सकता है.
Android Studio में अपने कोड में बदलाव करते समय या प्रोसेस के दौरान जांच करते समय अगर आपका बिल्ड इस्तेमाल किया जा रहा है, तो लिंट उन एपीआई के बारे में चेतावनी देगा जो आपके लिए उपलब्ध नहीं हैं
minSdk
में. आपको इन समस्याओं को ठीक करना चाहिए नई सुविधाओं को शर्त के आधार पर तय करना या पुराने सिस्टम के साथ काम करने की सुविधा के लिएAppcompat
. -
targetSdk
-
targetSdk
दो मकसद के लिए है:- यह आपके ऐप्लिकेशन का रनटाइम व्यवहार सेट करता है.
- यह प्रमाणित करता है कि आपने Android के किस वर्शन का इस्तेमाल करके टेस्ट किया है.
अगर आपके डिवाइस पर Android का नया वर्शन है, तो आपका
targetSdk
. Android आपके ऐप्लिकेशन को कंपैटबिलिटी मोड में चलाता है जोtargetSdk
. उदाहरण के लिए, जब एपीआई 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
- एनडीके का पाथ. इस प्रॉपर्टी को बंद कर दिया गया है. एनडीके का डाउनलोड किया गया कोई भी वर्शन Android SDK डायरेक्ट्री में मौजूदndk
डायरेक्ट्री.sdk.dir
- Android SDK टूल का पाथ.cmake.dir
- CMake का पाथ.ndk.symlinkdir
- Android Studio 3.5 और इसके बाद के वर्शन में, उस एनडीके का सिमलिंक बनाता है जो इंस्टॉल किए गए वर्शन से छोटा हो सकता है NDK पाथ.
NDK को छोटे पाथ पर फिर से मैप करें (सिर्फ़ Windows के लिए)
Windows में, इंस्टॉल किए गए एनडीके फ़ोल्डर जैसे कि ld.exe
में मौजूद टूल,
लंबे पाथ शामिल करते हैं. यह टूल लंबे पाथ के साथ काम नहीं करता.
छोटा पाथ बनाने के लिए, local.properties
में प्रॉपर्टी सेट करें
यह अनुरोध करने के लिए ndk.symlinkdir
: 'Android Gradle प्लग इन', Google Tag Manager
एनडीके. उस सिमलिंक का पाथ, मौजूदा एनडीके फ़ोल्डर से छोटा हो सकता है.
उदाहरण के लिए, ndk.symlinkdir = C:\
से यह सिमलिंक मिलता है:
C:\ndk\19.0.5232133
प्रोजेक्ट को Gradle फ़ाइलों के साथ सिंक करना
अपने प्रोजेक्ट की बिल्ड कॉन्फ़िगरेशन फ़ाइलों में बदलाव करने पर, Android Studio के लिए ज़रूरी है कि आप अपनी प्रोजेक्ट फ़ाइलें सिंक करें, ताकि यह काम कर सके अपने बिल्ड कॉन्फ़िगरेशन से जुड़े बदलाव इंपोर्ट करें और कुछ जांच करके यह पक्का करें कि कॉन्फ़िगरेशन से बिल्ड से जुड़ी गड़बड़ियां नहीं होतीं.
अपनी प्रोजेक्ट फ़ाइलें सिंक करने के लिए, अभी सिंक करें पर क्लिक करें
बदलाव करने पर दिखने वाला सूचना बार, जैसा कि यहां दिखाया गया है
पहली इमेज या प्रोजेक्ट सिंक करें पर क्लिक करें
चुनें. अगर Android Studio को
कॉन्फ़िगरेशन — उदाहरण के लिए, आपका सोर्स कोड एपीआई की ऐसी सुविधाओं का इस्तेमाल करता है जो सिर्फ़
आपके
compileSdkVersion
से ज़्यादा के एपीआई लेवल में उपलब्ध है
— मैसेज विंडो में समस्या के बारे में बताया गया है.
![](https://developer.android.com/static/images/tools/as-gradlesync.png?authuser=19&hl=hi)
सोर्स सेट
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 में कोई नई फ़ाइल या डायरेक्ट्री बनाई जाती है स्टूडियो के लिए, फ़ाइल > मेन्यू के नए विकल्प एक खास सोर्स सेट के लिए भी ऐसा करना चाहिए. आप इन सोर्स सेट में से चुन सकते हैं अपडेट करता है, जो Android Studio अपने-आप आवश्यक डायरेक्ट्री, अगर वे पहले से मौजूद नहीं हैं.
अगर अलग-अलग सोर्स सेट में एक ही फ़ाइल के अलग-अलग वर्शन हैं, तो Gradle किस फ़ाइल का इस्तेमाल करना है, यह तय करते समय नीचे दिए गए प्राथमिकता क्रम का इस्तेमाल करता है. सोर्स सेट, बाईं ओर मौजूद सेट दाएं:
बिल्ड का वैरिएंट > बिल्ड टाइप > प्रॉडक्ट फ़्लेवर > मुख्य सोर्स सेट > लाइब्रेरी डिपेंडेंसी
इससे Gradle, आपके बिल्ड वैरिएंट से जुड़ी खास फ़ाइलें इस्तेमाल कर पाएगा जो ऐक्टिविटी, ऐप्लिकेशन लॉजिक और ऐसे संसाधन जो आपके ऐप्लिकेशन के दूसरे वर्शन के लिए आम हैं.
एक से ज़्यादा आइटम मर्ज करने पर मेनिफ़ेस्ट है, तो Gradle एक जैसे प्रायॉरिटी ऑर्डर का इस्तेमाल करता है, ताकि हर बिल्ड वैरिएंट फ़ाइनल मेनिफ़ेस्ट में अलग-अलग कॉम्पोनेंट या अनुमतियों को तय करता है. सीखने में कस्टम सोर्स सेट बनाने के बारे में ज़्यादा जानने के लिए, सोर्स सेट बनाना लेख पढ़ें.
वर्शन कैटलॉग
अगर आपके बिल्ड में सामान्य डिपेंडेंसी वाले कई मॉड्यूल हैं, या आपके पास समान डिपेंडेंसी वाले कई स्वतंत्र प्रोजेक्ट हैं, तो हमारा सुझाव है कि आप इसका इस्तेमाल करते हैं वर्शन कैटलॉग या बिल ऑफ़ मटीरियल (बीओएम) को सामान्य वर्शन तय करें.
अन्य बिल्ड सिस्टम
Baze की मदद से Android ऐप्लिकेशन बनाने का तरीका संभव है लेकिन आधिकारिक रूप से समर्थित नहीं है. Android Studio आधिकारिक रूप से बेज़ल प्रोजेक्ट के लिए सहायता उपलब्ध कराता है.
Basel के साथ इमारत बनाने की मौजूदा सीमाओं को बेहतर ढंग से समझने के लिए, देखें ऐसी समस्याएं जिनके बारे में पहले से जानकारी है.