बिल्ड के वैरिएंट कॉन्फ़िगर करें

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

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

बिल्ड वैरिएंट, Gradle के ज़रिए बनाए जाते हैं. इसके लिए, Gradle नियमों के किसी खास सेट का इस्तेमाल करता है. इन नियमों के तहत, बिल्ड टाइप और प्रॉडक्ट फ़्लेवर में कॉन्फ़िगर की गई सेटिंग, कोड, और संसाधनों को एक साथ जोड़ा जाता है. बिल्ड वैरिएंट को सीधे तौर पर कॉन्फ़िगर नहीं किया जाता. हालांकि, बिल्ड टाइप और प्रॉडक्ट फ़्लेवर को कॉन्फ़िगर किया जाता है. ये दोनों मिलकर बिल्ड वैरिएंट बनाते हैं.

उदाहरण के लिए, "डेमो" प्रॉडक्ट फ़्लेवर में कुछ सुविधाओं और डिवाइस से जुड़ी ज़रूरी शर्तों के बारे में बताया जा सकता है. जैसे, कस्टम सोर्स कोड, संसाधन, और एपीआई के कम से कम लेवल. वहीं, "डीबग" बिल्ड टाइप में बिल्ड और पैकेजिंग से जुड़ी अलग-अलग सेटिंग लागू होती हैं. जैसे, डीबग करने के विकल्प और हस्ताक्षर करने के लिए इस्तेमाल होने वाली कुंजियां. इन दोनों को मिलाकर बनाया गया बिल्ड वैरिएंट, आपके ऐप्लिकेशन का "demoDebug" वर्शन है. इसमें "demo" प्रॉडक्ट फ़्लेवर, "debug" बिल्ड टाइप, और main/ सोर्स सेट में शामिल कॉन्फ़िगरेशन और संसाधनों का कॉम्बिनेशन शामिल है.

बिल्ड टाइप कॉन्फ़िगर करना

मॉड्यूल-लेवल की build.gradle.kts फ़ाइल के android ब्लॉक में, बिल्ड टाइप बनाए और कॉन्फ़िगर किए जा सकते हैं. नया मॉड्यूल बनाने पर, Android Studio अपने-आप डीबग और रिलीज़ बिल्ड टाइप बना देता है. हालांकि, डिबग बिल्ड टाइप, बिल्ड कॉन्फ़िगरेशन फ़ाइल में नहीं दिखता है, लेकिन Android Studio इसे debuggable true के साथ कॉन्फ़िगर करता है. इससे आपको सुरक्षित Android डिवाइसों पर ऐप्लिकेशन को डीबग करने की सुविधा मिलती है. साथ ही, यह सामान्य डीबग कीस्टोर के साथ ऐप्लिकेशन साइनिंग को कॉन्फ़िगर करता है.

अगर आपको कुछ सेटिंग जोड़नी हैं या उनमें बदलाव करना है, तो अपने कॉन्फ़िगरेशन में डीबग बिल्ड टाइप जोड़ा जा सकता है. इस सैंपल में, डीबग बिल्ड टाइप के लिए applicationIdSuffix के बारे में बताया गया है. साथ ही, "स्टेजिंग" बिल्ड टाइप को कॉन्फ़िगर किया गया है. इसे डीबग बिल्ड टाइप की सेटिंग का इस्तेमाल करके शुरू किया जाता है:

Kotlin

android {
    defaultConfig {
        manifestPlaceholders["hostName"] = "www.example.com"
        ...
    }
    buildTypes {
        getByName("release") {
            isMinifyEnabled = true
            proguardFiles(getDefaultProguardFile("proguard-android.txt"), "proguard-rules.pro")
        }

        getByName("debug") {
            applicationIdSuffix = ".debug"
            isDebuggable = true
        }

        /**
         * The `initWith` property lets you copy configurations from other build types,
         * then configure only the settings you want to change. This one copies the debug build
         * type, and then changes the manifest placeholder and application ID.
         */
        create("staging") {
            initWith(getByName("debug"))
            manifestPlaceholders["hostName"] = "internal.example.com"
            applicationIdSuffix = ".debugStaging"
        }
    }
}

Groovy

android {
    defaultConfig {
        manifestPlaceholders = [hostName:"www.example.com"]
        ...
    }
    buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }

        debug {
            applicationIdSuffix ".debug"
            debuggable true
        }

        /**
         * The `initWith` property lets you copy configurations from other build types,
         * then configure only the settings you want to change. This one copies the debug build
         * type, and then changes the manifest placeholder and application ID.
         */
        staging {
            initWith debug
            manifestPlaceholders = [hostName:"internal.example.com"]
            applicationIdSuffix ".debugStaging"
        }
    }
}

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

बिल्ड टाइप के साथ कॉन्फ़िगर की जा सकने वाली सभी प्रॉपर्टी के बारे में ज़्यादा जानने के लिए, BuildType रेफ़रंस पढ़ें.

प्रॉडक्ट के फ़्लेवर कॉन्फ़िगर करना

प्रॉडक्ट फ़्लेवर बनाना, बिल्ड टाइप बनाने जैसा ही है. अपने बिल्ड कॉन्फ़िगरेशन में मौजूद productFlavors ब्लॉक में प्रॉडक्ट फ़्लेवर जोड़ें. साथ ही, अपनी पसंद की सेटिंग शामिल करें. प्रॉडक्ट फ़्लेवर, defaultConfig की तरह ही प्रॉपर्टी के साथ काम करते हैं. ऐसा इसलिए, क्योंकि defaultConfig असल में ProductFlavor क्लास से जुड़ा है. इसका मतलब है कि defaultConfig ब्लॉक में सभी फ़्लेवर के लिए बुनियादी कॉन्फ़िगरेशन दिया जा सकता है. साथ ही, हर फ़्लेवर इनमें से किसी भी डिफ़ॉल्ट वैल्यू को बदल सकता है. जैसे, applicationId. ऐप्लिकेशन आईडी के बारे में ज़्यादा जानने के लिए, ऐप्लिकेशन आईडी सेट करना लेख पढ़ें.

ध्यान दें: आपको अब भी main/ मेनिफ़ेस्ट फ़ाइल में, package एट्रिब्यूट का इस्तेमाल करके पैकेज का नाम बताना होगा. आपको अपने सोर्स कोड में भी उसी पैकेज के नाम का इस्तेमाल करना होगा, ताकि R क्लास को रेफ़र किया जा सके. इसके अलावा, इससे किसी भी गतिविधि या सेवा के रजिस्ट्रेशन से जुड़ी समस्या को हल किया जा सकता है. इससे आपको applicationId का इस्तेमाल करके, हर प्रॉडक्ट के फ़्लेवर को पैकेजिंग और डिस्ट्रिब्यूशन के लिए यूनीक आईडी देने में मदद मिलती है. इसके लिए, आपको सोर्स कोड में बदलाव करने की ज़रूरत नहीं होती.

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

  Error: All flavors must now belong to a named flavor dimension.
  The flavor 'flavor_name' is not assigned to a flavor dimension.

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

यहां दिए गए कोड सैंपल में, "version" नाम का फ़्लेवर डाइमेंशन बनाया गया है. साथ ही, इसमें "demo" और "full" प्रॉडक्ट फ़्लेवर जोड़े गए हैं. इन फ़्लेवर के अपने applicationIdSuffix और versionNameSuffix होते हैं:

Kotlin

