कई डाइमेंशन वाले कई APK बनाना

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

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

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

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

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

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

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

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

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

3 4 5 6 7 8 9 10 11 12 +
छोटा
सामान्य
बड़ा
xlarge

ऊपर चार APK का एक उदाहरण है. नीला, सभी छोटे/सामान्य स्क्रीन वाले डिवाइसों के लिए, और हरा रंग बड़े साइज़ के लिए लाल रंग का इस्तेमाल कर सकते हैं. लाल रंग, बड़ी स्क्रीन वाले डिवाइस के लिए है. इन सभी की एपीआई रेंज 3 से 10 तक होती है. बैंगनी रंग का इस्तेमाल करने का एक अलग तरीका है. यह सभी स्क्रीन साइज़ के लिए है, लेकिन सिर्फ़ एपीआई 11 और उसके बाद के वर्शन के लिए. सबसे अहम बात यह है कि इस चार्ट को एक नज़र में देखकर, आपको तुरंत पता चल जाता है कि कौनसा APK किसी दिए गए एपीआई/स्क्रीन साइज़ कॉम्बिनेशन को कवर करता है. इसके अलावा, हर एक के लिए आपके पास शानदार कोडनेम भी होते हैं. ऐसा इसलिए, क्योंकि "क्या हमने पर लाल रंग की जांच की है?" पूछना, "क्या हमने Xoom के लिए 3 से 10 xlarge APK की जांच की है?" पूछने के मुकाबले काफ़ी आसान है. इस चार्ट को प्रिंट करके, अपने कोडबेस पर काम करने वाले हर व्यक्ति को दें. ज़िंदगी अब बहुत आसान हो गई है.

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

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

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

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

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

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

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

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

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

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

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

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

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

3 4 5 6 7 8 9 10 11 12 +
छोटा
सामान्य
बड़ा
xlarge

चूंकि कवरेज के लिए ओवरलैप होना ठीक है, इसलिए हम प्रत्येक APK द्वारा कवर किए गए क्षेत्र का वर्णन कर सकते हैं, जैसे इसलिए:

  • सभी स्क्रीन पर नीले रंग का कवर दिखता है, minSDK 3.
  • ग्रीन, बड़ी स्क्रीन और उसके बाद के वर्शन के लिए है. साथ ही, इसके लिए minSDK 3 की ज़रूरत होती है.
  • लाल रंग, XLarge स्क्रीन (आम तौर पर टैबलेट) और 9 के मिनिमम SDK को कवर करता है.
  • बैंगनी रंग की स्क्रीन, सभी स्क्रीन को कवर करती है, minSDK का 11 वर्शन.

ध्यान दें कि उन नियमों में बहुत ज़्यादा ओवरलैप नहीं हैं. उदाहरण के लिए, एपीआई 11 वाला X बड़ा डिवाइस, इन चार APK में से किसी भी एक को चला सकता है. हालांकि, "सबसे ज़्यादा वर्शन नंबर वाला वर्शन जीतता है" नियम का इस्तेमाल करके, हम प्राथमिकता का क्रम इस तरह से सेट कर सकते हैं:

बैंगनी ≥ लाल ≥ हरा ≥ नीला

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

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

अपने सभी APK को अलग-अलग "ट्रैक" पर रखने के लिए, ज़रूरी है कि आपके पास एक अच्छा वर्शन कोड हो स्कीम. सुझाया गया तरीका, इसके वर्शन कोड क्षेत्र पर देखा जा सकता है हमारी डेवलपर गाइड देखें. पूरा सेक्शन पढ़ना ठीक है, लेकिन बुनियादी जानकारी APKs के लिए, हम minSDK को दिखाने के लिए दो अंकों का इस्तेमाल करेंगे, दो अंकों से कम से कम/ज़्यादा से ज़्यादा स्क्रीन साइज़ को दिखाएंगे और बिल्ड नंबर दिखाने के लिए. इस तरह, जब डिवाइस Android के नए वर्शन में अपग्रेड हुआ, (जैसे, 10 से 11 तक), ऐसे APK के लिए जो अब ज़रूरी शर्तें पूरी करते हैं और जिन्हें फ़िलहाल इंस्टॉल किए गए APK के मुकाबले प्राथमिकता दी जाती है को डिवाइस में "अपग्रेड" के रूप में दिखेगा. वर्शन नंबर स्कीम, जब उदाहरण पर लागू की गई हो सेट किया जाता है, तो वह ऐसा दिख सकता है:

नीला: 0304001, 0304002, 0304003...
हरा: 0334001, 0334002, 0334003
लाल: 0344001, 0344002, 0344003...
बैंगनी: 1104001, 1104002, 1104003...

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

नीला:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    android:versionCode="0304001" android:versionName="1.0" package="com.example.foo">
    <uses-sdk android:minSdkVersion="3" />
    <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="0334001" android:versionName="1.0" package="com.example.foo">
    <uses-sdk android:minSdkVersion="3" />
    <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="0344001" android:versionName="1.0" package="com.example.foo">
    <uses-sdk android:minSdkVersion="3" />
    <supports-screens android:smallScreens="false"
        android:normalScreens="false"
        android:largeScreens="false"
        android:xlargeScreens="true" />
    ...

बैंगनी:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    android:versionCode="1104001" android:versionName="1.0" package="com.example.foo">
    <uses-sdk android:minSdkVersion="11" />
    <supports-screens android:smallScreens="true"
        android:normalScreens="true"
        android:largeScreens="true"
        android:xlargeScreens="true" />
    ...

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

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

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

  • सभी APK का पैकेज नाम एक ही होना चाहिए.
  • सभी APK एक ही सर्टिफ़िकेट से साइन किए जाने चाहिए.
  • अगर प्लैटफ़ॉर्म वर्शन में APK ओवरलैप करते हैं, तो सबसे ज़्यादा minSdkVersion वाले 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 आउटपुट की जांच करते समय, यह पक्का करें कि आपके पास और साथ में काम करने वाली स्क्रीन, और इसके साथ काम करने वाली स्क्रीन, और इसमें अनजाने में इस्तेमाल होने वाली "इस्तेमाल की सुविधा" वाला कोई विकल्प नहीं है मान जिन्हें मेनिफ़ेस्ट में सेट की गई अनुमतियों की वजह से जोड़ा गया था. ऊपर दिए गए उदाहरण में, 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, टारगेट किए गए डिवाइसों को टारगेट कर रहे हैं. बधाई हो, आपने कर दिखाया!

पीछे जाएं
अलग-अलग GL टेक्सचर के लिए कई APK बनाएं
आगे बढ़ें
अलग-अलग भाषाओं और संस्कृतियों के हिसाब से बनाना