अपना बिल्ड कॉन्फ़िगर करें

Android बिल्ड सिस्टम, ऐप्लिकेशन के संसाधनों और सोर्स कोड को संकलित करता है और उन्हें APK या Android ऐप्लिकेशन बंडल में पैकेज करता है. इनका इस्तेमाल, टेस्ट करने, डिप्लॉय करने, साइन करने, और डिस्ट्रिब्यूट करने के लिए किया जा सकता है.

Gradle बिल्ड की खास जानकारी और Android बिल्ड का स्ट्रक्चर में, हमने बिल्ड के कॉन्सेप्ट और Android ऐप्लिकेशन के स्ट्रक्चर के बारे में बात की थी. अब बिल्ड को कॉन्फ़िगर करने का समय आ गया है.

Android बिल्ड शब्दावली

Gradle और Android Gradle प्लग इन की मदद से, अपने बिल्ड के इन पहलुओं को कॉन्फ़िगर किया जा सकता है:

बिल्ड के टाइप

बिल्ड टाइप से कुछ खास प्रॉपर्टी तय होती हैं. Gradle, आपके ऐप्लिकेशन को बिल्ड और पैकेज करते समय इन प्रॉपर्टी का इस्तेमाल करता है. आम तौर पर, बिल्ड टाइप को डेवलपमेंट लाइफ़साइकल के अलग-अलग चरणों के लिए कॉन्फ़िगर किया जाता है.

उदाहरण के लिए, डीबग बिल्ड टाइप, डीबग करने के विकल्प चालू करता है और डीबग पासकोड से ऐप्लिकेशन पर हस्ताक्षर करता है. वहीं, रिलीज़ बिल्ड टाइप, डिस्ट्रिब्यूशन के लिए आपके ऐप्लिकेशन को छोटा कर सकता है, उसे गलत बना सकता है, और रिलीज़ पासकोड से उस पर हस्ताक्षर कर सकता है.

आपको अपना ऐप्लिकेशन बनाने के लिए, कम से कम एक बिल्ड टाइप तय करना होगा. Android Studio, डिबग और रिलीज़ बिल्ड टाइप को डिफ़ॉल्ट रूप से बनाता है. अपने ऐप्लिकेशन के लिए, पैकेजिंग की सेटिंग को पसंद के मुताबिक बनाने के लिए, बिल्ड टाइप को कॉन्फ़िगर करने का तरीका जानें.