android {
    ...
    defaultConfig {...}
    buildTypes {
        getByName("debug"){...}
        getByName("release"){...}
    }
    // Specifies one flavor dimension.
    flavorDimensions += "version"
    productFlavors {
        create("demo") {
            // Assigns this product flavor to the "version" flavor dimension.
            // If you are using only one dimension, this property is optional,
            // and the plugin automatically assigns all the module's flavors to
            // that dimension.
            dimension = "version"
            applicationIdSuffix = ".demo"
            versionNameSuffix = "-demo"
        }
        create("full") {
            dimension = "version"
            applicationIdSuffix = ".full"
            versionNameSuffix = "-full"
        }
    }
}

Groovy

android {
    ...
    defaultConfig {...}
    buildTypes {
        debug{...}
        release{...}
    }
    // Specifies one flavor dimension.
    flavorDimensions "version"
    productFlavors {
        demo {
            // Assigns this product flavor to the "version" flavor dimension.
            // If you are using only one dimension, this property is optional,
            // and the plugin automatically assigns all the module's flavors to
            // that dimension.
            dimension "version"
            applicationIdSuffix ".demo"
            versionNameSuffix "-demo"
        }
        full {
            dimension "version"
            applicationIdSuffix ".full"
            versionNameSuffix "-full"
        }
    }
}

ध्यान दें: अगर आपके पास कोई लेगसी ऐप्लिकेशन (अगस्त 2021 से पहले बनाया गया) है और उसे Google Play पर APK का इस्तेमाल करके डिस्ट्रिब्यूट किया जाता है, तो Google Play पर एक से ज़्यादा APK इस्तेमाल करने की सुविधा का इस्तेमाल करके ऐप्लिकेशन को डिस्ट्रिब्यूट करने के लिए, सभी वैरिएंट को एक ही applicationId वैल्यू असाइन करें. साथ ही, हर वैरिएंट को अलग versionCode दें. Google Play पर अपने ऐप्लिकेशन के अलग-अलग वैरिएंट को अलग-अलग ऐप्लिकेशन के तौर पर डिस्ट्रिब्यूट करने के लिए, आपको हर वैरिएंट को अलग applicationId असाइन करना होगा.

प्रॉडक्ट के फ़्लेवर बनाने और उन्हें कॉन्फ़िगर करने के बाद, सूचना बार में अभी सिंक करें पर क्लिक करें. सिंक पूरा होने के बाद, Gradle आपके बिल्ड टाइप और प्रॉडक्ट फ़्लेवर के आधार पर, बिल्ड वैरिएंट अपने-आप बनाता है. साथ ही, उन्हें <product-flavor><Build-Type> के हिसाब से नाम देता है. उदाहरण के लिए, अगर आपने "demo" और "full" प्रॉडक्ट फ़्लेवर बनाए हैं और डिफ़ॉल्ट "debug" और "release" बिल्ड टाइप रखे हैं, तो Gradle ये बिल्ड वैरिएंट बनाता है:

  • demoDebug
  • demoRelease
  • fullDebug
  • fullRelease

यह चुनने के लिए कि कौनसे बिल्ड वैरिएंट को बनाना और चलाना है, बिल्ड करें > बिल्ड वैरिएंट चुनें पर जाएं. इसके बाद, मेन्यू से कोई बिल्ड वैरिएंट चुनें. हर बिल्ड वैरिएंट को उसकी सुविधाओं और संसाधनों के हिसाब से पसंद के मुताबिक बनाने के लिए, आपको सोर्स सेट बनाने और मैनेज करने होंगे. इस पेज पर इसके बारे में बताया गया है.

बिल्ड वैरिएंट के लिए ऐप्लिकेशन आईडी बदलना

अपने ऐप्लिकेशन के लिए APK या AAB बनाते समय, बिल्ड टूल ऐप्लिकेशन को build.gradle.kts फ़ाइल के defaultConfig ब्लॉक में तय किए गए ऐप्लिकेशन आईडी से टैग करते हैं. इसे यहां दिए गए उदाहरण में दिखाया गया है. हालांकि, अगर आपको Google Play Store पर अलग-अलग लिस्टिंग के तौर पर दिखाने के लिए, अपने ऐप्लिकेशन के अलग-अलग वर्शन बनाने हैं, जैसे कि "मुफ़्त" और "प्रो" वर्शन, तो आपको अलग-अलग बिल्ड वैरिएंट बनाने होंगे. हर वैरिएंट का ऐप्लिकेशन आईडी अलग होना चाहिए.

इस मामले में, हर बिल्ड वैरिएंट को एक अलग प्रॉडक्ट फ़्लेवर के तौर पर तय करें. productFlavors ब्लॉक में मौजूद हर फ़्लेवर के लिए, applicationId प्रॉपर्टी को फिर से तय किया जा सकता है. इसके अलावा, applicationIdSuffix का इस्तेमाल करके, डिफ़ॉल्ट ऐप्लिकेशन आईडी में कोई सेगमेंट जोड़ा जा सकता है. इसे यहां दिखाया गया है:

Kotlin

android {
    defaultConfig {
        applicationId = "com.example.myapp"
    }
    productFlavors {
        create("free") {
            applicationIdSuffix = ".free"
        }
        create("pro") {
            applicationIdSuffix = ".pro"
        }
    }
}

Groovy

android {
    defaultConfig {
        applicationId "com.example.myapp"
    }
    productFlavors {
        free {
            applicationIdSuffix ".free"
        }
        pro {
            applicationIdSuffix ".pro"
        }
    }
}

इस तरह, "मुफ़्त" प्रॉडक्ट फ़्लेवर के लिए ऐप्लिकेशन आईडी "com.example.myapp.free" है.

यहां दिखाए गए तरीके से, अपने बिल्ड टाइप के आधार पर सेगमेंट जोड़ने के लिए, applicationIdSuffix का इस्तेमाल भी किया जा सकता है:

Kotlin

android {
    ...
    buildTypes {
        getByName("debug") {
            applicationIdSuffix = ".debug"
        }
    }
}

Groovy

android {
    ...
    buildTypes {
        debug {
            applicationIdSuffix ".debug"
        }
    }
}

Gradle, प्रॉडक्ट फ़्लेवर के बाद बिल्ड टाइप कॉन्फ़िगरेशन लागू करता है. इसलिए, "free debug" बिल्ड वैरिएंट के लिए ऐप्लिकेशन आईडी "com.example.myapp.free.debug" है. यह तब काम आता है, जब आपको एक ही डिवाइस पर डीबग और रिलीज़, दोनों वर्शन चाहिए. ऐसा इसलिए, क्योंकि किसी भी दो ऐप्लिकेशन का ऐप्लिकेशन आईडी एक जैसा नहीं हो सकता.

अगर आपके पास कोई लेगसी ऐप्लिकेशन (अगस्त 2021 से पहले बनाया गया) है जिसे Google Play पर APKs का इस्तेमाल करके डिस्ट्रिब्यूट किया जाता है और आपको एक ही ऐप्लिकेशन लिस्टिंग का इस्तेमाल करके, कई APKs डिस्ट्रिब्यूट करने हैं, तो आपको हर बिल्ड वैरिएंट के लिए एक ही ऐप्लिकेशन आईडी का इस्तेमाल करना होगा. हालांकि, आपको हर APK को अलग versionCode देना होगा. ज़्यादा जानकारी के लिए, एक से ज़्यादा एपीके इस्तेमाल करने की सुविधा के बारे में पढ़ें. AAB का इस्तेमाल करके पब्लिश करने पर कोई असर नहीं पड़ता, क्योंकि यह एक ऐसे आर्टफ़ैक्ट का इस्तेमाल करता है जो डिफ़ॉल्ट रूप से एक वर्शन कोड और ऐप्लिकेशन आईडी का इस्तेमाल करता है.

