अलग-अलग GL टेक्सचर के लिए एक से ज़्यादा APK बनाना

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

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

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

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

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

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

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

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

Android डेवलपर गाइड में, supports-gl-texture पेज पर, काम करने वाले सामान्य टेक्सचर के बारे में आसानी से जानकारी मिलती है. इस पेज पर, यह जानकारी भी दी गई है कि कौनसे फ़ोन (या फ़ोन की फ़ैमिली) पर खास टेक्स्चर फ़ॉर्मैट काम करते हैं. ध्यान दें कि आपके किसी एक APK के लिए ETC1 काम करना चाहिए, तो आम तौर पर यह अच्छा आइडिया होता है. ऐसा इसलिए, क्योंकि Android पर चलने वाले ऐसे सभी डिवाइस टेक्सचर फ़ॉर्मैट पर काम करते हैं जो OpenGL ES 2.0 स्पेसिफ़िकेशन के साथ काम करते हैं.

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

ETC1 एटीआई पावरवीआर

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

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

चाहे आप किसी मौजूदा 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 से ऐसा ऐप्लिकेशन डाउनलोड करता है जो एक से ज़्यादा APKs का इस्तेमाल करता है, तो इस्तेमाल करने के लिए सही APK को कुछ आसान नियमों के हिसाब से चुना जाता है:

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

जीएल टेक्सचर के लिए, आखिरी नियम अहम है. इसका मतलब है कि आपको एक ही ऐप्लिकेशन में अलग-अलग जीएल फ़ॉर्मैट इस्तेमाल करते समय बहुत सावधानी बरतनी चाहिए. अगर आपको 99% समय तक PowerVR का इस्तेमाल करना है, लेकिन स्प्लैश स्क्रीन के लिए ETC1 का इस्तेमाल करना है, तो... इसका मतलब है कि आपका मेनिफ़ेस्ट दोनों फ़ॉर्मैट पर काम करता है. अगर किसी डिवाइस पर सिर्फ़ ETC1 काम करता है, तो उसे काम करने वाला डिवाइस माना जाएगा. आपका ऐप्लिकेशन डाउनलोड हो जाएगा और उपयोगकर्ता को क्रैश से जुड़े कुछ मैसेज दिखेंगे. आम तौर पर, अगर GL टेक्स्चर के साथ काम करने वाले अलग-अलग डिवाइसों को टारगेट करने के लिए, कई APK का इस्तेमाल किया जा रहा है, तो हर APK के लिए एक टेक्स्चर फ़ॉर्मैट होगा.

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

उदाहरण के लिए, कुछ डिवाइसों को चुनें और देखें कि पहले से तय किए गए कितने APK, हर डिवाइस पर काम करते हैं.

FooPhone Nexus S Evo
ETC1 ETC1 ETC1
पावरवीआर ATI TC

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

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

नीला: 1001, 1002, 1003, 1004...
हरा: 2001, 2002, 2003, 2004...
लाल:3001, 3002, 3003, 3004...

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

नीला:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    android:versionCode="1001" android:versionName="1.0" package="com.example.foo">
    <supports-gl-texture android:name="GL_OES_compressed_ETC1_RGB8_texture" />
    ...

हरा:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    android:versionCode="2001" android:versionName="1.0" package="com.example.foo">
    <supports-gl-texture android:name="GL_AMD_compressed_ATC_texture" />
    ...

लाल:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    android:versionCode="3001" android:versionName="1.0" package="com.example.foo">
    <supports-gl-texture android:name="GL_IMG_texture_compression_pvrtc" />
    ...

प्री-लॉन्च चेकलिस्ट की समीक्षा करना

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

  • सभी APK का पैकेज नाम एक ही होना चाहिए
  • सभी 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: 'xlarge'
supports-any-density: 'true'
locales: '--_--'
densities: '120' '160' '240'

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

क्यों? ज़रूरी अनुमति SEND_SMS जोड़ने से, android.hardware.telephony की सुविधा की ज़रूरी शर्त को अपने-आप जोड़ दिया गया. ज़्यादातर (अगर सभी नहीं) बड़े डिवाइस टैबलेट होते हैं, जिनमें टेलीफ़ोन हार्डवेयर नहीं होता. ऐसे में, 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" />

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