प्रॉडक्ट के फ़्लेवर
प्रॉडक्ट फ़्लेवर, आपके ऐप्लिकेशन के उन अलग-अलग वर्शन के बारे में बताते हैं जिन्हें उपयोगकर्ताओं के लिए रिलीज़ किया जा सकता है. जैसे, मुफ़्त और पैसे चुकाकर डाउनलोड किए जाने वाले वर्शन. अपने ऐप्लिकेशन के सभी वर्शन के लिए उपलब्ध पार्ट शेयर और दोबारा इस्तेमाल करते समय, अलग-अलग कोड और संसाधनों का इस्तेमाल करने के लिए, प्रॉडक्ट के फ़्लेवर को पसंद के मुताबिक बनाया जा सकता है. प्रॉडक्ट के फ़्लेवर ज़रूरी नहीं हैं और आपको उन्हें मैन्युअल तरीके से बनाना होगा. अपने ऐप्लिकेशन के अलग-अलग वर्शन बनाने के लिए, प्रॉडक्ट के फ़्लेवर कॉन्फ़िगर करने का तरीका जानें.
वैरिएंट बनाना
बिल्ड वैरिएंट, बिल्ड टाइप और प्रॉडक्ट फ़्लेवर का क्रॉस-प्रॉडक्ट होता है. साथ ही, यह वह कॉन्फ़िगरेशन होता है जिसका इस्तेमाल Gradle आपके ऐप्लिकेशन को बनाने के लिए करता है. बिल्ड वैरिएंट का इस्तेमाल करके, डेवलपमेंट के दौरान अपने प्रॉडक्ट फ़्लेवर का डीबग वर्शन और डिस्ट्रिब्यूशन के लिए, अपने प्रॉडक्ट फ़्लेवर के साइन किए गए रिलीज़ वर्शन बनाए जा सकते हैं. हालांकि, सीधे तौर पर बिल्ड वैरिएंट को कॉन्फ़िगर नहीं किया जाता, लेकिन उनसे बने बिल्ड टाइप और प्रॉडक्ट फ़्लेवर को कॉन्फ़िगर किया जाता है. अतिरिक्त बिल्ड टाइप या प्रॉडक्ट फ़्लेवर बनाने पर, अतिरिक्त बिल्ड वैरिएंट भी बन जाते हैं. बाइल्ड वैरिएंट बनाने और मैनेज करने का तरीका जानने के लिए, बिल्ड वैरिएंट कॉन्फ़िगर करना के बारे में खास जानकारी वाला लेख पढ़ें.
मेनिफ़ेस्ट एंट्री
बिल्ड के वैरिएंट कॉन्फ़िगरेशन में, मेनिफ़ेस्ट फ़ाइल की कुछ प्रॉपर्टी के लिए वैल्यू तय की जा सकती है. ये बिल्ड वैल्यू, मेनिफ़ेस्ट फ़ाइल में मौजूदा वैल्यू को बदल देती हैं. अगर आपको अपने ऐप्लिकेशन के अलग-अलग नाम, कम से कम SDK वर्शन या टारगेट SDK वर्शन के साथ एक से ज़्यादा वैरिएंट जनरेट करने हैं, तो यह तरीका मददगार होता है. एक से ज़्यादा मेनिफ़ेस्ट मौजूद होने पर, मेनिफ़ेस्ट मर्जर टूल, मेनिफ़ेस्ट सेटिंग को मर्ज करता है.
डिपेंडेंसी
बिल्ड सिस्टम, आपके लोकल फ़ाइल सिस्टम और रिमोट रिपॉज़िटरी से प्रोजेक्ट की डिपेंडेंसी मैनेज करता है. इसका मतलब है कि आपको अपनी डिपेंडेंसी के बाइनरी पैकेज को मैन्युअल तरीके से खोजने, डाउनलोड करने, और प्रोजेक्ट डायरेक्ट्री में कॉपी करने की ज़रूरत नहीं है. ज़्यादा जानकारी के लिए, बिल्ड डिपेंडेंसी जोड़ना लेख पढ़ें.
साइन इन करना
बिल्ड सिस्टम की मदद से, बिल्ड कॉन्फ़िगरेशन में साइन करने की सेटिंग तय की जा सकती है. साथ ही, यह बिल्ड प्रोसेस के दौरान आपके ऐप्लिकेशन को अपने-आप साइन कर सकता है. बिल्ड सिस्टम, डीबग वर्शन को डिफ़ॉल्ट पासकोड और सर्टिफ़िकेट के साथ साइन करता है. इसके लिए, यह जाने-पहचाने क्रेडेंशियल का इस्तेमाल करता है, ताकि बिल्ड के समय पासवर्ड के अनुरोध से बचा जा सके. रिलीज़ वर्शन पर तब तक साइन नहीं किया जाता, जब तक कि आपने इस बिल्ड के लिए साइन करने का कॉन्फ़िगरेशन साफ़ तौर पर तय न कर दिया हो. अगर आपके पास कोई रिलीज़ पासकोड नहीं है, तो अपने ऐप्लिकेशन पर हस्ताक्षर करें सेक्शन में दिए गए तरीके से एक रिलीज़ पासकोड जनरेट किया जा सकता है. ज़्यादातर ऐप स्टोर पर ऐप्लिकेशन उपलब्ध कराने के लिए, साइन किए हुए रिलीज़ बिल्ड ज़रूरी होते हैं.
कोड और रिसॉर्स को छोटा करना
बिल्ड सिस्टम की मदद से, हर बिल्ड वैरिएंट के लिए ProGuard के नियमों की अलग-अलग फ़ाइल तय की जा सकती है. आपका ऐप्लिकेशन बनाते समय, बिल्ड सिस्टम अपने बिल्ट-इन टूल का इस्तेमाल करके, आपके कोड और संसाधनों को छोटा करने के लिए, नियमों का सही सेट लागू करता है. जैसे, R8. अपने कोड और संसाधनों को छोटा करके, APK या AAB का साइज़ कम किया जा सकता है.
एक से ज़्यादा APK के लिए सहायता
बिल्ड सिस्टम आपको अपने-आप अलग-अलग APK बनाने की सुविधा देता है. हर APK में सिर्फ़ वे कोड और संसाधन होते हैं जो खास स्क्रीन सघनता या ऐप्लिकेशन बाइनरी इंटरफ़ेस (एबीआई) के लिए ज़रूरी हैं. ज़्यादा जानकारी के लिए, एक से ज़्यादा APK बनाना लेख पढ़ें. हालांकि, एक ही AAB रिलीज़ करने का सुझाव दिया जाता है, क्योंकि इससे स्क्रीन डेंसिटी और एबीआई के साथ-साथ भाषा के हिसाब से भी ऐप्लिकेशन को अलग-अलग वर्शन में बांटा जा सकता है. साथ ही, Google Play पर कई आर्टिफ़ैक्ट अपलोड करने की ज़रूरत भी नहीं पड़ती. अगस्त 2021 के बाद सबमिट किए गए सभी नए ऐप्लिकेशन के लिए, AAB का इस्तेमाल करना ज़रूरी है.