अहम जानकारी: अगर आपको अपनी मेनिफ़ेस्ट फ़ाइल में ऐप्लिकेशन आईडी का रेफ़रंस देना है, तो किसी भी मेनिफ़ेस्ट एट्रिब्यूट में ${applicationId} प्लेसहोल्डर का इस्तेमाल किया जा सकता है. बिल्ड के दौरान, Gradle इस टैग की जगह असल ऐप्लिकेशन आईडी का इस्तेमाल करता है. ज़्यादा जानकारी के लिए, मेनिफ़ेस्ट में बिल्ड वैरिएबल इंजेक्ट करना लेख पढ़ें.

प्रॉडक्ट के कई फ़्लेवर को फ़्लेवर डाइमेंशन के साथ जोड़ना

कुछ मामलों में, आपको प्रॉडक्ट के अलग-अलग वर्शन के कॉन्फ़िगरेशन को एक साथ जोड़ना पड़ सकता है. उदाहरण के लिए, आपको एपीआई लेवल के आधार पर, "full" और "demo" प्रॉडक्ट फ़्लेवर के लिए अलग-अलग कॉन्फ़िगरेशन बनाने पड़ सकते हैं. इसके लिए, Android Gradle प्लगिन की मदद से, प्रॉडक्ट फ़्लेवर के कई ग्रुप बनाए जा सकते हैं. इन्हें फ़्लेवर डाइमेंशन के तौर पर इस्तेमाल किया जाता है.

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

नीचे दिए गए कोड के नमूने में, flavorDimensions प्रॉपर्टी का इस्तेमाल किया गया है. इससे "मोड" फ़्लेवर डाइमेंशन बनाया जाता है, ताकि "फ़ुल" और "डेमो" प्रॉडक्ट फ़्लेवर को ग्रुप किया जा सके. साथ ही, "एपीआई" फ़्लेवर डाइमेंशन बनाया जाता है, ताकि एपीआई लेवल के आधार पर प्रॉडक्ट फ़्लेवर कॉन्फ़िगरेशन को ग्रुप किया जा सके:

Kotlin

android {
  ...
  buildTypes {
    getByName("debug") {...}
    getByName("release") {...}
  }

  // Specifies the flavor dimensions you want to use. The order in which you
  // list the dimensions determines their priority, from highest to lowest,
  // when Gradle merges variant sources and configurations. You must assign
  // each product flavor you configure to one of the flavor dimensions.
  flavorDimensions += listOf("api", "mode")

  productFlavors {
    create("demo") {
      // Assigns this product flavor to the "mode" flavor dimension.
      dimension = "mode"
      ...
    }

    create("full") {
      dimension = "mode"
      ...
    }

    // Configurations in the "api" product flavors override those in "mode"
    // flavors and the defaultConfig block. Gradle determines the priority
    // between flavor dimensions based on the order in which they appear next
    // to the flavorDimensions property, with the first dimension having a higher
    // priority than the second, and so on.
    create("minApi24") {
      dimension = "api"
      minSdk = 24
      // To ensure the target device receives the version of the app with
      // the highest compatible API level, assign version codes in increasing
      // value with API level.
      versionCode = 30000 + (android.defaultConfig.versionCode ?: 0)
      versionNameSuffix = "-minApi24"
      ...
    }

    create("minApi23") {
      dimension = "api"
      minSdk = 23
      versionCode = 20000  + (android.defaultConfig.versionCode ?: 0)
      versionNameSuffix = "-minApi23"
      ...
    }

    create("minApi21") {
      dimension = "api"
      minSdk = 21
      versionCode = 10000  + (android.defaultConfig.versionCode ?: 0)
      versionNameSuffix = "-minApi21"
      ...
    }
  }
}
...

Groovy

android {
  ...
  buildTypes {
    debug {...}
    release {...}
  }

  // Specifies the flavor dimensions you want to use. The order in which you
  // list the dimensions determines their priority, from highest to lowest,
  // when Gradle merges variant sources and configurations. You must assign
  // each product flavor you configure to one of the flavor dimensions.
  flavorDimensions "api", "mode"

  productFlavors {
    demo {
      // Assigns this product flavor to the "mode" flavor dimension.
      dimension "mode"
      ...
    }

    full {
      dimension "mode"
      ...
    }

    // Configurations in the "api" product flavors override those in "mode"
    // flavors and the defaultConfig block. Gradle determines the priority
    // between flavor dimensions based on the order in which they appear next
    // to the flavorDimensions property, with the first dimension having a higher
    // priority than the second, and so on.
    minApi24 {
      dimension "api"
      minSdkVersion 24
      // To ensure the target device receives the version of the app with
      // the highest compatible API level, assign version codes in increasing
      // value with API level.

      versionCode 30000 + android.defaultConfig.versionCode
      versionNameSuffix "-minApi24"
      ...
    }

    minApi23 {
      dimension "api"
      minSdkVersion 23
      versionCode 20000  + android.defaultConfig.versionCode
      versionNameSuffix "-minApi23"
      ...
    }

    minApi21 {
      dimension "api"
      minSdkVersion 21
      versionCode 10000  + android.defaultConfig.versionCode
      versionNameSuffix "-minApi21"
      ...
    }
  }
}
...

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

पिछले बिल्ड कॉन्फ़िगरेशन का इस्तेमाल करके, Gradle कुल 12 बिल्ड वैरिएंट बनाता है. इनके नाम इस तरह रखे जाते हैं:

  • बिल्ड का वैरिएंट: [minApi24, minApi23, minApi21][Demo, Full][Debug, Release]
  • मिलता-जुलता APK: app-[minApi24, minApi23, minApi21]-[demo, full]-[debug, release].apk
    • जैसे, मुझे पता चला कि
    बिल्ड वैरिएंट: minApi24DemoDebug
    इससे जुड़ा APK: app-minApi24-demo-debug.apk

हर प्रॉडक्ट फ़्लेवर और बिल्ड वैरिएंट के लिए सोर्स सेट डायरेक्ट्री बनाने के अलावा, प्रॉडक्ट फ़्लेवर के हर कॉम्बिनेशन के लिए भी सोर्स सेट डायरेक्ट्री बनाई जा सकती है. उदाहरण के लिए, src/demoMinApi24/java/ डायरेक्ट्री में Java सोर्स बनाए और जोड़े जा सकते हैं. साथ ही, Gradle उन सोर्स का इस्तेमाल सिर्फ़ तब करता है, जब वह ऐसा वैरिएंट बना रहा हो जिसमें उन दोनों प्रॉडक्ट फ़्लेवर को शामिल किया गया हो.

प्रॉडक्ट के फ़्लेवर के कॉम्बिनेशन के लिए बनाए गए सोर्स सेट को, हर प्रॉडक्ट के फ़्लेवर के सोर्स सेट की तुलना में ज़्यादा प्राथमिकता मिलती है. सोर्स सेट और Gradle के संसाधनों को मर्ज करने के तरीके के बारे में ज़्यादा जानने के लिए, सोर्स सेट बनाने का तरीका बताने वाला सेक्शन पढ़ें.

वैरिएंट फ़िल्टर करना

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

पिछले सेक्शन में दिए गए बिल्ड कॉन्फ़िगरेशन का इस्तेमाल करके, मान लें कि आपको ऐप्लिकेशन के डेमो वर्शन के लिए, सिर्फ़ एपीआई लेवल 23 और इससे ऊपर के वर्शन को सपोर्ट करना है. "minApi21" और "demo" प्रॉडक्ट फ़्लेवर को एक साथ इस्तेमाल करने वाले सभी बिल्ड वैरिएंट कॉन्फ़िगरेशन को फ़िल्टर करने के लिए, variantFilter ब्लॉक का इस्तेमाल किया जा सकता है:

