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

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

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

पुष्टि करें कि आपको एक से ज़्यादा APKs की ज़रूरत है

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

अगर आप इसे प्रबंधित कर सकते हैं, तो अपने ऐप्लिकेशन को एक APK तक सीमित रखने के कई फ़ायदे हैं, जिनमें ये शामिल हैं:

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

इस लेसन के बाकी हिस्से में यह माना जाता है कि आपने इस विषय के बारे में रिसर्च की है, लिंक किए गए संसाधनों में उस विषय के बारे में जानकारी इकट्ठा की है, और यह तय किया है कि आपके ऐप्लिकेशन के लिए एक से ज़्यादा APKs सही रहेंगे.

अपनी ज़रूरी शर्तें चार्ट पर रखें

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

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

3 4 5 6 7 8 9 10 11 12 13 +

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

3 4 5 6 7 8 9 10 11 12 13 +

एक बार जब आप यह चार्ट बना लें, तो इसे अपनी टीम को वितरित करें. आपके प्रोजेक्ट के लिए टीम के साथ बातचीत करना अब और भी आसान हो गया है. अब आपको "एपीआई लेवल 3 से 6 के लिए APK कैसा है, यानी Android 1.x वाला APK कैसा है" पूछने की ज़रूरत नहीं है. क्या हो रहा है?" आप बस इतना कह सकते हैं कि "नीले APK का साथ कैसा है?"

सभी सामान्य कोड और संसाधनों को लाइब्रेरी प्रोजेक्ट में डालना

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

ध्यान दें: लाइब्रेरी प्रोजेक्ट बनाने और उन्हें शामिल करने की जानकारी, इस लेसन में नहीं दी गई है. हालांकि, Android लाइब्रेरी बनाएं लेख को पढ़कर, इसके बारे में ज़्यादा जानकारी पाई जा सकती है.

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

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

नए APK प्रोजेक्ट बनाना

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

alexlucas:~/code/multi-apks-root$ ls
foo-blue
foo-green
foo-lib
foo-red

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

मेनिफ़ेस्ट में बदलाव करें

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

  • मेनिफ़ेस्ट को यह दिखाना होगा कि खास APK को मंज़ूरी दी गई है
  • ज़रूरी शर्तें पूरी करने वाले APK में से, सबसे ज़्यादा वर्शन होने पर जीत मिली

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

3 4 5 6 7 8 9 10 11 12 13 +
3 4 5 6 7 8 9 10 11 12 13 +
3 4 5 6 7 8 9 10 11 12 13 +

हालांकि, यह ज़रूरी होता है कि minSdkVersion ज़्यादा बाद वाले APK का वर्शन कोड भी हो, इसलिए हम जानते हैं कि versionCode की वैल्यू के हिसाब से लाल ≥ हरा ≥ नीला. इसलिए, चार्ट को छोटा करके, हम उसे कुछ इस तरह देख सकते हैं:

3 4 5 6 7 8 9 10 11 12 13 +

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

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

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

नीला: 03001, 03002, 03003, 03004...
हरा: 07001, 07002, 07003, 07004...
लाल:11,001, 11,002, 11,003, 11,004...

इन सभी को एक साथ मिलाकर, आपके Android मेनिफ़ेस्ट कुछ इस तरह दिखेंगे:

नीला:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    android:versionCode="03001" android:versionName="1.0" package="com.example.foo">
    <uses-sdk android:minSdkVersion="3" />
    ...

हरा:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    android:versionCode="07001" android:versionName="1.0" package="com.example.foo">
    <uses-sdk android:minSdkVersion="7" />
    ...

लाल:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    android:versionCode="11001" android:versionName="1.0" package="com.example.foo">
    <uses-sdk android:minSdkVersion="11" />
    ...

अपने ऐप्लिकेशन के लॉन्च से पहले की चेकलिस्ट की समीक्षा करें

