एक से ज़्यादा APK बनाएं

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

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

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

एक से ज़्यादा APKs के लिए अपना बिल्ड कॉन्फ़िगर करना

एक से ज़्यादा APK के लिए अपना बिल्ड कॉन्फ़िगर करने के लिए, अपने मॉड्यूल-लेवल की build.gradle फ़ाइल में एक splits ब्लॉक जोड़ें. splits ब्लॉक में, density ब्लॉक दें. इससे यह तय किया जा सकता है कि Gradle को, डिसप्ले डेंसिटी के हिसाब से APK कैसे जनरेट करने हैं. इसके अलावा, abi ब्लॉक की मदद से यह तय किया जा सकता है कि Gradle को, एबीआई के हिसाब से APK कैसे जनरेट करने हैं. आपके पास डेंसिटी और एबीआई, दोनों ब्लॉक देने का विकल्प होता है. साथ ही, बिल्ड सिस्टम हर डेंसिटी और एबीआई कॉम्बिनेशन के लिए एक APK बनाता है.

स्क्रीन डेंसिटी के लिए कई APK कॉन्फ़िगर करना

अलग-अलग स्क्रीन डेंसिटी के लिए अलग-अलग APK बनाने के लिए, अपने splits ब्लॉक में एक density ब्लॉक जोड़ें. अपने density ब्लॉक में, अपनी पसंद के स्क्रीन डेंसिटी और काम करने वाले स्क्रीन साइज़ की सूची दें. काम करने वाले स्क्रीन साइज़ की सूची का इस्तेमाल सिर्फ़ तब करें, जब आपको हर APK के मेनिफ़ेस्ट में खास <compatible-screens> एलिमेंट की ज़रूरत हो.

स्क्रीन डेंसिटी के लिए एक से ज़्यादा APK कॉन्फ़िगर करने के लिए, यहां दिए गए Gradle DSL विकल्पों का इस्तेमाल किया जाता है:

Groovy के लिए enable और Kotlin स्क्रिप्ट के लिए isEnable
अगर इस एलिमेंट को true पर सेट किया जाता है, तो Gradle आपके तय किए गए स्क्रीन डेंसिटी के आधार पर कई APK जनरेट करता है. डिफ़ॉल्ट वैल्यू false है.
exclude
कॉमा लगाकर अलग की गई, उन डेंसिटी की सूची बताता है जिनके लिए आपको Gradle को अलग-अलग APK जनरेट करने की अनुमति नहीं देनी है. exclude का इस्तेमाल तब करें, जब आपको ज़्यादातर डिसप्ले डेंसिटी के लिए APK जनरेट करने हों, लेकिन कुछ डिसप्ले डेंसिटी को बाहर रखना हो जिन पर आपका ऐप्लिकेशन काम नहीं करता.
reset()

स्क्रीन डेंसिटी की डिफ़ॉल्ट सूची मिटाता है. सिर्फ़ तब इस्तेमाल करें, जब आपको जो घनत्व जोड़ने हैं उन्हें बताने के लिए, include एलिमेंट के साथ जोड़ा जाए.

नीचे दिया गया स्निपेट, सूची को खाली करने के लिए reset() को कॉल करके, घनत्व की सूची को सिर्फ़ ldpi और xxhdpi पर सेट करता है. इसके बाद, include का इस्तेमाल करता है:

reset()                  // Clears the default list from all densities
                         // to no densities.
include "ldpi", "xxhdpi" // Specifies the two densities to generate APKs
                         // for.
include
डिवाइस की स्क्रीन डेंसिटी की सूची, कॉमा लगाकर अलग की गई हो. आपको जिन डेंसिटी के लिए Gradle से APK जनरेट कराना है उनकी सूची दें. घनत्व की सटीक सूची तय करने के लिए, सिर्फ़ reset() के साथ इस्तेमाल करें.
compatibleScreens

इस एट्रिब्यूट की वैल्यू, कॉमा लगाकर अलग किए गए स्क्रीन साइज़ की सूची होती है. इससे, हर APK के लिए मेनिफ़ेस्ट में मैच करने वाला <compatible-screens> नोड इंजेक्ट होता है.