Kotlin

android {
  ...
  buildTypes {...}

  flavorDimensions += listOf("api", "mode")
  productFlavors {
    create("demo") {...}
    create("full") {...}
    create("minApi24") {...}
    create("minApi23") {...}
    create("minApi21") {...}
  }
}

androidComponents {
    beforeVariants { variantBuilder ->
        // To check for a certain build type, use variantBuilder.buildType == "<buildType>"
        if (variantBuilder.productFlavors.containsAll(listOf("api" to "minApi21", "mode" to "demo"))) {
            // Gradle ignores any variants that satisfy the conditions above.
            variantBuilder.enable = false
        }
    }
}
...

Groovy

android {
  ...
  buildTypes {...}

  flavorDimensions "api", "mode"
  productFlavors {
    demo {...}
    full {...}
    minApi24 {...}
    minApi23 {...}
    minApi21 {...}
  }

  variantFilter { variant ->
      def names = variant.flavors*.name
      // To check for a certain build type, use variant.buildType.name == "<buildType>"
      if (names.contains("minApi21") && names.contains("demo")) {
          // Gradle ignores any variants that satisfy the conditions above.
          setIgnore(true)
      }
  }
}
...

अपने बिल्ड कॉन्फ़िगरेशन में वैरिएंट फ़िल्टर जोड़ने और सूचना बार में अभी सिंक करें पर क्लिक करने के बाद, Gradle उन सभी बिल्ड वैरिएंट को अनदेखा कर देता है जो आपकी तय की गई शर्तों को पूरा करते हैं. मेन्यू बार में मौजूद Build > Select Build Variant पर क्लिक करने पर, अब मेन्यू में बिल्ड वैरिएंट नहीं दिखते. इसके अलावा, टूल विंडो बार में मौजूद Build Variants पर क्लिक करने पर भी बिल्ड वैरिएंट नहीं दिखते.

सोर्स सेट बनाना

डिफ़ॉल्ट रूप से, Android Studio main/ सोर्स सेट और डायरेक्ट्री बनाता है. इनका इस्तेमाल, सभी बिल्ड वैरिएंट के बीच शेयर की जाने वाली हर चीज़ के लिए किया जाता है. हालांकि, नई सोर्स सेट बनाई जा सकती हैं. इनसे यह कंट्रोल किया जा सकता है कि Gradle, खास बिल्ड टाइप, प्रॉडक्ट फ़्लेवर, प्रॉडक्ट फ़्लेवर के कॉम्बिनेशन (फ़्लेवर डाइमेंशन का इस्तेमाल करते समय), और बिल्ड वैरिएंट के लिए किन फ़ाइलों को कंपाइल और पैकेज करता है.

उदाहरण के लिए, main/ सोर्स सेट में बुनियादी फ़ंक्शन तय किए जा सकते हैं. साथ ही, अलग-अलग क्लाइंट के लिए अपने ऐप्लिकेशन की ब्रैंडिंग बदलने के लिए, प्रॉडक्ट फ़्लेवर सोर्स सेट का इस्तेमाल किया जा सकता है. इसके अलावा, सिर्फ़ उन बिल्ड वैरिएंट के लिए खास अनुमतियां और लॉगिंग की सुविधा शामिल की जा सकती है जो डीबग बिल्ड टाइप का इस्तेमाल करते हैं.

Gradle को सोर्स सेट की फ़ाइलों और डायरेक्ट्री को एक खास तरीके से व्यवस्थित करने की ज़रूरत होती है. यह तरीका, main/ सोर्स सेट के जैसा होता है. उदाहरण के लिए, Gradle को Kotlin या Java क्लास फ़ाइलों की ज़रूरत होती है. ये फ़ाइलें, आपके "debug" बिल्ड टाइप के हिसाब से होनी चाहिए. साथ ही, ये src/debug/kotlin/ या src/debug/java/ डायरेक्ट्री में मौजूद होनी चाहिए.

Android Gradle प्लग इन, Gradle का एक ऐसा टास्क उपलब्ध कराता है जो आपको यह दिखाता है कि अपने हर बिल्ड टाइप, प्रॉडक्ट फ़्लेवर, और बिल्ड वैरिएंट के लिए फ़ाइलों को कैसे व्यवस्थित किया जाए. उदाहरण के लिए, टास्क के आउटपुट के इस सैंपल में बताया गया है कि Gradle को "debug" बिल्ड टाइप के लिए, कुछ फ़ाइलें कहां मिलेंगी: 

------------------------------------------------------------
Project :app
------------------------------------------------------------

...

debug
----
Compile configuration: debugCompile
build.gradle name: android.sourceSets.debug
Java sources: [app/src/debug/java]
Kotlin sources: [app/src/debug/kotlin, app/src/debug/java]
Manifest file: app/src/debug/AndroidManifest.xml
Android resources: [app/src/debug/res]
Assets: [app/src/debug/assets]
AIDL sources: [app/src/debug/aidl]
RenderScript sources: [app/src/debug/rs]
JNI sources: [app/src/debug/jni]
JNI libraries: [app/src/debug/jniLibs]
Java-style resources: [app/src/debug/resources]

इस आउटपुट को देखने के लिए, यह तरीका अपनाएं:

  1. टूल विंडो बार में, Gradle पर क्लिक करें.

  2. MyApplication > Tasks > android पर जाएं और sourceSets पर दो बार क्लिक करें.

    Tasks फ़ोल्डर देखने के लिए, आपको Gradle को सिंक करने के दौरान टास्क की सूची बनाने की अनुमति देनी होगी. ऐसा करने के लिए, यहां दिया गया तरीका अपनाएं:

    1. फ़ाइल > सेटिंग > एक्सपेरिमेंटल पर क्लिक करें (macOS पर Android Studio > सेटिंग > एक्सपेरिमेंटल पर क्लिक करें).
    2. Gradle सिंक के दौरान, Gradle टास्क की सूची न बनाएं को अनचेक करें.
  3. Gradle के टास्क पूरा करने के बाद, Run विंडो खुलती है. इसमें आउटपुट दिखता है.

ध्यान दें: टास्क के आउटपुट में यह भी दिखाया जाता है कि ऐप्लिकेशन की जांच करने के लिए इस्तेमाल की जाने वाली फ़ाइलों के सोर्स सेट कैसे व्यवस्थित करें. जैसे, test/ और androidTest/ टेस्टिंग सोर्स सेट.

नया बिल्ड वैरिएंट बनाते समय, Android Studio आपके लिए सोर्स सेट डायरेक्ट्री नहीं बनाता. हालांकि, यह आपकी मदद करने के लिए कुछ विकल्प ज़रूर देता है. उदाहरण के लिए, "debug" बिल्ड टाइप के लिए सिर्फ़ java/ डायरेक्ट्री बनाने के लिए:

  1. प्रोजेक्ट पैनल खोलें. इसके बाद, पैनल में सबसे ऊपर मौजूद मेन्यू से प्रोजेक्ट व्यू चुनें.
  2. MyProject/app/src/ पर जाएं.
  3. src डायरेक्ट्री पर राइट क्लिक करें और नया > डायरेक्ट्री चुनें.
  4. Gradle Source Sets में जाकर, मेन्यू से full/java चुनें.
  5. Enter दबाएं.

Android Studio, आपके डिबग बिल्ड टाइप के लिए एक सोर्स सेट डायरेक्ट्री बनाता है. इसके बाद, इसमें java/ डायरेक्ट्री बनाता है. इसके अलावा, Android Studio, आपके लिए डायरेक्ट्री बना सकता है. इसके लिए, आपको किसी खास बिल्ड वैरिएंट के लिए अपने प्रोजेक्ट में नई फ़ाइल जोड़नी होगी.

