अलग-अलग एपीआई लेवल के लिए कई 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 काम करता है, इस बारे में चिंता करने की ज़रूरत नहीं है

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

अपनी ज़रूरतों को चार्ट में दिखाना

सबसे पहले एक आसान चार्ट बनाएं. इससे आपको यह तय करने में मदद मिलेगी कि आपको कितने APKs बनाने हैं और हर APK में कौनसी API रेंज शामिल करनी है. 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 कैसा है" पूछने की ज़रूरत नहीं है. क्या हो रहा है?" इसके लिए, "Blue 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 चुन लिया जाता है

उदाहरण के लिए, पहले बताए गए कई APKs के सेट को लेते हैं और मान लें कि हमने किसी भी 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 ने फ़्रंट-फ़ेसिंग कैमरे को ज़रूरी शर्त के तौर पर शामिल किया है. इसके बाद, Google Play इस शर्त को अनदेखा कर देगा. इससे यह पता चलेगा कि Red और उस डिवाइस के बीच कोई मैच नहीं है. इसके बाद, यह पता चलेगा कि ग्रीन, एपीआई 11 वाले डिवाइसों के साथ फ़ॉरवर्ड-कंपैटिबल है. ऐसा इसलिए है, क्योंकि maxSdkVersion की कोई वैल्यू तय नहीं की गई है. साथ ही, यह इस बात से भी कोई फ़र्क़ नहीं पड़ता कि डिवाइस में फ़्रंट कैमरा है या नहीं! उपयोगकर्ता अब भी Google Play से ऐप्लिकेशन डाउनलोड कर सकता है. ऐसा इसलिए, क्योंकि फ़्रंट कैमरे से जुड़ी समस्या के बावजूद, अब भी एक ऐसा APK मौजूद है जो उस खास एपीआई लेवल के साथ काम करता है.

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

नीला: 03001, 03002, 03003, 03004...
हरा: 07001, 07002, 07003, 07004...
लाल:11001, 11002, 11003, 11004...

इन सभी को एक साथ जोड़ने पर, आपके 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 स्क्रीन पर Cupcake वर्शन के साथ इस्तेमाल किया जा सकता है, उसे कोई नहीं देख पाएगा
  • हर 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 आउटपुट की जांच करते समय, पक्का करें कि आपके पास स्क्रीन के साथ काम करने की सुविधा और काम करने वाली स्क्रीन के लिए, एक-दूसरे से मेल न खाने वाली वैल्यू न हों. साथ ही, आपके पास ऐसी "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" />

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

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