Android बिल्ड में Java के वर्शन

भले ही, आपका सोर्स कोड Java, Kotlin या दोनों में लिखा गया हो, फिर भी आपको अपने बिल्ड के लिए JDK या Java भाषा का वर्शन चुनना होगा. ज़्यादा जानकारी के लिए, Android बिल्ड में Java के वर्शन देखें.

बिल्ड कॉन्फ़िगरेशन फ़ाइलें

कस्टम बिल्ड कॉन्फ़िगरेशन बनाने के लिए, आपको एक या एक से ज़्यादा बिल्ड कॉन्फ़िगरेशन फ़ाइलों में बदलाव करने होंगे. ये प्लैन-टेक्स्ट फ़ाइलें, डोमेन के हिसाब से बनी भाषा (डीएसएल) का इस्तेमाल करती हैं. इनका मकसद, Kotlin स्क्रिप्ट का इस्तेमाल करके, बिल्ड लॉजिक के बारे में बताना और उसमें बदलाव करना है. Kotlin स्क्रिप्ट, Kotlin भाषा का एक फ़्लेवर है. अपने बिल्ड कॉन्फ़िगर करने के लिए, Groovy का भी इस्तेमाल किया जा सकता है. यह Java Virtual Machine (JVM) भाषा के लिए एक डाइनैमिक भाषा है.

आपको अपनी बिल्ड को कॉन्फ़िगर करने के लिए, Kotlin स्क्रिप्ट या Groovy के बारे में जानने की ज़रूरत नहीं है. ऐसा इसलिए है, क्योंकि 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 को बताती है कि आपके ऐप्लिकेशन को बिल्ड करते समय किन मॉड्यूल को शामिल करना चाहिए. कई मॉड्यूल वाले प्रोजेक्ट के लिए, हर उस मॉड्यूल की जानकारी देनी ज़रूरी है जिसे फ़ाइनल बिल्ड में शामिल करना है.

ज़्यादातर प्रोजेक्ट के लिए, फ़ाइल डिफ़ॉल्ट रूप से इस तरह दिखती है:

KotlinGroovy
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")
 
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 फ़ाइल (ग्रूवी डीएसएल के लिए), रूट प्रोजेक्ट डायरेक्ट्री में मौजूद होती है. यह आम तौर पर, आपके प्रोजेक्ट में मॉड्यूल के ज़रिए इस्तेमाल किए जाने वाले प्लगिन के सामान्य वर्शन के बारे में बताता है.

यहां दिए गए कोड सैंपल में, नया प्रोजेक्ट बनाने के बाद, टॉप-लेवल वाली बिल्ड स्क्रिप्ट में मौजूद डिफ़ॉल्ट सेटिंग और डीएसएल एलिमेंट के बारे में बताया गया है:

KotlinGroovy
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.9.0" apply false
    id("com.android.library") version "8.9.0" apply false
    id("org.jetbrains.kotlin.android") version "2.1.10" 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.9.0' apply false
    id 'com.android.library' version '8.9.0' apply false
    id 'org.jetbrains.kotlin.android' version '2.1.10' apply false
}