इस सेटिंग की मदद से, एक ही build.gradle सेक्शन में स्क्रीन डेंसिटी और स्क्रीन साइज़, दोनों को आसानी से मैनेज किया जा सकता है. हालांकि, <compatible-screens> का इस्तेमाल करने पर, हो सकता है कि आपका ऐप्लिकेशन कुछ डिवाइसों पर काम न करे. अलग-अलग स्क्रीन साइज़ के साथ काम करने के अन्य तरीकों के बारे में जानने के लिए, स्क्रीन के साथ काम करने की खास जानकारी देखें.

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

यहां दिए गए उदाहरण में, ldpi, xxhdpi, और xxxhdpi को छोड़कर, हर स्क्रीन डेंसिटी के लिए एक अलग APK जनरेट किया गया है. ऐसा करने के लिए, exclude का इस्तेमाल करके, उन तीन डेंसिटी को सभी डेंसिटी की डिफ़ॉल्ट सूची से हटाएं.

Groovy

android {
  ...
  splits {

    // Configures multiple APKs based on screen density.
    density {

      // Configures multiple APKs based on screen density.
      enable true

      // Specifies a list of screen densities you don't want Gradle to create multiple APKs for.
      exclude "ldpi", "xxhdpi", "xxxhdpi"

      // Specifies a list of compatible screen size settings for the manifest.
      compatibleScreens 'small', 'normal', 'large', 'xlarge'
    }
  }
}

Kotlin

android {
    ...
    splits {

        // Configures multiple APKs based on screen density.
        density {

            // Configures multiple APKs based on screen density.
            isEnable = true

            // Specifies a list of screen densities you don't want Gradle to create multiple APKs for.
            exclude("ldpi", "xxhdpi", "xxxhdpi")

            // Specifies a list of compatible screen size settings for the manifest.
            compatibleScreens("small", "normal", "large", "xlarge")
        }
    }
}

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

एबीआई के लिए एक से ज़्यादा APK कॉन्फ़िगर करना

अलग-अलग एबीआई के लिए अलग-अलग APK बनाने के लिए, अपने splits ब्लॉक में एक abi ब्लॉक जोड़ें. अपने abi ब्लॉक में, अपनी पसंद के एबीआई की सूची दें.

हर एबीआई के लिए एक से ज़्यादा APK कॉन्फ़िगर करने के लिए, Gradle DSL के इन विकल्पों का इस्तेमाल किया जाता है:

Groovy के लिए enable या Kotlin स्क्रिप्ट के लिए isEnable
अगर इस एलिमेंट को true पर सेट किया जाता है, तो Gradle आपके तय किए गए एबीआई के आधार पर कई APK जनरेट करता है. डिफ़ॉल्ट वैल्यू false है.
exclude
कॉमा लगाकर अलग की गई उन एबीआई की सूची बताता है जिनके लिए आपको Gradle से अलग-अलग APK जनरेट नहीं कराना है. अगर आपको ज़्यादातर एबीआई के लिए APK जनरेट करने हैं, लेकिन कुछ ऐसे एबीआई को बाहर रखना है जिन पर आपका ऐप्लिकेशन काम नहीं करता, तो exclude का इस्तेमाल करें.
reset()

एबीआई की डिफ़ॉल्ट सूची मिटाता है. सिर्फ़ तब इस्तेमाल करें, जब आपको जोड़ने के लिए एबीआई तय करने के लिए, include एलिमेंट के साथ जोड़ा जाए.

नीचे दिया गया स्निपेट, एबीआई की सूची को सिर्फ़ x86 और x86_64 पर सेट करता है. इसके लिए, सूची को हटाने के लिए reset() को कॉल किया जाता है और फिर include का इस्तेमाल किया जाता है:

reset()                 // Clears the default list from all ABIs to no ABIs.
include "x86", "x86_64" // Specifies the two ABIs we want to generate APKs for.
include
कॉमा लगाकर अलग की गई उन एबीआई की सूची बताता है जिनके लिए आपको Gradle से APK जनरेट करने हैं. एबीआई की सटीक सूची बताने के लिए, सिर्फ़ reset() के साथ इस्तेमाल करें.
Groovy के लिए universalApk या Kotlin स्क्रिप्ट के लिए isUniversalApk

अगर true है, तो Gradle हर एबीआई के लिए APK के साथ-साथ एक यूनिवर्सल APK भी जनरेट करता है. यूनिवर्सल APK में, एक ही APK में सभी एबीआई के लिए कोड और संसाधन होते हैं. डिफ़ॉल्ट वैल्यू false है.