उदाहरण के लिए, "debug" बिल्ड टाइप के लिए वैल्यू वाली एक्सएमएल फ़ाइल बनाने के लिए:

  1. Project पैन में, src डायरेक्ट्री पर राइट क्लिक करें. इसके बाद, New > XML > Values XML File को चुनें.
  2. एक्सएमएल फ़ाइल का नाम डालें या डिफ़ॉल्ट नाम का इस्तेमाल करें.
  3. टारगेट सोर्स सेट के बगल में मौजूद मेन्यू से, debug चुनें.
  4. पूरा करें पर क्लिक करें.

"debug" बिल्ड टाइप को टारगेट सोर्स सेट के तौर पर तय किया गया था. इसलिए, Android Studio, एक्सएमएल फ़ाइल बनाते समय ज़रूरी डायरेक्ट्री अपने-आप बना देता है. इससे मिलने वाला डायरेक्ट्री स्ट्रक्चर, पहली इमेज में दिखाया गया है.

पहली इमेज. "debug" बिल्ड टाइप के लिए, नई सोर्स सेट डायरेक्ट्री.

चालू सोर्स सेट के आइकॉन में हरे रंग का इंडिकेटर होता है. इससे पता चलता है कि वे चालू हैं. debug सोर्स सेट में [main] जोड़ा गया है, ताकि यह दिखाया जा सके कि इसे main सोर्स सेट में मर्ज किया जाएगा.

इसी तरीके का इस्तेमाल करके, प्रॉडक्ट के फ़्लेवर, जैसे कि src/demo/, और बिल्ड वैरिएंट, जैसे कि src/demoDebug/, के लिए सोर्स सेट डायरेक्ट्री भी बनाई जा सकती हैं. इसके अलावा, टेस्टिंग के लिए सोर्स सेट बनाए जा सकते हैं. ये सोर्स सेट, खास बिल्ड वैरिएंट को टारगेट करते हैं. जैसे, src/androidTestDemoDebug/. ज़्यादा जानने के लिए, सोर्स सेट की टेस्टिंग के बारे में पढ़ें.

सोर्स सेट के डिफ़ॉल्ट कॉन्फ़िगरेशन बदलना

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

sourceSets ब्लॉक, android ब्लॉक में होना चाहिए. आपको सोर्स फ़ाइलों की जगह बदलने की ज़रूरत नहीं है. आपको सिर्फ़ Gradle को उन पाथ की जानकारी देनी है जहां Gradle, हर सोर्स सेट कॉम्पोनेंट के लिए फ़ाइलें ढूंढ सकता है. ये पाथ, मॉड्यूल-लेवल की build.gradle.kts फ़ाइल के हिसाब से होने चाहिए. यह जानने के लिए कि किन कॉम्पोनेंट को कॉन्फ़िगर किया जा सकता है और क्या उन्हें एक से ज़्यादा फ़ाइलों या डायरेक्ट्री में मैप किया जा सकता है, Android Gradle प्लगिन के एपीआई रेफ़रंस देखें.

यहां दिए गए कोड के सैंपल में, app/other/ डायरेक्ट्री के सोर्स को main सोर्स सेट के कुछ कॉम्पोनेंट पर मैप किया गया है. साथ ही, androidTest सोर्स सेट की रूट डायरेक्ट्री को बदला गया है:

Kotlin

android {
  ...
  // Encapsulates configurations for the main source set.
  sourceSets.getByName("main") {
    // Changes the directory for Java sources. The default directory is
    // 'src/main/java'.
    java.setSrcDirs(listOf("other/java"))

    // If you list multiple directories, Gradle uses all of them to collect
    // sources. Because Gradle gives these directories equal priority, if
    // you define the same resource in more than one directory, you receive an
    // error when merging resources. The default directory is 'src/main/res'.
    res.setSrcDirs(listOf("other/res1", "other/res2"))

    // Note: Avoid specifying a directory that is a parent to one
    // or more other directories you specify. For example, avoid the following:
    // res.srcDirs = ['other/res1', 'other/res1/layouts', 'other/res1/strings']
    // Specify either only the root 'other/res1' directory or only the
    // nested 'other/res1/layouts' and 'other/res1/strings' directories.

    // For each source set, you can specify only one Android manifest.
    // By default, Android Studio creates a manifest for your main source
    // set in the src/main/ directory.
    manifest.srcFile("other/AndroidManifest.xml")
    ...
  }

  // Create additional blocks to configure other source sets.
  sourceSets.getByName("androidTest") {
      // If all the files for a source set are located under a single root
      // directory, you can specify that directory using the setRoot property.
      // When gathering sources for the source set, Gradle looks only in locations
      // relative to the root directory you specify. For example, after applying the
      // configuration below for the androidTest source set, Gradle looks for Java
      // sources only in the src/tests/java/ directory.
      setRoot("src/tests")
      ...
  }
}
...

Groovy

android {
  ...
  sourceSets {
    // Encapsulates configurations for the main source set.
    main {
      // Changes the directory for Java sources. The default directory is
      // 'src/main/java'.
      java.srcDirs = ['other/java']

      // If you list multiple directories, Gradle uses all of them to collect
      // sources. Because Gradle gives these directories equal priority, if
      // you define the same resource in more than one directory, you receive an
      // error when merging resources. The default directory is 'src/main/res'.
      res.srcDirs = ['other/res1', 'other/res2']

      // Note: Avoid specifying a directory that is a parent to one
      // or more other directories you specify. For example, avoid the following:
      // res.srcDirs = ['other/res1', 'other/res1/layouts', 'other/res1/strings']
      // Specify either only the root 'other/res1' directory or only the
      // nested 'other/res1/layouts' and 'other/res1/strings' directories.

      // For each source set, you can specify only one Android manifest.
      // By default, Android Studio creates a manifest for your main source
      // set in the src/main/ directory.
      manifest.srcFile 'other/AndroidManifest.xml'
      ...
    }

    // Create additional blocks to configure other source sets.
    androidTest {

      // If all the files for a source set are located under a single root
      // directory, you can specify that directory using the setRoot property.
      // When gathering sources for the source set, Gradle looks only in locations
      // relative to the root directory you specify. For example, after applying the
      // configuration below for the androidTest source set, Gradle looks for Java
      // sources only in the src/tests/java/ directory.
      setRoot 'src/tests'
      ...
    }
  }
}
...

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

सोर्स सेट की मदद से बनाना

सोर्स सेट डायरेक्ट्री का इस्तेमाल करके, कोड और संसाधनों को सिर्फ़ कुछ कॉन्फ़िगरेशन के साथ पैकेज किया जा सकता है. उदाहरण के लिए, अगर आपको "demoDebug" बिल्ड वैरिएंट बनाना है, जो "demo" प्रॉडक्ट फ़्लेवर और "debug" बिल्ड टाइप का क्रॉसप्रॉडक्ट है, तो Gradle इन डायरेक्ट्री को देखता है और इन्हें यह प्राथमिकता देता है:

  1. src/demoDebug/ (बिल्ड वैरिएंट सोर्स सेट)
  2. src/debug/ (बिल्ड टाइप सोर्स सेट)
  3. src/demo/ (प्रॉडक्ट फ़्लेवर का सोर्स सेट किया गया है)
  4. src/main/ (मुख्य सोर्स सेट)

