एक से ज़्यादा APK समर्थन

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

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

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

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

अपने ऐप्लिकेशन को एक से ज़्यादा APK के साथ पब्लिश करके, ये काम किए जा सकते हैं:

  • हर APK के साथ, OpenGL टेक्सचर कंप्रेस करने के अलग-अलग फ़ॉर्मैट काम करते हैं.
  • हर APK के साथ अलग-अलग स्क्रीन साइज़ और डेंसिटी के साथ काम करना.
  • हर APK के साथ, डिवाइस की अलग-अलग सुविधाओं के सेट काम करते हैं.
  • हर APK के साथ, प्लैटफ़ॉर्म के अलग-अलग वर्शन काम करते हैं.
  • हर APK के साथ अलग-अलग सीपीयू आर्किटेक्चर के साथ काम करना चाहिए. जैसे, जब आपका ऐप्लिकेशन Android NDK का इस्तेमाल करता है, तो ARM या x86 के लिए.
  • कम सुविधाओं वाले डिवाइसों के लिए ऑप्टिमाइज़ करें, जैसे कि Android (Go वर्शन) पर काम करने वाले डिवाइस.

फ़िलहाल, Google Play पर एक ही ऐप्लिकेशन के तौर पर कई APK पब्लिश करने के लिए, डिवाइस की सिर्फ़ ये विशेषताएं इस्तेमाल की जा सकती हैं.

ध्यान दें: Google Play पर APKs को तैयार करने और पब्लिश करने के बारे में जानने के लिए, रिलीज़ तैयार करना और उन्हें रोल-आउट करना सहायता लेख पढ़ें.

एक से ज़्यादा APK कैसे काम करते हैं

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

  • प्रॉडक्ट की जानकारी (ऐप्लिकेशन की जानकारी, आइकॉन, स्क्रीनशॉट वगैरह) का सिर्फ़ एक सेट बनाए रखा जाता है. इसका मतलब यह भी है कि अलग-अलग APK के लिए, अलग-अलग कीमत नहीं ली जा सकती.
  • सभी उपयोगकर्ताओं को Google Play पर आपके ऐप्लिकेशन का सिर्फ़ एक वर्शन दिखता है. इसलिए, उन्हें "टैबलेट के लिए" या "फ़ोन के लिए" पब्लिश किए गए अलग-अलग वर्शन से भ्रम नहीं होता.
  • उपयोगकर्ताओं की सभी समीक्षाएं, एक ही ऐप्लिकेशन की लिस्टिंग पर लागू होती हैं. भले ही, अलग-अलग डिवाइसों पर उपयोगकर्ताओं के पास अलग-अलग APK हों.
  • अगर आपने Android के अलग-अलग वर्शन (अलग-अलग एपीआई लेवल) के लिए अलग-अलग APK पब्लिश किए हैं, तो जब किसी उपयोगकर्ता के डिवाइस पर सिस्टम अपडेट होता है और वह आपके पब्लिश किए गए किसी दूसरे APK के लिए ज़रूरी शर्तें पूरी करता है, तो Google Play उपयोगकर्ता के ऐप्लिकेशन को Android के नए वर्शन के लिए डिज़ाइन किए गए APK पर अपडेट कर देता है. ऐप्लिकेशन से जुड़ा कोई भी सिस्टम डेटा बरकरार रखा जाता है. यह ठीक वैसा ही है जैसे किसी एक APK का इस्तेमाल करते समय, ऐप्लिकेशन के सामान्य अपडेट के साथ होता है.

इस्तेमाल किए जा सकने वाले फ़िल्टर