ध्यान दें कि यह विकल्प सिर्फ़ splits.abi ब्लॉक में उपलब्ध है. स्क्रीन की सघनता के आधार पर एक से ज़्यादा APK बनाते समय, Gradle हमेशा एक यूनिवर्सल APK जनरेट करता है. इसमें सभी स्क्रीन सघनताओं के लिए कोड और संसाधन शामिल होते हैं.

यहां दिए गए उदाहरण में, हर एबीआई के लिए एक अलग APK जनरेट किया जाता है: x86 और x86_64. ऐसा करने के लिए, एबीआई की खाली सूची के साथ reset() का इस्तेमाल करें. इसके बाद, एबीआई की उस सूची के साथ include का इस्तेमाल करें जिसमें हर एबीआई के लिए एक APK है.

Groovy

android {
  ...
  splits {

    // Configures multiple APKs based on ABI.
    abi {

      // Enables building multiple APKs per ABI.
      enable true

      // By default all ABIs are included, so use reset() and include to specify that you only
      // want APKs for x86 and x86_64.

      // Resets the list of ABIs for Gradle to create APKs for to none.
      reset()

      // Specifies a list of ABIs for Gradle to create APKs for.
      include "x86", "x86_64"

      // Specifies that you don't want to also generate a universal APK that includes all ABIs.
      universalApk false
    }
  }
}

Kotlin

android {
  ...
  splits {

    // Configures multiple APKs based on ABI.
    abi {

      // Enables building multiple APKs per ABI.
      isEnable = true

      // By default all ABIs are included, so use reset() and include to specify that you only
      // want APKs for x86 and x86_64.

      // Resets the list of ABIs for Gradle to create APKs for to none.
      reset()

      // Specifies a list of ABIs for Gradle to create APKs for.
      include("x86", "x86_64")

      // Specifies that you don't want to also generate a universal APK that includes all ABIs.
      isUniversalApk = false
    }
  }
}

काम करने वाले एबीआई की सूची देखने के लिए, काम करने वाले एबीआई पर जाएं.

बिना नेटिव/C++ कोड वाले प्रोजेक्ट

बिना नेटिव/C++ कोड वाले प्रोजेक्ट के लिए, बिल्ड वैरिएंट पैनल में दो कॉलम होते हैं: मॉड्यूल और चालू बिल्ड वैरिएंट, जैसा कि पहले चित्र में दिखाया गया है.

बिल्ड वैरिएंट पैनल
पहली इमेज. वैरिएंट बनाएं पैनल में, बिना नेटिव/C++ कोड वाले प्रोजेक्ट के लिए दो कॉलम होते हैं.

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

नेटिव/C++ कोड वाले प्रोजेक्ट

नेटिव/C++ कोड वाले प्रोजेक्ट के लिए, बिल्ड वैरिएंट पैनल में तीन कॉलम होते हैं: मॉड्यूल, चालू बिल्ड वैरिएंट, और चालू एबीआई, जैसा कि दूसरे चित्र में दिखाया गया है.

दूसरी इमेज. बिल्ड वैरिएंट पैनल, नेटिव/C++ कोड वाले प्रोजेक्ट के लिए ऐक्टिव एबीआई कॉलम जोड़ता है.

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

बिल्ड टाइप या एबीआई बदलने के लिए:

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

किसी ऐप्लिकेशन या लाइब्रेरी मॉड्यूल के लिए किसी भी कॉलम में बदलाव करने पर, वह बदलाव उन सभी लाइनों पर लागू हो जाता है जिनमें उस कॉलम का इस्तेमाल किया गया है.

वर्शन कॉन्फ़िगर करना

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

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

नीचे दिए गए उदाहरण में, x86 ABI के APK को 2004 का versionCode और x86_64 ABI के APK को 3004 का versionCode मिलता है.

वर्शन कोड को 1, 000 जैसे बड़े अंतराल में असाइन करने पर, आपको बाद में यूनीक वर्शन कोड असाइन करने की सुविधा मिलती है. उदाहरण के लिए, अगर किसी अगले अपडेट में defaultConfig.versionCode को 5 पर सेट किया जाता है, तो Gradle x86 APK को 2005 का versionCode और x86_64 APK को 3005 का वर्शन कोड असाइन करता है.

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