प्रॉडक्ट के फ़्लेवर के कॉम्बिनेशन के लिए बनाए गए सोर्स सेट में, फ़्लेवर के सभी डाइमेंशन शामिल होने चाहिए. उदाहरण के लिए, बिल्ड वैरिएंट सोर्स सेट, बिल्ड टाइप और सभी फ़्लेवर डाइमेंशन का कॉम्बिनेशन होना चाहिए. ऐसे फ़ोल्डर को कोड और संसाधनों के साथ मर्ज नहीं किया जा सकता जिनमें कई फ़्लेवर डाइमेंशन शामिल हों, लेकिन सभी नहीं.

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

प्राथमिकता के क्रम से यह तय होता है कि जब Gradle कोड और संसाधनों को जोड़ता है, तो किस सोर्स सेट को ज़्यादा प्राथमिकता दी जाती है. demoDebug/ सोर्स सेट डायरेक्ट्री में ऐसी फ़ाइलें होती हैं जो उस बिल्ड वैरिएंट के लिए खास होती हैं. इसलिए, अगर demoDebug/ में ऐसी फ़ाइल शामिल है जिसे debug/ में भी तय किया गया है, तो Gradle, demoDebug/ सोर्स सेट में मौजूद फ़ाइल का इस्तेमाल करता है. इसी तरह, Gradle, बिल्ड टाइप और प्रॉडक्ट फ़्लेवर के सोर्स सेट में मौजूद फ़ाइलों को, main/ में मौजूद फ़ाइलों के मुकाबले ज़्यादा प्राथमिकता देता है. Gradle, बिल्ड के इन नियमों को लागू करते समय प्राथमिकता के इस क्रम का ध्यान रखता है:

  • kotlin/ या java/ डायरेक्ट्री में मौजूद सभी सोर्स कोड को एक साथ कंपाइल किया जाता है, ताकि एक आउटपुट जनरेट किया जा सके.

    ध्यान दें: अगर Gradle को किसी बिल्ड वैरिएंट के लिए, एक ही Kotlin या Java क्लास को तय करने वाली दो या उससे ज़्यादा सोर्स सेट डायरेक्ट्री मिलती हैं, तो वह बिल्ड से जुड़ी गड़बड़ी दिखाता है. उदाहरण के लिए, डीबग ऐप्लिकेशन बनाते समय, src/debug/Utility.kt और src/main/Utility.kt, दोनों को एक साथ तय नहीं किया जा सकता. ऐसा इसलिए, क्योंकि Gradle, बिल्ड प्रोसेस के दौरान इन दोनों डायरेक्ट्री को देखता है और "डुप्लीकेट क्लास" वाली गड़बड़ी दिखाता है. अगर आपको अलग-अलग बिल्ड टाइप के लिए Utility.kt के अलग-अलग वर्शन चाहिए, तो हर बिल्ड टाइप को फ़ाइल का अपना वर्शन तय करना होगा. साथ ही, उसे Utility.kt सोर्स सेट में शामिल नहीं करना होगा.main/

  • मेनिफ़ेस्ट को एक साथ मर्ज करके एक मेनिफ़ेस्ट बनाया जाता है. प्राथमिकता उसी क्रम में दी जाती है जिस क्रम में पिछले उदाहरण में सूची दी गई है. इसका मतलब है कि बिल्ड टाइप के लिए मेनिफ़ेस्ट सेटिंग, प्रॉडक्ट फ़्लेवर के लिए मेनिफ़ेस्ट सेटिंग को बदल देती हैं. इसी तरह, अन्य सेटिंग भी बदल जाती हैं. ज़्यादा जानने के लिए, मेनिफ़ेस्ट मर्ज करने की सुविधा के बारे में पढ़ें.
  • values/ डायरेक्ट्री में मौजूद फ़ाइलों को एक साथ मर्ज कर दिया जाता है. अगर दो फ़ाइलों का नाम एक जैसा है, जैसे कि दो strings.xml फ़ाइलें, तो उन्हें प्राथमिकता उसी क्रम में दी जाती है जिस क्रम में पिछले उदाहरण में दी गई है. इसका मतलब है कि बिल्ड टाइप के सोर्स सेट में मौजूद किसी फ़ाइल में तय की गई वैल्यू, प्रॉडक्ट फ़्लेवर में मौजूद उसी फ़ाइल में तय की गई वैल्यू को बदल देती है. इसी तरह, अन्य वैल्यू भी बदल जाती हैं.
  • res/ और asset/ डायरेक्ट्री में मौजूद संसाधनों को एक साथ पैकेज किया जाता है. अगर दो या इससे ज़्यादा सोर्स सेट में एक ही नाम वाली रिसॉर्स फ़ाइलें मौजूद हैं, तो उन्हें प्राथमिकता उसी क्रम में दी जाती है जिस क्रम में पिछले उदाहरण में दी गई है.
  • ऐप्लिकेशन बनाते समय, Gradle, लाइब्रेरी मॉड्यूल की डिपेंडेंसी में शामिल संसाधनों और मेनिफ़ेस्ट को सबसे कम प्राथमिकता देता है.

डिपेंडेंसी का एलान करना

किसी खास बिल्ड वैरिएंट या टेस्टिंग सोर्स सेट के लिए डिपेंडेंसी कॉन्फ़िगर करने के लिए, Implementation कीवर्ड से पहले बिल्ड वैरिएंट या टेस्टिंग सोर्स सेट का नाम जोड़ें. उदाहरण के लिए:

Kotlin

dependencies {
    // Adds the local "mylibrary" module as a dependency to the "free" flavor.
    "freeImplementation"(project(":mylibrary"))

    // Adds a remote binary dependency only for local tests.
    testImplementation("junit:junit:4.12")

    // Adds a remote binary dependency only for the instrumented test APK.
    androidTestImplementation("com.android.support.test.espresso:espresso-core:3.6.1")
}

Groovy

dependencies {
    // Adds the local "mylibrary" module as a dependency to the "free" flavor.
    freeImplementation project(":mylibrary")

    // Adds a remote binary dependency only for local tests.
    testImplementation 'junit:junit:4.12'

    // Adds a remote binary dependency only for the instrumented test APK.
    androidTestImplementation 'com.android.support.test.espresso:espresso-core:3.6.1'
}

डिपेंडेंसी कॉन्फ़िगर करने के बारे में ज़्यादा जानने के लिए, बिल्ड डिपेंडेंसी जोड़ना लेख पढ़ें.

वैरिएंट के हिसाब से डिपेंडेंसी मैनेज करने की सुविधा का इस्तेमाल करना

Android Gradle प्लगिन 3.0.0 और इससे ऊपर वाले वर्शन में, डिपेंडेंसी का नया तरीका शामिल है. इससे लाइब्रेरी का इस्तेमाल करते समय, वैरिएंट अपने-आप मैच हो जाते हैं. इसका मतलब है कि किसी ऐप्लिकेशन का debug वैरिएंट, लाइब्रेरी के debug वैरिएंट का इस्तेमाल अपने-आप करता है. इसी तरह, अन्य वैरिएंट भी काम करते हैं. यह सुविधा, फ़्लेवर का इस्तेमाल करते समय भी काम करती है: किसी ऐप्लिकेशन का freeDebug वैरिएंट, लाइब्रेरी के freeDebug वैरिएंट का इस्तेमाल करेगा.

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

उदाहरण के लिए, मान लें कि आपका ऐप्लिकेशन "स्टेजिंग" नाम का बिल्ड टाइप कॉन्फ़िगर करता है, लेकिन उसकी लाइब्रेरी की डिपेंडेंसी में से कोई एक ऐसा नहीं करता. जब प्लगिन आपके ऐप्लिकेशन का "स्टेजिंग" वर्शन बनाने की कोशिश करेगा, तब उसे यह पता नहीं चलेगा कि लाइब्रेरी के किस वर्शन का इस्तेमाल करना है. इसलिए, आपको इस तरह का गड़बड़ी का मैसेज दिखेगा: 

