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

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

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

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

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

बिल्ड टाइप

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

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

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

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

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

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

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

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

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

कोई नया प्रोजेक्ट शुरू करने पर, Android Studio इनमें से कुछ फ़ाइलें अपने-आप बना देता है. साथ ही, उन्हें सही डिफ़ॉल्ट वैल्यू के आधार पर भर देता है. बनाई गई फ़ाइलों की खास जानकारी के लिए, Android बिल्ड स्ट्रक्चर देखें.

Gradle रैपर फ़ाइल

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 की सेटिंग फ़ाइल

Kotlin DSL के लिए settings.gradle.kts फ़ाइल या Groovy 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. 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'

टॉप-लेवल की बिल्ड फ़ाइल

Kotlin DSL के लिए टॉप-लेवल build.gradle.kts फ़ाइल या Groovy 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 "9.4.0" apply false
    id("com.android.library") version "9.4.0" apply false
    id("org.jetbrains.kotlin.android") version "2.4.10" apply false
}

Groovy

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 '9.4.0' apply false
    id 'com.android.library' version '9.4.0' apply false
    id 'org.jetbrains.kotlin.android' version '2.4.10' apply false
}