कई डाइमेंशन वाले कई 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 के लिए एक अलग 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 के लिए ज़रूरी है.
  • लाल रंग में Xबड़ी स्क्रीन (आम तौर पर, टैबलेट) के लिए 9 का minSDK का इस्तेमाल किया जाता है.
  • बैंगनी रंग की स्क्रीन, सभी स्क्रीन को कवर करती है, 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 में मौजूद कपकेक को कोई नहीं देख सकता)
  • हर 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 सही डिवाइस को टारगेट कर रहा है. बधाई हो, आपने कर दिखाया!

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