Error:Failed to resolve: Could not resolve project :mylibrary.
Required by:
    project :app

वैरिएंट मैचिंग से जुड़ी बिल्ड गड़बड़ियां ठीक करना

इस प्लगिन में डीएसएल एलिमेंट शामिल हैं. इनकी मदद से, यह कंट्रोल किया जा सकता है कि Gradle उन स्थितियों को कैसे हल करे जिनमें किसी ऐप्लिकेशन और डिपेंडेंसी के बीच सीधे तौर पर वैरिएंट मैच नहीं किया जा सकता.

यहां, वैरिएंट के हिसाब से डिपेंडेंसी मैच करने से जुड़ी समस्याओं की सूची दी गई है. साथ ही, डीएसएल प्रॉपर्टी का इस्तेमाल करके उन्हें हल करने का तरीका बताया गया है:

  • आपके ऐप्लिकेशन में ऐसा बिल्ड टाइप शामिल है जो लाइब्रेरी डिपेंडेंसी में नहीं है.

    उदाहरण के लिए, आपके ऐप्लिकेशन में "staging" बिल्ड टाइप शामिल है, लेकिन किसी डिपेंडेंसी में सिर्फ़ "debug" और "release" बिल्ड टाइप शामिल हैं.

    ध्यान दें कि अगर लाइब्रेरी की डिपेंडेंसी में ऐसा बिल्ड टाइप शामिल है जो आपके ऐप्लिकेशन में नहीं है, तो इससे कोई समस्या नहीं होती. ऐसा इसलिए होता है, क्योंकि प्लगिन कभी भी डिपेंडेंसी से उस बिल्ड टाइप का अनुरोध नहीं करता.

    matchingFallbacks का इस्तेमाल करके, किसी दिए गए बिल्ड टाइप के लिए वैकल्पिक मैच तय करें. इसके बारे में यहां बताया गया है:

    Kotlin

    // In the app's build.gradle.kts file.
android {
    buildTypes {
        getByName("debug") {}
        getByName("release") {}
        create("staging") {
            // Specifies a sorted list of fallback build types that the
            // plugin can try to use when a dependency does not include a
            // "staging" build type. You may specify as many fallbacks as you
            // like, and the plugin selects the first build type that's
            // available in the dependency.
            matchingFallbacks += listOf("debug", "qa", "release")
        }
    }
}

    Groovy

    // In the app's build.gradle file.
android {
    buildTypes {
        debug {}
        release {}
        staging {
            // Specifies a sorted list of fallback build types that the
            // plugin can try to use when a dependency does not include a
            // "staging" build type. You may specify as many fallbacks as you
            // like, and the plugin selects the first build type that's
            // available in the dependency.
            matchingFallbacks = ['debug', 'qa', 'release']
        }
    }
}

  • किसी फ़्लेवर डाइमेंशन के लिए, ऐप्लिकेशन और उसकी लाइब्रेरी डिपेंडेंसी, दोनों में मौजूद फ़्लेवर के अलावा, आपके ऐप्लिकेशन में ऐसे फ़्लेवर शामिल हैं जो लाइब्रेरी में मौजूद नहीं हैं.

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

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

    यहां दिखाए गए तरीके से, ऐप्लिकेशन के "मुफ़्त" प्रॉडक्ट फ़्लेवर के लिए, मिलते-जुलते अन्य प्रॉडक्ट तय करने के लिए matchingFallbacks का इस्तेमाल करें:

    Kotlin

    // In the app's build.gradle.kts file.
android {
    defaultConfig{
    // Don't configure matchingFallbacks in the defaultConfig block.
    // Instead, specify fallbacks for a given product flavor in the
    // productFlavors block, as shown below.
  }
    flavorDimensions += "tier"
    productFlavors {
        create("paid") {
            dimension = "tier"
            // Because the dependency already includes a "paid" flavor in its
            // "tier" dimension, you don't need to provide a list of fallbacks
            // for the "paid" flavor.
        }
        create("free") {
            dimension = "tier"
            // Specifies a sorted list of fallback flavors that the plugin
            // can try to use when a dependency's matching dimension does
            // not include a "free" flavor. Specify as many
            // fallbacks as you like; the plugin selects the first flavor
            // that's available in the dependency's "tier" dimension.
            matchingFallbacks += listOf("demo", "trial")
        }
    }
}

    Groovy

    // In the app's build.gradle file.
android {
    defaultConfig{
    // Don't configure matchingFallbacks in the defaultConfig block.
    // Instead, specify fallbacks for a given product flavor in the
    // productFlavors block, as shown below.
  }
    flavorDimensions 'tier'
    productFlavors {
        paid {
            dimension 'tier'
            // Because the dependency already includes a "paid" flavor in its
            // "tier" dimension, you don't need to provide a list of fallbacks
            // for the "paid" flavor.
        }
        free {
            dimension 'tier'
            // Specifies a sorted list of fallback flavors that the plugin
            // can try to use when a dependency's matching dimension does
            // not include a "free" flavor. Specify as many
            // fallbacks as you like; the plugin selects the first flavor
            // that's available in the dependency's "tier" dimension.
            matchingFallbacks = ['demo', 'trial']
        }
    }
}

  • लाइब्रेरी डिपेंडेंसी में एक फ़्लेवर डाइमेंशन शामिल है, जो आपके ऐप्लिकेशन में नहीं है.

    उदाहरण के लिए, किसी लाइब्रेरी डिपेंडेंसी में "minApi" डाइमेंशन के लिए फ़्लेवर शामिल हैं, लेकिन आपके ऐप्लिकेशन में सिर्फ़ "tier" डाइमेंशन के लिए फ़्लेवर शामिल हैं. जब आपको अपने ऐप्लिकेशन का "freeDebug" वर्शन बनाना होता है, तब प्लगिन को यह पता नहीं होता कि डिपेंडेंसी के "minApi23Debug" या "minApi18Debug" वर्शन में से किसका इस्तेमाल करना है.

    ध्यान दें कि अगर आपके ऐप्लिकेशन में कोई ऐसा फ़्लेवर डाइमेंशन शामिल है जो लाइब्रेरी डिपेंडेंसी में नहीं है, तो इससे कोई समस्या नहीं होती. ऐसा इसलिए होता है, क्योंकि प्लगिन सिर्फ़ उन डाइमेंशन के फ़्लेवर से मैच करता है जो डिपेंडेंसी में मौजूद हैं. उदाहरण के लिए, अगर किसी डिपेंडेंसी में ABI के लिए कोई डाइमेंशन शामिल नहीं है, तो आपके ऐप्लिकेशन का "freeX86Debug" वर्शन, डिपेंडेंसी के "freeDebug" वर्शन का इस्तेमाल करेगा.

    defaultConfig ब्लॉक में missingDimensionStrategy का इस्तेमाल करके, प्लगिन के लिए डिफ़ॉल्ट फ़्लेवर तय करें. इससे प्लगिन, हर ऐसे डाइमेंशन के लिए फ़्लेवर चुन पाएगा जो मौजूद नहीं है. ऐसा करने का तरीका, यहां दिए गए सैंपल में दिखाया गया है. productFlavors ब्लॉक में जाकर, अपने चुने गए विकल्पों को बदला भी जा सकता है. इससे हर फ़्लेवर, किसी डाइमेंशन के मौजूद न होने पर, मैचिंग की अलग रणनीति तय कर सकता है.

    Kotlin

    // In the app's build.gradle.kts file.
