अगर आप Google Play पर अपना ऐप्लिकेशन प्रकाशित करते हैं, तो आपको Android ऐप्लिकेशन बंडल. ऐसा करने पर, Google Play अपने-आप ऐसा होने पर जनरेट करता है और हर उपयोगकर्ता के डिवाइस कॉन्फ़िगरेशन के हिसाब से ऑप्टिमाइज़ किए गए APKs उपलब्ध कराता है. इसलिए, वे सिर्फ़ ऐसे APK डाउनलोड करते हैं आपका ऐप्लिकेशन चलाने के लिए ज़रूरी कोड और संसाधन शामिल हैं. एक से ज़्यादा APKs पब्लिश करना तब फ़ायदेमंद होता है, जब Google Play पर पब्लिश नहीं किया जा रहा है, लेकिन आपको हर APK को खुद ही बनाना, साइन करना, और मैनेज करना होगा.
Google Play पर एक से ज़्यादा APK का फ़ायदा लेने के लिए, अपना Android ऐप्लिकेशन डेवलप करते समय, शुरू करने से कुछ अच्छे तरीके अपनाने और बेवजह सिर दर्द से बचने की ज़रूरत होती है पूरा करने के लिए डिज़ाइन किया गया है. इस लेसन में, अपने ऐप्लिकेशन के एक से ज़्यादा APKs बनाने का तरीका बताया गया है जिसमें हर ऐप्लिकेशन स्क्रीन साइज़ की एक अलग क्लास को कवर करता है. इसके अलावा, आपको हमारे कुछ ऐसे टूल भी मिलेंगे जो एक से ज़्यादा APK कोडबेस को ज़्यादा से ज़्यादा आसान बनाए रखना होगा.
पुष्टि करें कि आपको एक से ज़्यादा APK की ज़रूरत है
जब कोई ऐसा ऐप्लिकेशन बनाया जाता है जो अलग-अलग साइज़ के Android डिवाइसों पर काम करता है, तो स्वाभाविक है कि आप चाहें कि आपका ऐप्लिकेशन बड़े डिवाइसों पर मौजूद सभी जगह का फ़ायदा ले. साथ ही, यह भी ज़रूरी है कि छोटी स्क्रीन पर ऐप्लिकेशन इस्तेमाल करने में कोई समस्या न आए. शुरुआत में यह इस तरह से लग सकता है हालांकि एकाधिक APK समर्थन बेहतरीन समाधान है, लेकिन अक्सर ऐसा नहीं होता है. एकल APK का इस्तेमाल करना इसके बजाय एक से ज़्यादा APK डेवलपर गाइड के सेक्शन में, APK के लिए एक APK से इसे पूरा करें. इसमें हमारी सहायता लाइब्रेरी का इस्तेमाल भी शामिल है. आपको यह भी पढ़ना चाहिए एक से ज़्यादा स्क्रीन का इस्तेमाल करने के बारे में जानकारी देने वाली गाइड, साथ ही, आपके लिए सहायता लाइब्रेरी भी उपलब्ध है, को Android SDK का इस्तेमाल करके डाउनलोड किया जा सकता है. इससे आपको प्री-हनीकॉम्ब डिवाइस पर फ़्रैगमेंट इस्तेमाल करने की सुविधा मिलती है ( एकाधिक-स्क्रीन समर्थन भी बहुत आसान है).
अगर आप इसे प्रबंधित कर सकते हैं, तो अपने ऐप्लिकेशन को एक APK तक सीमित रखने के कई फ़ायदे हैं, शामिल हैं:
- पब्लिश करना और टेस्ट करना आसान है
- सिर्फ़ एक कोडबेस को मैनेज करना होता है
- आपका ऐप्लिकेशन, डिवाइस के कॉन्फ़िगरेशन में हुए बदलावों के हिसाब से काम कर सकता है
- सभी डिवाइसों पर ऐप्लिकेशन को पहले जैसा करने की सुविधा काम करती है
- आपको मार्केट प्राथमिकता, "अपग्रेड" के व्यवहार के बारे में चिंता करने की आवश्यकता नहीं है एक APK से इसके बाद या कौनसा APK, किस क्लास के डिवाइसों के साथ काम करता है
इस लेसन के बाकी हिस्से में यह माना गया है कि आपने इस विषय पर रिसर्च की है, लिंक किए गए रिसॉर्स में मौजूद कॉन्टेंट को ध्यान से पढ़ा है, और यह तय किया है कि आपके ऐप्लिकेशन के लिए एक से ज़्यादा APK सही हैं.
अपनी ज़रूरी शर्तें चार्ट पर रखें
आपको कितने APK की ज़रूरत है और किस स्क्रीन पर, यह तुरंत तय करने के लिए एक आसान चार्ट बनाकर शुरुआत करें हर APK में साइज़(साइज़) शामिल होता है. अच्छी बात यह है कि अपनी ज़रूरतों को तेज़ी और आसानी से चार्ट में शामिल किया जा सकता है, और बाद में उसका रेफ़रंस दें. अलग-अलग स्क्रीन साइज़ दिखाने वाली सेल की एक पंक्ति से शुरुआत करें Android प्लैटफ़ॉर्म पर उपलब्ध है.
छोटा | सामान्य | बड़ा | xlarge |
अब चार्ट में बस इस तरह रंग भरें कि हर रंग एक APK को दिखाता हो. यहां एक उदाहरण दिया गया है, जिसमें बताया गया है कि हर APK को स्क्रीन साइज़ की किसी खास रेंज पर लागू कर सकता है.
छोटा | सामान्य | बड़ा | xlarge |
आपकी ज़रूरतों के मुताबिक, आपके पास दो APK भी हो सकते हैं, "छोटा और बाकी सब कुछ" या "xबड़ा और बाकी सब कुछ". चार्ट में रंग भरने से, टीम के बीच बातचीत करना भी आसान हो जाता है. अब हर 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 की संभावित सीमा इस तरह दिखेगी:
छोटा | सामान्य | बड़ा | xlarge |
छोटा | सामान्य | बड़ा | xlarge |
छोटा | सामान्य | बड़ा | xlarge |
हालांकि, "अधिकतम वर्शन संख्या जीतता है" का उपयोग करके नियम के तहत, अगर हम versionCode एट्रिब्यूट को लाल ≥ हरा ≥ नीला जैसा हर APK, इस तरह चार्ट को छोटा करके दिखाता है:
छोटा | सामान्य | बड़ा | xlarge |
अब, यह मान लेते हैं कि Red APK में कुछ ज़रूरी शर्तें हैं, जो बाकी दोनों में नहीं हैं. Android डेवलपर गाइड के Google Play पर फ़िल्टर पेज पर, इस तरह की समस्याओं की पूरी सूची दी गई है. उदाहरण के लिए, मान लें कि रेड को फ़्रंट कैमरे की ज़रूरत है. वास्तव में, लाल APK का पूरा बिंदु एक अन्य उपलब्ध स्क्रीन स्पेस हो, ताकि सामने वाले कैमरे से मनोरंजक चीज़ें की जा सकें. हालांकि, हमें पता चलता है कि सभी बड़े डिवाइस में सामने का कैमरा भी नहीं होता! कितना डरावना!
अच्छी बात यह है कि अगर कोई उपयोगकर्ता ऐसे किसी डिवाइस से Google Play ब्राउज़ कर रहा है, तो Google Play को देखते हैं, तो देखते हैं कि Red ने सामने वाले कैमरे को एक आवश्यकता के रूप में सूचीबद्ध कर दिया है और धीरे-धीरे इसे अनदेखा कर देता है, ने यह तय कर लिया है कि रेड और वह डिवाइस डिजिटल स्वर्ग से मेल नहीं खाते हैं. इसके बाद, उसे हरा रंग न सिर्फ़ xlarge डिवाइसों के साथ काम करता है, बल्कि इस बात की भी परवाह नहीं करता कि कोई सामने का कैमरा! उपयोगकर्ता अब भी Google Play से ऐप्लिकेशन डाउनलोड कर सकता है, क्योंकि सामने के कैमरे में गड़बड़ी होने के बावजूद, उस स्क्रीन पर काम करने वाला एक APK मौजूद था साइज़.
अपने सभी 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-screens android:smallScreens="true" android:normalScreens="true" android:largeScreens="true" android:xlargeScreens="true" /> ...
हरा:
<manifest xmlns:android="http://schemas.android.com/apk/res/android" android:versionCode="2001" android:versionName="1.0" package="com.example.foo"> <supports-screens android:smallScreens="false" android:normalScreens="false" android:largeScreens="true" android:xlargeScreens="true" /> ...
लाल:
<manifest xmlns:android="http://schemas.android.com/apk/res/android" android:versionCode="3001" android:versionName="1.0" package="com.example.foo"> <supports-screens android:smallScreens="false" android:normalScreens="false" android:largeScreens="false" android:xlargeScreens="true" /> ...
ध्यान दें कि तकनीकी तौर पर, एक से ज़्यादा APK, supports-screens टैग या compatible-screens टैग में से किसी एक के साथ काम करेंगे. आम तौर पर, सपोर्ट-स्क्रीन को प्राथमिकता दी जाती है. और एक ही मेनिफ़ेस्ट में दोनों टैग का इस्तेमाल करना आम तौर पर खराब आइडिया होता है. इससे चीज़ें ज़रूरत से ज़्यादा मुश्किल हो जाती हैं और गड़बड़ियों की संभावना बढ़ जाती है. यह भी ध्यान रखें कि डिफ़ॉल्ट मानों (छोटी और सामान्य, डिफ़ॉल्ट रूप से हमेशा सही होते हैं), मेनिफ़ेस्ट हर स्क्रीन साइज़. यह आपको आने वाले समय में होने वाली परेशानी से बचा सकता है. उदाहरण के लिए, < का लक्ष्य SDK 9 में xlarge अपने-आप 'गलत' पर सेट हो जाएगा, क्योंकि यह साइज़ अभी मौजूद नहीं है. इसलिए, साफ़ तौर पर जानकारी दें!
अपने ऐप्लिकेशन के लॉन्च से पहले की चेकलिस्ट की समीक्षा करें
Google Play पर अपलोड करने से पहले, इन आइटम की दोबारा जांच करें. याद रखें कि ये खास तौर पर, कई APK के लिए काम का हो. साथ ही, यह किसी भी तरीके से सभी के लिए पूरी चेकलिस्ट नहीं दिखाता हो ऐप्लिकेशन को Google Play पर अपलोड किया जा रहा है.
- सभी APK का पैकेज नाम एक ही होना चाहिए
- सभी APK एक ही सर्टिफ़िकेट से साइन किए जाने चाहिए
- मेनिफ़ेस्ट में 'सही' पर सेट करने के लिए, आपके 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: 'xlarge' supports-any-density: 'true' locales: '--_--' densities: '120' '160' '240'
aapt आउटपुट की जांच करते समय, यह पक्का करें कि आपके पास और साथ में काम करने वाली स्क्रीन, और इसके साथ काम करने वाली स्क्रीन, और इसमें अनजाने में इस्तेमाल होने वाली "इस्तेमाल की सुविधा" वाला कोई विकल्प नहीं है मान जिन्हें मेनिफ़ेस्ट में सेट की गई अनुमतियों की वजह से जोड़ा गया था. ऊपर दिए गए उदाहरण में, 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" />
लॉन्च से पहले की चेकलिस्ट पूरी कर लेने के बाद, अपने APKs Google Play पर अपलोड करें. Google Play को ब्राउज़ करते समय ऐप्लिकेशन को दिखने में कुछ समय लग सकता है. हालांकि, जब यह दिखता है, एक आखिरी चेक करें. ऐप्लिकेशन को उन सभी टेस्ट डिवाइसों पर डाउनलोड करें जिन पर आपको टेस्ट करने की ज़रूरत पड़ सकती है कि APK, सही डिवाइस को टारगेट कर रहा है या नहीं.
Google Play पर एक से ज़्यादा APK प्रकाशित करने के बारे में ज़्यादा जानकारी के लिए, पढ़ें एक से ज़्यादा APK समर्थन.