यह तय करने के लिए कि कौनसे डिवाइसों को कौनसा APK मिलेगा, Google Play के फ़िल्टर का इस्तेमाल किया जाता है. ये फ़िल्टर, हर APK की मेनिफ़ेस्ट फ़ाइल में मौजूद एलिमेंट से तय किए जाते हैं. हालांकि, Google Play आपको एक से ज़्यादा APK पब्लिश करने की अनुमति सिर्फ़ तब देता है, जब हर APK में डिवाइस की इन विशेषताओं के किसी वैरिएशन के साथ काम करने के लिए फ़िल्टर का इस्तेमाल किया जाता है:

  • OpenGL टेक्सचर कंप्रेस करने के फ़ॉर्मैट

    यह आपकी मेनिफ़ेस्ट फ़ाइल के <supports-gl-texture> एलिमेंट पर आधारित होता है.

    उदाहरण के लिए, OpenGL ES का इस्तेमाल करने वाले गेम को डेवलप करते समय, ATI टेक्स्चर कंप्रेसन की सुविधा वाले डिवाइसों के लिए एक APK और PowerVR कंप्रेसन की सुविधा वाले डिवाइसों के लिए एक अलग APK उपलब्ध कराया जा सकता है.

  • स्क्रीन का साइज़ (और ज़रूरत पड़ने पर, स्क्रीन की डेंसिटी)

    यह आपकी मेनिफ़ेस्ट फ़ाइल के <supports-screens> या <compatible-screens> एलिमेंट पर आधारित होता है. आपको दोनों एलिमेंट का कभी इस्तेमाल नहीं करना चाहिए. साथ ही, जब भी हो सके, सिर्फ़ <supports-screens> का इस्तेमाल करना चाहिए.

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

    सभी स्क्रीन साइज़ के साथ काम करने के लिए, यहां दिए गए सबसे सही तरीके अपनाएं:

    • Android सिस्टम, ऐप्लिकेशन के लिए बेहतर सुविधाएं उपलब्ध कराता है, ताकि वे एक ही APK के साथ सभी स्क्रीन कॉन्फ़िगरेशन के साथ काम कर सकें. अलग-अलग स्क्रीन के साथ काम करने के लिए, आपको एक से ज़्यादा APK बनाने से बचना चाहिए. ऐसा तब तक न करें, जब तक ज़रूरी न हो. इसके बजाय, एक से ज़्यादा स्क्रीन के साथ काम करने के लिए बनी गाइड का पालन करें. इससे आपका ऐप्लिकेशन आसानी से काम कर पाएगा और एक ही APK की मदद से, सभी स्क्रीन कॉन्फ़िगरेशन के साथ काम कर पाएगा.
    • डिफ़ॉल्ट रूप से, <supports-screens> एलिमेंट में स्क्रीन साइज़ के सभी एट्रिब्यूट की वैल्यू "सही" होती है. हालांकि, अगर आपने इन एट्रिब्यूट की वैल्यू को "गलत" के तौर पर सेट नहीं किया है, तो ऐसा होगा. हालांकि, android:xlargeScreens एट्रिब्यूट को Android 2.3 (एपीआई लेवल 9) में जोड़ा गया था. इसलिए, अगर आपका ऐप्लिकेशन android:minSdkVersion या android:targetSdkVersion को "9" या उससे ज़्यादा पर सेट नहीं करता है, तो Google Play यह मान लेगा कि यह "गलत" है.
    • आपको अपनी मेनिफ़ेस्ट फ़ाइल में, <supports-screens> और <compatible-screens>, दोनों एलिमेंट को एक साथ इस्तेमाल नहीं करना चाहिए. दोनों का इस्तेमाल करने से, आपके ऐप्लिकेशन में गड़बड़ी होने की संभावना बढ़ जाती है. ऐसा, दोनों के बीच होने वाले संघर्ष की वजह से होता है. इनमें से किसका इस्तेमाल करना है, यह तय करने के लिए, खास स्क्रीन पर डिस्ट्रिब्यूट करना लेख पढ़ें. अगर आपको दोनों का इस्तेमाल करना है, तो ध्यान रखें कि किसी दिए गए साइज़ के बीच समझौते में किसी भी तरह का विरोध होने पर, "गलत" को प्राथमिकता दी जाएगी.

  • डिवाइस की सुविधाओं के सेट

    यह आपकी मेनिफ़ेस्ट फ़ाइल के <uses-feature> एलिमेंट पर आधारित होता है.

    उदाहरण के लिए, मल्टीटच की सुविधा वाले डिवाइसों के लिए एक APK और मल्टीटच की सुविधा वाले डिवाइसों के लिए एक और APK उपलब्ध कराया जा सकता है. इस प्लैटफ़ॉर्म पर काम करने वाली सुविधाओं की सूची देखने के लिए, सुविधाओं का रेफ़रंस देखें.

  • Android (Go वर्शन)

    Android (Go वर्शन) पर चलने वाले डिवाइसों को टारगेट करने के लिए, आपके APK में <uses-feature android:name="android.hardware.ram.low" android:required="true"> का एलान करना ज़रूरी है. साथ ही, यह भी ज़रूरी है कि वह कम से कम एपीआई लेवल 26 को टारगेट करता हो और उसका वर्शन कोड, Go वर्शन के APK से ज़्यादा हो.

  • एपीआई लेवल

    यह आपकी मेनिफ़ेस्ट फ़ाइल के <uses-sdk> एलिमेंट पर आधारित होता है. एपीआई के अलग-अलग लेवल के लिए सहायता की जानकारी देने के लिए, android:minSdkVersion और android:maxSdkVersion , दोनों एट्रिब्यूट का इस्तेमाल किया जा सकता है.

    उदाहरण के लिए, आपके पास अपने ऐप्लिकेशन को एक ऐसे APK के साथ पब्लिश करने का विकल्प है जो एपीआई लेवल 16 से 19 (Android 4.1.x से 4.4.4) के साथ काम करता है. इसके लिए, एपीआई लेवल 16 या उससे पहले के वर्शन के साथ काम करने वाले एपीआई का इस्तेमाल किया जाता है. इसके अलावा, आपके पास एक और APK के साथ ऐप्लिकेशन को पब्लिश करने का विकल्प है जो एपीआई लेवल 21 और उसके बाद के वर्शन (Android 5.0 और उसके बाद के वर्शन) के साथ काम करता है. इसके लिए, एपीआई लेवल 21 या उससे पहले के वर्शन के साथ काम करने वाले एपीआई का इस्तेमाल किया जाता है. अलग-अलग एपीआई को टारगेट करने वाले अलग-अलग APK बनाने का तरीका जानने के लिए, प्रॉडक्ट फ़्लेवर कॉन्फ़िगर करें पर जाएं.

    अगर कई APK को अलग-अलग करने के लिए, इस विशेषता का इस्तेमाल फ़ैक्टर के तौर पर किया जाता है, तो ज़्यादा android:minSdkVersion वैल्यू वाले APK की android:versionCode वैल्यू भी ज़्यादा होनी चाहिए. यह तब भी लागू होता है, जब दो APK, काम करने वाले किसी दूसरे फ़िल्टर के आधार पर, डिवाइस के लिए उपलब्धता की जानकारी ओवरलैप करते हैं. इससे यह पक्का होता है कि जब किसी डिवाइस पर सिस्टम अपडेट मिलता है, तो Google Play उपयोगकर्ता को आपके ऐप्लिकेशन के लिए अपडेट ऑफ़र कर सकता है. ऐसा इसलिए होता है, क्योंकि अपडेट, ऐप्लिकेशन के वर्शन कोड में बढ़ोतरी पर आधारित होते हैं. इस ज़रूरी शर्त के बारे में ज़्यादा जानकारी, एक से ज़्यादा APK के लिए नियम सेक्शन में दी गई है.

    आम तौर पर, आपको android:maxSdkVersion का इस्तेमाल नहीं करना चाहिए. ऐसा इसलिए, क्योंकि जब तक आपने सार्वजनिक एपीआई की मदद से ऐप्लिकेशन को सही तरीके से डेवलप किया है, तब तक वह Android के आने वाले वर्शन के साथ काम करता रहेगा. अगर आपको एपीआई के ऊंचे लेवल के लिए कोई दूसरा APK पब्लिश करना है, तो भी आपको ज़्यादा से ज़्यादा वर्शन की जानकारी देने की ज़रूरत नहीं है. ऐसा इसलिए, क्योंकि अगर एक APK में android:minSdkVersion का वर्शन "16" और दूसरे में "21" है, तो एपीआई लेवल 21 या उसके बाद के लेवल वाले डिवाइसों को हमेशा दूसरा APK मिलेगा. ऐसा इसलिए, क्योंकि पिछले नोट के मुताबिक, इसका वर्शन कोड ज़्यादा है.


  • सीपीयू आर्किटेक्चर (एबीआई)

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