android {
    defaultConfig{
    // Specifies a sorted list of flavors that the plugin can try to use from
    // a given dimension. This tells the plugin to select the "minApi18" flavor
    // when encountering a dependency that includes a "minApi" dimension.
    // You can include additional flavor names to provide a
    // sorted list of fallbacks for the dimension.
    missingDimensionStrategy("minApi", "minApi18", "minApi23")
    // Specify a missingDimensionStrategy property for each
    // dimension that exists in a local dependency but not in your app.
    missingDimensionStrategy("abi", "x86", "arm64")
    }
    flavorDimensions += "tier"
    productFlavors {
        create("free") {
            dimension = "tier"
            // You can override the default selection at the product flavor
            // level by configuring another missingDimensionStrategy property
            // for the "minApi" dimension.
            missingDimensionStrategy("minApi", "minApi23", "minApi18")
        }
        create("paid") {}
    }
}

    Groovy

    // In the app's build.gradle file.
android {
    defaultConfig{
    // Specifies a sorted list of flavors that the plugin can try to use from
    // a given dimension. This tells the plugin to select the "minApi18" flavor
    // when encountering a dependency that includes a "minApi" dimension.
    // You can include additional flavor names to provide a
    // sorted list of fallbacks for the dimension.
    missingDimensionStrategy 'minApi', 'minApi18', 'minApi23'
    // Specify a missingDimensionStrategy property for each
    // dimension that exists in a local dependency but not in your app.
    missingDimensionStrategy 'abi', 'x86', 'arm64'
    }
    flavorDimensions 'tier'
    productFlavors {
        free {
            dimension 'tier'
            // You can override the default selection at the product flavor
            // level by configuring another missingDimensionStrategy property
            // for the 'minApi' dimension.
            missingDimensionStrategy 'minApi', 'minApi23', 'minApi18'
        }
        paid {}
    }
}

ज़्यादा जानकारी के लिए, Android Gradle प्लगिन के डीएसएल रेफ़रंस में matchingFallbacks और missingDimensionStrategy देखें.

साइनिंग की सेटिंग कॉन्फ़िगर करना

जब तक इस बिल्ड के लिए साइनिंग कॉन्फ़िगरेशन साफ़ तौर पर तय नहीं किया जाता, तब तक Gradle आपके रिलीज़ बिल्ड के APK या AAB पर हस्ताक्षर नहीं करता. अगर आपके पास अब तक कोई साइनिंग की नहीं है, तो Android Studio का इस्तेमाल करके, अपलोड की और कीस्टोर जनरेट करें.

Gradle बिल्ड कॉन्फ़िगरेशन का इस्तेमाल करके, रिलीज़ बिल्ड टाइप के लिए हस्ताक्षर करने के कॉन्फ़िगरेशन को मैन्युअल तरीके से कॉन्फ़िगर करने के लिए:

  1. कोई कीस्टोर बनाएं. कीस्टोर एक बाइनरी फ़ाइल होती है. इसमें निजी कुंजियों का सेट होता है. आपको अपने कीस्टोर को सुरक्षित जगह पर रखना होगा.
  2. निजी कुंजी बनाएं. निजी कुंजी का इस्तेमाल, ऐप्लिकेशन को डिस्ट्रिब्यूट करने के लिए साइन करने के लिए किया जाता है. इसे कभी भी ऐप्लिकेशन के साथ शामिल नहीं किया जाता. साथ ही, इसे तीसरे पक्ष की उन कंपनियों के साथ शेयर नहीं किया जाता जिनके पास इसे ऐक्सेस करने की अनुमति नहीं है.

  3. मॉड्यूल-लेवल की build.gradle.kts फ़ाइल में, हस्ताक्षर करने का कॉन्फ़िगरेशन जोड़ें:

    Kotlin

    ...
android {
    ...
    defaultConfig {...}
    signingConfigs {
        create("release") {
            storeFile = file("myreleasekey.keystore")
            storePassword = "password"
            keyAlias = "MyReleaseKey"
            keyPassword = "password"
        }
    }
    buildTypes {
        getByName("release") {
            ...
            signingConfig = signingConfigs.getByName("release")
        }
    }
}

    Groovy

    ...
android {
    ...
    defaultConfig {...}
    signingConfigs {
        release {
            storeFile file("myreleasekey.keystore")
            storePassword "password"
            keyAlias "MyReleaseKey"
            keyPassword "password"
        }
    }
    buildTypes {
        release {
            ...
            signingConfig signingConfigs.release
        }
    }
}

ध्यान दें: बिल्ड फ़ाइल में अपनी रिलीज़ कुंजी और कीस्टोर के पासवर्ड शामिल करना, सुरक्षा के लिहाज़ से सही तरीका नहीं है. इसके बजाय, बिल्ड फ़ाइल को कॉन्फ़िगर करें, ताकि वह एनवायरमेंट वैरिएबल से इन पासवर्ड को हासिल कर सके. इसके अलावा, बिल्ड प्रोसेस के दौरान भी इन पासवर्ड के लिए प्रॉम्प्ट किया जा सकता है.

इन पासवर्ड को एनवायरमेंट वैरिएबल से पाने के लिए:

Kotlin

storePassword = System.getenv("KSTOREPWD")
keyPassword = System.getenv("KEYPWD")

Groovy

storePassword System.getenv("KSTOREPWD")
keyPassword System.getenv("KEYPWD")

इसके अलावा, किसी स्थानीय प्रॉपर्टी फ़ाइल से कीस्टोर लोड किया जा सकता है. सुरक्षा से जुड़ी वजहों से, इस फ़ाइल को सोर्स कंट्रोल में न जोड़ें. इसके बजाय, हर डेवलपर के लिए इसे स्थानीय तौर पर सेट अप करें. ज़्यादा जानने के लिए, अपनी बिल्ड फ़ाइलों से हस्ताक्षर करने की जानकारी हटाना लेख पढ़ें.

यह प्रोसेस पूरी करने के बाद, अपने ऐप्लिकेशन को डिस्ट्रिब्यूट किया जा सकता है और Google Play पर पब्लिश किया जा सकता है.

चेतावनी: अपने कीस्टोर और निजी पासकोड को सुरक्षित जगह पर रखें. साथ ही, यह पक्का करें कि आपके पास इनका सुरक्षित बैकअप हो. अगर Play ऐप्लिकेशन साइनिंग का इस्तेमाल किया जाता है और अपलोड पासकोड खो जाता है, तो Play Console का इस्तेमाल करके, अपलोड पासकोड रीसेट करने का अनुरोध किया जा सकता है. अगर आपने Play ऐप्लिकेशन साइनिंग के बिना कोई ऐप्लिकेशन पब्लिश किया है (अगस्त 2021 से पहले बनाए गए ऐप्लिकेशन के लिए) और आपकी ऐप्लिकेशन साइनिंग की खो गई है, तो आपके पास अपने ऐप्लिकेशन के लिए कोई भी अपडेट पब्लिश करने का विकल्प नहीं होगा. ऐसा इसलिए, क्योंकि आपको हमेशा अपने ऐप्लिकेशन के सभी वर्शन को एक ही कुंजी से साइन करना होता है.

Wear OS ऐप्लिकेशन पर हस्ताक्षर करना

Wear OS ऐप्लिकेशन पब्लिश करते समय, स्मार्टवॉच के APK और फ़ोन के वैकल्पिक APK, दोनों पर एक ही कुंजी से हस्ताक्षर किए जाने चाहिए. Wear OS ऐप्लिकेशन को पैकेज करने और उन पर हस्ताक्षर करने के बारे में ज़्यादा जानने के लिए, Wear ऐप्लिकेशन को पैकेज और डिस्ट्रिब्यूट करना लेख पढ़ें.