Groovy

android {
  ...
  defaultConfig {
    ...
    versionCode 4
  }
  splits {
    ...
  }
}

// Map for the version code that gives each ABI a value.
ext.abiCodes = ['armeabi-v7a':1, x86:2, x86_64:3]

// For per-density APKs, create a similar map:
// ext.densityCodes = ['mdpi': 1, 'hdpi': 2, 'xhdpi': 3]

import com.android.build.OutputFile

// For each APK output variant, override versionCode with a combination of
// ext.abiCodes * 1000 + variant.versionCode. In this example, variant.versionCode
// is equal to defaultConfig.versionCode. If you configure product flavors that
// define their own versionCode, variant.versionCode uses that value instead.
android.applicationVariants.all { variant ->

  // Assigns a different version code for each output APK
  // other than the universal APK.
  variant.outputs.each { output ->

    // Stores the value of ext.abiCodes that is associated with the ABI for this variant.
    def baseAbiVersionCode =
            // Determines the ABI for this variant and returns the mapped value.
            project.ext.abiCodes.get(output.getFilter(OutputFile.ABI))

    // Because abiCodes.get() returns null for ABIs that are not mapped by ext.abiCodes,
    // the following code doesn't override the version code for universal APKs.
    // However, because you want universal APKs to have the lowest version code,
    // this outcome is desirable.
    if (baseAbiVersionCode != null) {

      // Assigns the new version code to versionCodeOverride, which changes the
      // version code for only the output APK, not for the variant itself. Skipping
      // this step causes Gradle to use the value of variant.versionCode for the APK.
      output.versionCodeOverride =
              baseAbiVersionCode * 1000 + variant.versionCode
    }
  }
}

Kotlin

android {
  ...
  defaultConfig {
    ...
    versionCode = 4
  }
  splits {
    ...
  }
}

// Map for the version code that gives each ABI a value.
val abiCodes = mapOf("armeabi-v7a" to 1, "x86" to 2, "x86_64" to 3)

// For per-density APKs, create a similar map:
// val densityCodes = mapOf("mdpi" to 1, "hdpi" to 2, "xhdpi" to 3)

import com.android.build.api.variant.FilterConfiguration.FilterType.*

// For each APK output variant, override versionCode with a combination of
// abiCodes * 1000 + variant.versionCode. In this example, variant.versionCode
// is equal to defaultConfig.versionCode. If you configure product flavors that
// define their own versionCode, variant.versionCode uses that value instead.
androidComponents {
    onVariants { variant ->

        // Assigns a different version code for each output APK
        // other than the universal APK.
        variant.outputs.forEach { output ->
            val name = output.filters.find { it.filterType == ABI }?.identifier

            // Stores the value of abiCodes that is associated with the ABI for this variant.
            val baseAbiCode = abiCodes[name]
            // Because abiCodes.get() returns null for ABIs that are not mapped by ext.abiCodes,
            // the following code doesn't override the version code for universal APKs.
            // However, because you want universal APKs to have the lowest version code,
            // this outcome is desirable.
            if (baseAbiCode != null) {
                // Assigns the new version code to output.versionCode, which changes the version code
                // for only the output APK, not for the variant itself.
                output.versionCode.set(baseAbiCode * 1000 + (output.versionCode.get() ?: 0))
            }
        }
    }
}

वर्शन कोड की अन्य स्कीम के ज़्यादा उदाहरणों के लिए, वर्शन कोड असाइन करना देखें.

एक से ज़्यादा APK बनाना

एक से ज़्यादा APK बनाने के लिए, मॉड्यूल-लेवल की build.gradle या build.gradle.kts फ़ाइल को कॉन्फ़िगर करने के बाद, प्रोजेक्ट पैनल में, चुने गए मौजूदा मॉड्यूल के लिए सभी APK बनाने के लिए, बिल्ड करें > APK बनाएं पर क्लिक करें. Gradle, प्रोजेक्ट की build/outputs/apk/ डायरेक्ट्री में हर डेंसिटी या एबीआई के लिए APK बनाता है.

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