Google Play फ़िल्टर को चालू करने वाले अन्य मेनिफ़ेस्ट एलिमेंट, अब भी हर APK पर पहले की तरह लागू होते हैं. हालांकि, इन एलिमेंट को ऊपर नहीं बताया गया है. हालांकि, Google Play आपको डिवाइस की उन विशेषताओं के आधार पर अलग-अलग APK पब्लिश करने की अनुमति नहीं देता. इसलिए, अगर ऊपर दिए गए फ़िल्टर हर APK के लिए एक जैसे हैं, तो एक से ज़्यादा APK पब्लिश नहीं किए जा सकते. हालांकि, APK, मेनिफ़ेस्ट या APK में मौजूद अन्य विशेषताओं के आधार पर अलग-अलग होते हैं. उदाहरण के लिए, आपके पास सिर्फ़ <uses-configuration> की विशेषताओं के आधार पर अलग-अलग APK उपलब्ध कराने का विकल्प नहीं है.

एक से ज़्यादा APK के लिए नियम

अपने ऐप्लिकेशन के लिए एक से ज़्यादा APK पब्लिश करने से पहले, आपको ये नियम समझने होंगे:

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

    इसका मतलब है कि हर APK में, ऊपर दिए गए काम करने वाले Google Play फ़िल्टर में से कम से कम एक के लिए, अलग-अलग तरह के सपोर्ट का एलान करना होगा.

    आम तौर पर, किसी खास विशेषता (जैसे, काम करने वाले टेक्सचर कंप्रेस करने के फ़ॉर्मैट) के आधार पर, अपने APKs में अंतर किया जाता है. इसलिए, हर APK में अलग-अलग डिवाइसों के लिए काम करने की जानकारी दी जाएगी. हालांकि, एक से ज़्यादा ऐसे APK पब्लिश किए जा सकते हैं जो एक-दूसरे के साथ ओवरलैप होते हैं. जब दो APK ओवरलैप करते हैं (वे एक ही डिवाइस कॉन्फ़िगरेशन के साथ काम करते हैं), तो उस ओवरलैप रेंज में आने वाले डिवाइस को ज़्यादा वर्शन कोड वाला APK मिलेगा. इस कोड को android:versionCode से तय किया जाता है.

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

    ऐसा सिर्फ़ तब होता है, जब: APK, काम करने वाले एपीआई लेवल के आधार पर सिर्फ़ अलग-अलग हों (काम करने वाले किसी दूसरे फ़िल्टर से APK एक-दूसरे से अलग न हों) या जब APK, काम करने वाले किसी दूसरे फ़िल्टर का इस्तेमाल करते हों, लेकिन उस फ़िल्टर में APK ओवरलैप हों.

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

    ध्यान दें: वर्शन कोड में हुई बढ़ोतरी का साइज़ मायने नहीं रखता. यह ज़रूरी है कि ज़्यादा एपीआई लेवल के साथ काम करने वाले वर्शन में, वर्शन कोड का साइज़ बड़ा हो.

    यहां कुछ उदाहरण दिए गए हैं:

    • अगर आपने एपीआई लेवल 16 और उसके बाद के वर्शन (Android 4.1.x+) के लिए अपलोड किए गए APK का वर्शन कोड 0400 है, तो एपीआई लेवल 21 और उसके बाद के वर्शन (Android 5.0+) के लिए अपलोड किए गए APK का वर्शन कोड 0401 या इससे ज़्यादा होना चाहिए. इस मामले में, एपीआई लेवल ही इस्तेमाल किया जाने वाला एकमात्र फ़िल्टर है. इसलिए, हर APK के लिए एपीआई लेवल के हिसाब से वर्शन कोड बढ़ाना ज़रूरी है, ताकि उपयोगकर्ताओं को सिस्टम अपडेट मिलने पर अपडेट मिल सके.
    • अगर आपके पास एपीआई लेवल 16 (और उसके बाद के वर्शन) और छोटी से बड़ी स्क्रीन के लिए एक APK है और एपीआई लेवल 21 (और उसके बाद के वर्शन) और बड़ी से बड़ी स्क्रीन के लिए एक और APK है, तो एपीआई लेवल के हिसाब से वर्शन कोड बढ़ाने होंगे. इस मामले में, एपीआई लेवल फ़िल्टर का इस्तेमाल, हर APK को अलग-अलग दिखाने के लिए किया जाता है. हालांकि, स्क्रीन साइज़ का भी इस्तेमाल किया जाता है. स्क्रीन के साइज़ ओवरलैप होते हैं, क्योंकि दोनों APK बड़ी स्क्रीन के साथ काम करते हैं. इसलिए, वर्शन कोड अब भी क्रम में होने चाहिए. इससे यह पक्का होता है कि बड़ी स्क्रीन वाले जिस डिवाइस पर एपीआई लेवल 21 का सिस्टम अपडेट मिलेगा उस पर दूसरे APK के लिए भी अपडेट मिलेगा.
    • अगर आपके पास एपीआई लेवल 16 (और उसके बाद के वर्शन) और छोटी - सामान्य स्क्रीन के लिए एक APK है और एपीआई लेवल 21 (और उसके बाद के वर्शन) और बड़ी - बड़ी स्क्रीन के लिए एक और APK है, तो एपीआई लेवल के हिसाब से वर्शन कोड बढ़ाने की ज़रूरत नहीं है. स्क्रीन साइज़ फ़िल्टर में कोई ओवरलैप नहीं है. इसलिए, ऐसे कोई डिवाइस नहीं है जो इन दोनों APK के बीच स्विच कर सकता है. इसलिए, वर्शन कोड को कम एपीआई लेवल से ज़्यादा एपीआई लेवल पर बढ़ाने की ज़रूरत नहीं है.
    • अगर आपके पास एपीआई लेवल 16 (और उसके बाद के वर्शन) और ARMv7 सीपीयू के लिए एक APK है और एपीआई लेवल 21 (और उसके बाद के वर्शन) और ARMv5TE सीपीयू के लिए एक और APK है, तो एपीआई लेवल के हिसाब से वर्शन कोड बढ़ने चाहिए. इस मामले में, हर APK को अलग-अलग दिखाने के लिए, एपीआई लेवल फ़िल्टर का इस्तेमाल किया जाता है. हालांकि, सीपीयू आर्किटेक्चर का भी इस्तेमाल किया जाता है. ARMv5TE लाइब्रेरी वाला APK, ARMv7 सीपीयू वाले डिवाइसों के साथ काम करता है. इसलिए, APK इस विशेषता पर ओवरलैप होते हैं. इसलिए, एपीआई लेवल 21 और उसके बाद के वर्शन के साथ काम करने वाले APK का वर्शन कोड, ज़्यादा होना चाहिए. इससे यह पक्का होता है कि ARMv7 सीपीयू वाले किसी डिवाइस को एपीआई लेवल 21 पर सिस्टम अपडेट मिलने पर, उसे एपीआई लेवल 21 के लिए डिज़ाइन किए गए दूसरे APK का अपडेट मिलेगा. हालांकि, इस तरह के अपडेट की वजह से ARMv7 डिवाइस, ऐसे APK का इस्तेमाल करता है जो उस डिवाइस के सीपीयू के लिए पूरी तरह से ऑप्टिमाइज़ नहीं होता. इसलिए, आपको हर एपीआई लेवल पर ARMv5TE और ARMv7, दोनों आर्किटेक्चर के लिए APK उपलब्ध कराना चाहिए, ताकि हर सीपीयू पर ऐप्लिकेशन की परफ़ॉर्मेंस को ऑप्टिमाइज़ किया जा सके. ध्यान दें: यह शर्त, APKs की तुलना ARMv5TE और ARMv7 लाइब्रेरी से करने पर सिर्फ़ लागू होती है. यह अन्य नेटिव लाइब्रेरी से तुलना करने पर लागू नहीं होती.