Google Play पर अपलोड करने से पहले, इन चीज़ों की दोबारा जांच कर लें. याद रखें कि ये खास तौर पर, एक से ज़्यादा APK के लिए होते हैं. ये किसी भी तरीके से, Google Play पर अपलोड किए जा रहे सभी ऐप्लिकेशन की पूरी चेकलिस्ट नहीं दिखाते हैं.

  • सभी APK का पैकेज नाम एक ही होना चाहिए
  • सभी APK पर एक ही सर्टिफ़िकेट से हस्ताक्षर किया जाना चाहिए
  • अगर APK, प्लैटफ़ॉर्म वर्शन में ओवरलैप करते हैं, तो ज़्यादा minSdkVersion वाले APK का वर्शन कोड भी ज़्यादा होना चाहिए
  • अलग-अलग जानकारी ढूंढने के लिए, मेनिफ़ेस्ट फ़िल्टर दोबारा जांच लें. ऐसा APK जो सिर्फ़ XLARGE स्क्रीन पर कपकेक के साथ काम करता है, इसलिए यह किसी को नहीं दिखेगा
  • हर APK का मेनिफ़ेस्ट, काम करने वाली स्क्रीन, openGL टेक्सचर या प्लैटफ़ॉर्म वर्शन में से कम से कम एक के लिए यूनीक होना चाहिए
  • हर APK को कम से कम एक डिवाइस पर टेस्ट करने की कोशिश करें. इसके अलावा, आपके पास अपनी डेवलपमेंट मशीन पर, कारोबार में सबसे ज़्यादा पसंद के मुताबिक डिवाइस एमुलेटर है. आनंद लें!

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

>aapt dump badging
package: name='com.example.hello' versionCode='1' versionName='1.0'
sdkVersion:'11'
uses-permission:'android.permission.SEND_SMS'
application-label:'Hello'
application-icon-120:'res/drawable-ldpi/icon.png'
application-icon-160:'res/drawable-mdpi/icon.png'
application-icon-240:'res/drawable-hdpi/icon.png'
application: label='Hello' icon='res/drawable-mdpi/icon.png'
launchable-activity: name='com.example.hello.HelloActivity'  label='Hello' icon=''
uses-feature:'android.hardware.telephony'
uses-feature:'android.hardware.touchscreen'
main
supports-screens: 'small' 'normal' 'large' 'xlarge'
supports-any-density: 'true'
locales: '--_--'
densities: '120' '160' '240'

aapt आउटपुट की जांच करते समय, पक्का करें कि आपके पास supports-स्क्रीन और काम करने वाली स्क्रीन के लिए अलग-अलग वैल्यू न हों. साथ ही, यह भी पक्का करें कि आपके पास मेनिफ़ेस्ट में सेट की गई अनुमतियों की वजह से, अनजाने में जोड़ी गई "uses-feature" वाली वैल्यू न हों. ऊपर दिए गए उदाहरण में, APK बहुत सारे डिवाइसों को नहीं दिखेगा.

क्यों? ज़रूरी अनुमति SEND_SMS जोड़ने से, android.hardware.telephony की सुविधा की ज़रूरी शर्त को अपने-आप जोड़ दिया गया. एपीआई 11, Honeycomb (खास तौर पर टैबलेट के लिए ऑप्टिमाइज़ किया गया Android वर्शन) है और किसी भी Honeycomb डिवाइस में टेलीफ़ोनी हार्डवेयर नहीं है. इसलिए, Google Play इस APK को सभी मामलों में फ़िल्टर कर देगा. ऐसा तब तक होगा, जब तक आने वाले समय में, एपीआई लेवल की बेहतर सुविधाओं वाले डिवाइसों में टेलीफ़ोनी हार्डवेयर न हो.

अच्छी बात यह है कि अपने मेनिफ़ेस्ट में इन्हें जोड़कर, इस समस्या को आसानी से ठीक कर दिया जाता है:

<uses-feature android:name="android.hardware.telephony" android:required="false" />

android.hardware.touchscreen की ज़रूरी शर्त भी अपने-आप जुड़ जाती है. अगर आपको अपने APK को टचस्क्रीन वाले डिवाइसों के अलावा, अन्य टीवी पर भी दिखाना है, तो आपको अपने मेनिफ़ेस्ट में ये चीज़ें जोड़नी होंगी:

<uses-feature android:name="android.hardware.touchscreen" android:required="false" />

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

पीछे जाएं
एक से ज़्यादा APK के बारे में जानकारी
आगे बढ़ें
अलग-अलग स्क्रीन साइज़ के हिसाब से कई APK बनाएं