उदाहरण के लिए, यहां दिया गया build.gradle स्निपेट, mdpi और hdpi डेंसिटी के लिए एक से ज़्यादा APK बनाने की सुविधा देता है. साथ ही, x86 और x86_64 एबीआई के लिए भी ऐसा किया जा सकता है:

Groovy

...
  splits {
    density {
      enable true
      reset()
      include "mdpi", "hdpi"
    }
    abi {
      enable true
      reset()
      include "x86", "x86_64"
    }
  }

Kotlin

...
  splits {
    density {
      isEnable = true
      reset()
      include("mdpi", "hdpi")
    }
    abi {
      isEnable = true
      reset()
      include("x86", "x86_64")
    }
  }

उदाहरण के तौर पर दिए गए कॉन्फ़िगरेशन के आउटपुट में ये चार APK शामिल हैं:

  • app-hdpiX86-release.apk: इसमें hdpi डेंसिटी और x86 एबीआई के लिए कोड और संसाधन शामिल होते हैं.
  • app-hdpiX86_64-release.apk: इसमें hdpi डेंसिटी और x86_64 एबीआई के लिए कोड और संसाधन शामिल होते हैं.
  • app-mdpiX86-release.apk: इसमें mdpi डेंसिटी और x86 एबीआई के लिए कोड और संसाधन शामिल होते हैं.
  • app-mdpiX86_64-release.apk: इसमें mdpi डेंसिटी और x86_64 एबीआई के लिए कोड और संसाधन शामिल होते हैं.

स्क्रीन डेंसिटी के आधार पर एक से ज़्यादा APK बनाते समय, Gradle हमेशा एक यूनिवर्सल APK जनरेट करता है. इसमें हर डेंसिटी के लिए APK के साथ-साथ, सभी डेंसिटी के लिए कोड और संसाधन शामिल होते हैं.

एबीआई के आधार पर एक से ज़्यादा APK बनाते समय, Gradle सिर्फ़ एक ऐसा APK जनरेट करता है जिसमें सभी एबीआई के लिए कोड और संसाधन शामिल होते हैं. ऐसा तब होता है, जब आपने अपनी build.gradle फ़ाइल (Groovy के लिए) के splits.abi ब्लॉक में universalApk true या अपनी build.gradle.kts फ़ाइल (Kotlin स्क्रिप्ट के लिए) के splits.abi ब्लॉक में isUniversalApk = true डाला हो.

APK फ़ाइल के नाम का फ़ॉर्मैट

एक से ज़्यादा APK बनाते समय, Gradle इस स्कीम का इस्तेमाल करके APK फ़ाइल के नाम जनरेट करता है:

modulename-screendensityABI-buildvariant.apk

इस योजना के कॉम्पोनेंट ये हैं:

modulename
यह उस मॉड्यूल का नाम बताता है जिसे बनाया जा रहा है.
screendensity
अगर स्क्रीन की डेंसिटी के लिए एक से ज़्यादा APK चालू हैं, तो APK के लिए स्क्रीन की डेंसिटी बताता है, जैसे कि mdpi.
ABI

अगर एबीआई के लिए एक से ज़्यादा APK चालू हैं, तो APK के लिए एबीआई तय करें, जैसे कि x86.

अगर स्क्रीन डेंसिटी और एबीआई, दोनों के लिए एक से ज़्यादा APK चालू हैं, तो Gradle, डेंसिटी के नाम को एबीआई के नाम के साथ जोड़ देता है. उदाहरण के लिए, mdpiX86. अगर हर एबीआई के लिए universalApk चालू है, तो Gradle, यूनिवर्सल APK फ़ाइल के नाम के एबीआई हिस्से के तौर पर universal का इस्तेमाल करता है.

buildvariant
इससे पता चलता है कि कौनसा बिल्ड वैरिएंट बनाया जा रहा है, जैसे कि debug.

उदाहरण के लिए, myApp के डिबग वर्शन के लिए mdpi स्क्रीन डेंसिटी APK बनाते समय, APK फ़ाइल का नाम myApp-mdpi-debug.apk होता है. myApp के रिलीज़ वर्शन को mdpi स्क्रीन डेंसिटी और x86 एबीआई, दोनों के लिए एक से ज़्यादा APK बनाने के लिए कॉन्फ़िगर किया गया है. इस वर्शन के APK का फ़ाइल नाम myApp-mdpiX86-release.apk है.