ऊपर दिए गए नियमों का पालन न करने पर, APKs चालू करने पर Google Play Console पर गड़बड़ी का मैसेज दिखता है. इस गड़बड़ी को ठीक करने के बाद ही, ऐप्लिकेशन पब्लिश किया जा सकता है.

APKs चालू करने पर, अन्य तरह के विरोध भी हो सकते हैं. हालांकि, इनकी वजह से गड़बड़ियां नहीं, बल्कि चेतावनियां मिलेंगी. चेतावनियां इन वजहों से मिल सकती हैं:

  • जब किसी APK में बदलाव करके, किसी डिवाइस की विशेषताओं के लिए काम करने की सुविधा को "छोटा" किया जाता है और कोई दूसरा APK उन डिवाइसों के साथ काम नहीं करता जो काम करने की सुविधा की तय सीमा से बाहर हैं. उदाहरण के लिए, अगर कोई APK फ़िलहाल छोटी और सामान्य साइज़ की स्क्रीन पर काम करता है और आपने इसे सिर्फ़ छोटी स्क्रीन पर काम करने के लिए बदल दिया है, तो आपने काम करने वाले डिवाइसों के पूल को छोटा कर दिया है. साथ ही, कुछ डिवाइसों पर अब Google Play पर आपका ऐप्लिकेशन नहीं दिखेगा. इस समस्या को हल करने के लिए, सामान्य साइज़ की स्क्रीन पर काम करने वाला कोई दूसरा APK जोड़ें. इससे, पहले जिन डिवाइसों पर ऐप्लिकेशन काम करता था वे अब भी काम करते रहेंगे.
  • जब दो या उससे ज़्यादा APKs के बीच "ओवरलैप" होते हैं. उदाहरण के लिए, अगर कोई APK स्क्रीन के छोटे, सामान्य, और बड़े साइज़ के साथ काम करता है, जबकि कोई दूसरा APK बड़े और बड़े से ज़्यादा साइज़ के साथ काम करता है, तो दोनों APK में ओवरलैप होता है. ऐसा इसलिए होता है, क्योंकि दोनों APK बड़ी स्क्रीन के साथ काम करते हैं. अगर इस समस्या को ठीक नहीं किया जाता है, तो उन डिवाइसों को वह APK मिलेगा जिन पर दोनों APK काम करते हैं. उदाहरण के लिए, बड़ी स्क्रीन वाले डिवाइसों पर सबसे नया वर्शन कोड वाला APK मिलेगा.

    ध्यान दें: अगर अलग-अलग सीपीयू आर्किटेक्चर के लिए अलग-अलग APK बनाए जा रहे हैं, तो ध्यान रखें कि ARMv5TE के लिए बनाया गया APK, ARMv7 के लिए बनाए गए APK के साथ ओवरलैप हो जाएगा. इसका मतलब है कि ARMv5TE के लिए डिज़ाइन किया गया APK, ARMv7 डिवाइस के साथ काम करता है, लेकिन इसके उलट ऐसा नहीं है. सिर्फ़ ARMv7 लाइब्रेरी वाला APK, नहीं ARMv5TE डिवाइस के साथ काम करता है.

