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

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

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

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

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

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

android में बिल्ड टाइप बनाए और कॉन्फ़िगर किए जा सकते हैं मॉड्यूल-लेवल की build.gradle.kts फ़ाइल का ब्लॉक. बनाने पर एक नया मॉड्यूल है, तो 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"
        }
    }
}

ग्रूवी

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 को आपके कॉन्फ़िगरेशन में किसी भी गड़बड़ी का पता चलता है, समस्या के बारे में बताने के लिए, मैसेज विंडो दिखती है.

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

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

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

ध्यान दें: आपको अब भी इसका इस्तेमाल करके पैकेज का नाम तय करना होगा package एट्रिब्यूट की वैल्यू सबमिट करें.main/ आपको वह तरीका भी इस्तेमाल करना चाहिए 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" नाम का एक फ़्लेवर डाइमेंशन बनाता है और जोड़ता है "डेमो" और "पूरा" हो सकता है अलग-अलग फ़्लेवर का इस्तेमाल करें. इन फ़्लेवर की अपनी खासियत है 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"
        }
    }
}

ग्रूवी

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"
        }
    }
}

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

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

  • demoDebug
  • demoRelease
  • fullDebug
  • fullRelease

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

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

जब अपने ऐप्लिकेशन के लिए कोई APK या एएबी बनाया जाता है, तो बिल्ड टूल, ऐप्लिकेशन को 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"
        }
    }
}

ग्रूवी

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

इस प्रकार, "free" प्रॉडक्ट फ़्लेवर यह है "com.example.myapp.free" का इस्तेमाल करें.

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

Kotlin

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

ग्रूवी

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

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

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

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

फ़्लेवर डाइमेंशन की मदद से, कई तरह के प्रॉडक्ट के फ़्लेवर जोड़ें

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

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

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

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"
      ...
    }
  }
}
...

ग्रूवी

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 और उससे ऊपर के लेवल का इस्तेमाल करना है ऐप का वर्शन है. Google आपके यूआरएल पैरामीटर को कैसे इस्तेमाल करेगा, यह तय करने के लिए बिल्ड के सभी वैरिएंट को फ़िल्टर करने के लिए, variantFilter को ब्लॉक करें "minApi21" को जोड़ने वाले कॉन्फ़िगरेशन और "डेमो" प्रॉडक्ट फ़्लेवर:

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
        }
    }
}
...

ग्रूवी

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 उन सभी बिल्ड वैरिएंट को अनदेखा करता है जो पूरा होते हैं शर्तों को पूरा करने की ज़रूरत नहीं है. बिल्ड के वैरिएंट अब मेन्यू में नहीं दिखते जब आप बिल्ड > मेन्यू बार से बिल्ड वैरिएंट चुनें या वैरिएंट बनाएं टूल विंडो बार पर क्लिक करें.

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

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

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

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

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

------------------------------------------------------------
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. टूल विंडो बार में, Gredle पर क्लिक करें.

  2. MyApplication > टास्क > android और sourceSets पर दो बार क्लिक करें.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

नीचे दिया गया कोड सैंपल, 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")
      ...
  }
}
...

ग्रूवी

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 मॉड्यूल बनाता है. यह मॉड्यूल, Android Studio पर काम नहीं कर सकता डुप्लीकेट कॉन्टेंट रूट की ज़रूरत होती है.

सोर्स सेट के साथ बनाएं

अपने हिसाब से कोड और संसाधन शामिल करने के लिए, सोर्स सेट डायरेक्ट्री का इस्तेमाल किया जा सकता है कुछ खास कॉन्फ़िगरेशन के साथ ही पैकेज किया जाना चाहिए. उदाहरण के लिए, अगर आपको "डेमोडीबग" बनाना बिल्ड वैरिएंट है, जो "डेमो" प्रॉडक्ट फ़्लेवर और "डीबग" बिल्ड टाइप, 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 के अलग-अलग वर्शन चाहिए बिल्ड टाइप अलग-अलग हो, तो हर बिल्ड टाइप में फ़ाइल को अपलोड करें और उसे 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.5.1")
}

ग्रूवी

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.5.1'
}

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

वैरिएंट-अवेयर डिपेंडेंसी मैनेजमेंट का इस्तेमाल करें

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

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

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

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

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

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

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

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

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

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

    दिए गए बिल्ड टाइप के लिए वैकल्पिक मिलान तय करने के लिए 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")
        }
    }
}

    ग्रूवी

    // 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")
        }
    }
}

    ग्रूवी

    // 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" के लिए फ़्लेवर शामिल होते हैं डाइमेंशन, लेकिन आपका ऐप्लिकेशन इसमें सिर्फ़ "टीयर" के फ़्लेवर शामिल होते हैं डाइमेंशन. जब आप "freeDebug" बनाना हो आपके ऐप्लिकेशन का एक वर्शन है, तो प्लगिन को यह नहीं पता कि "minApi23Debug" का इस्तेमाल करना है या नहीं या "minApi18डीबग" इस डिपेंडेंसी का वर्शन हो.

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

    यह बताने के लिए, 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") {}
    }
}

    ग्रूवी

    // 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 {}
    }
}

ज़्यादा जानकारी के लिए, matchingFallbacks देखें और missingDimensionStrategy देखें.

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

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

रिलीज़ के बिल्ड टाइप के लिए, साइनिंग कॉन्फ़िगरेशन को मैन्युअल तरीके से कॉन्फ़िगर करने के लिए 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")
        }
    }
}

    ग्रूवी

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

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

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

Kotlin

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

ग्रूवी

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

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

इस प्रोसेस को पूरा करने के बाद, अपने ऐप्लिकेशन को लोगों तक पहुंचाया जा सकता है और उसे पब्लिश किया जा सकता है Google Play पर उपलब्ध है.

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

Wear OS ऐप्लिकेशन पर साइन किया जा रहा है

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