जब इस तरह के विरोध होते हैं, तो आपको चेतावनी वाला मैसेज दिखेगा. हालांकि, आपके पास अब भी अपना ऐप्लिकेशन पब्लिश करने का विकल्प होगा.

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

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

सलाह: लाइब्रेरी प्रोजेक्ट का इस्तेमाल करके, अपने ऐप्लिकेशन कोड के बड़े हिस्सों को डुप्लीकेट होने से बचाया जा सकता है. लाइब्रेरी प्रोजेक्ट में शेयर किया गया कोड और संसाधन होते हैं. इन्हें अपने असली ऐप्लिकेशन प्रोजेक्ट में शामिल किया जा सकता है.

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

ध्यान दें: एक ही ऐप्लिकेशन के लिए पब्लिश किए गए सभी APKs का पैकेज नाम एक ही होना चाहिए और उन पर एक ही सर्टिफ़िकेट कुंजी से हस्ताक्षर किए जाने चाहिए. पक्का करें कि आपको एक से ज़्यादा APK के लिए बने सभी नियम भी समझ आ गए हों.

वर्शन कोड असाइन करना

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

वर्शन कोड ऑर्डर करना

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

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

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

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

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

वर्शन कोड स्कीम का इस्तेमाल करना

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

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

हमारा सुझाव है कि आप वर्शन कोड में कम से कम सात अंक इस्तेमाल करें: वर्शन कोड के ऊपरी बिट में, काम करने वाले कॉन्फ़िगरेशन दिखाने वाले पूर्णांक होते हैं. साथ ही, वर्शन का नाम (android:versionName से) निचले बिट में होता है. उदाहरण के लिए, अगर ऐप्लिकेशन के वर्शन का नाम 3.1.0 है, तो एपीआई लेवल 4 वाले APK और एपीआई लेवल 11 वाले APK के वर्शन कोड, क्रमशः 0400310 और 1100310 जैसे होंगे. पहले दो अंक, एपीआई लेवल (क्रमशः 4 और 11) के लिए रिज़र्व हैं. बीच के दो अंक, स्क्रीन साइज़ या GL टेक्सचर फ़ॉर्मैट (इन उदाहरणों में इस्तेमाल नहीं किए गए) के लिए हैं. आखिरी तीन अंक, ऐप्लिकेशन के वर्शन के नाम (3.1.0) के लिए हैं. पहले चित्र में दो उदाहरण दिए गए हैं. ये उदाहरण, प्लैटफ़ॉर्म के वर्शन (एपीआई लेवल) और स्क्रीन साइज़, दोनों के आधार पर अलग-अलग होते हैं.

पहली इमेज. आपके वर्शन कोड के लिए सुझाई गई स्कीम. इसमें एपीआई लेवल के लिए पहले दो अंकों, कम से कम और ज़्यादा से ज़्यादा स्क्रीन साइज़ (1 से 4, चारों साइज़ को दिखाने के लिए) के लिए दूसरे और तीसरे अंकों या टेक्सचर फ़ॉर्मैट को दिखाने के लिए, और ऐप्लिकेशन वर्शन के लिए आखिरी तीन अंकों का इस्तेमाल किया जाता है.

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

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

आगे बढ़ें
अलग-अलग एपीआई लेवल के लिए कई APK बनाएं