Godot: Android निर्यात के भविष्य पर

मैं प्रस्ताव 2 के लिए वोट करता हूं।

अगर हम एपीके निर्यात तंत्र को फिर से सक्रिय करने के बारे में बात कर रहे हैं तो मुझे लगता है कि यह जानना महत्वपूर्ण हो सकता है कि गोडोट इंजन कौन सी सुविधा गायब है:

1. APK गतिशील सामग्री : एक लाइटर उत्पन्न करने की अनुमति APK
2. Google झटपट ऐप : उपयोगकर्ता आपका गेम/ऐप इंस्टॉल किए बिना खेल सकता है
3. अनुकूली आइकन : नवीनतम Android (Android P, और कुछ Android 7.1+) को अनुकूली आइकन की आवश्यकता होती है।
4. क्रैशिंग हैंडलर: गोडोट इंजन में क्रैशिंग एपीआई नहीं है। मतलब जब गोडोट इंजन क्रैश हो जाता है, तो हमें एक फ़ंक्शन को उजागर करना चाहिए जिससे उपयोगकर्ता इसे अपने पसंदीदा क्रैश-एनालिटिक्स एप्लिकेशन पर भेज सकें
5. ANR अब क्रैश हो गया है , इसलिए जब गेम शुरू हो रहा है, तो हमें UIThread के बजाय AsyncTask का उपयोग करना चाहिए।

जबकि हम निर्यात तंत्र को फिर से तैयार कर रहे हैं, हमें उन सुविधाओं को गोडोट इंजन में भी जोड़ना चाहिए।

मेरा वोट => 2

शायद एक संकर?
यदि डिबग मोड में परीक्षण के लिए sdk नहीं मिलता है, लेकिन रिलीज़ पैकेज के लिए SDK की स्थापना की आवश्यकता है, तो पुराने दृष्टिकोण का उपयोग करें। यदि एसडीके पाया जाता है, तो इसे डीबग और रिलीज मोड में उपयोग करें।
मैं 2 वोट देता हूं, क्योंकि अगर आप एंड्रॉइड में काम कर रहे हैं तो हमेशा एक आवश्यकता होती है।

@xsellier मैं इस तर्क के बिंदु की सराहना करता हूं कि ओपी में जो प्रस्तावित किया गया था, उससे आगे नहीं जाता है, अगर कोई आपके द्वारा उल्लेख किए गए

@HeartoLazor बनाए रखने के लिए कम कोड बेहतर imo है, इसलिए यदि # 2 के लिए जाना है, तो हाइब्रिड एक बुरा विचार है।

मैं प्रस्ताव 2 के लिए भी वोट करता हूं।

एक बार एंड्रॉइड टूलिंग सेट करने के बाद बहुत सारे काम बहुत दर्द रहित हो जाते हैं, जैसे कि नए एसडीके डाउनलोड करना और बाहरी लिबास बनाना।

साथ ही तीसरे पक्ष के पुस्तकालयों को जोड़ना आसान होगा।

मैं विकल्प 2 . के लिए वोट करता हूं

विकल्प 2 बहुत अधिक सुविधाजनक लगता है। ग्रैडल एक महान उपकरण है, पुस्तकालयों को जोड़ना और निर्माण प्रक्रिया का प्रबंधन करना वर्तमान प्रवाह की तुलना में बहुत आसान है।

मेरा वोट प्रस्ताव 2 के लिए है

मैंने एक बार 2.x . के लिए एक ऐडऑन के रूप में एक एंड्रॉइड टेम्पलेट निर्माता बनाया था
https://github.com/vinod8990/godot-addon-aetc

हालांकि मैं प्रस्ताव 2 के लिए वोट करता हूं।
यदि हम एक मानक बनाते हैं, तो यह सुनिश्चित करने की आवश्यकता है कि एक मॉड्यूल भी एपीआई को हटा दें। यह एक बहुत बड़ा पीआईए है जब हमें एक देशी प्लगइन को हटाने की आवश्यकता होती है (जैसा कि एकता के मामले में)।

वोट -> प्रस्ताव 2: यह सबसे तार्किक विकल्प की तरह लगता है, गोडोट वर्तमान में और निकट भविष्य में मोबाइल विकास के लिए सबसे अच्छा गेम इंजन है और जब एंड्रॉइड और मोबाइल प्लेटफॉर्म पर निर्यात करने की बात आती है तो बेहतर एडमोब/टूल्स एकीकरण जरूरी है।

क्या इसका मतलब यह भी है कि आईओएस निर्यात में भी सुधार होगा। कम से कम निकट भविष्य में।

प्रोपसल 2 के लिए वोट करें: कुछ पुस्तकालय एकीकरण को एप्लिकेशन विशिष्ट फाइलों के साथ एपीके के पुनर्निर्माण के लिए आवश्यक है जैसे कि फायरबेस के लिए google-services.json या फेसबुक एपीआई के लिए स्ट्रिंग्स.एक्सएमएल अनुकूलन। गोडोट 2 पर, मेरे पास कुछ lib को ठीक से एकीकृत करने के लिए SConstruct/SCsub/methods.py और कुछ टेम्पलेट फ़ाइल पैच थे।

ऐसा लगता है कि यहां ज्यादातर समझौता है .. तो मुझे लगता है कि एपीके हैकिंग को दूर जाना होगा, और ग्रैडल चलाने से पहले निर्यात टेम्पलेट एंड्रॉइड निर्देशिका में काफी अधिक होना चाहिए ..

विकल्प #2 के लिए कोई प्रस्ताव या पीआर करने के लिए तैयार है? :)

खैर इस समय मुझे शेयर और Admob मॉड्यूल को जोड़ने में बहुत दर्द हुआ है, क्योंकि इस समय बनावट से get_data विधि में एक बग है, इसलिए संकलन के बाद और आप हार जाते हैं।

इसके अलावा मेरे पास जावा, ग्रेडल और अन्य सभी को एक साथ काम करने के लिए एक विशिष्ट कॉन्फ़िगरेशन होना चाहिए जो ठीक है लेकिन कठिन है।

यह भी जानना कि कौन सी शेडर विधियां उपलब्ध हैं और अधिक तरल भौतिकी बहुत अच्छी होगी क्योंकि मुझे साधारण वेगों को लागू करने के बजाय स्थिति बदलने के लिए कई चीजों को फिर से लिखना होगा क्योंकि कुछ मुद्दे जो 3.1 में बदल जाएंगे, इसलिए एंड्रॉइड पर युक्तियों वाला एक पृष्ठ होगा भी एक अच्छा कदम हो।

तो एंड्रॉइड के लिए अनुकूलन के लिए कुछ चेकबॉक्स के साथ # 2 बहुत अच्छा होगा।

बेशक मैं इस सभी निर्यात वातावरण को बनाने के प्रयास की सराहना करता हूं।

नंबर 2 साफ-सुथरा लगता है इसलिए मुझे लगता है कि यह हैक पर काम करने से बेहतर है जो भविष्य में समस्याएं ला सकता है।
मेरी एकमात्र चिंता तैनाती का समय है। वर्तमान में एंड्रॉइड पर परीक्षण वास्तव में तेज़ है, यह मूल रूप से इस बात पर निर्भर करता है कि आपकी संपत्ति कितनी बड़ी है। क्या विकल्प 2 निर्माण समय को गंभीर रूप से प्रभावित करेगा?
किसी भी मामले में मुझे अभी भी लगता है कि यह जाने का रास्ता है। यह परीक्षण के लिए दृश्य/स्क्रिप्ट सिंकिंग पर अधिक निर्भर होने की बात होगी।

प्रस्ताव 2 बहुत बेहतर है क्योंकि Google Play को हमेशा अपने नवीनतम Android SDK के साथ एपीके बनाने की आवश्यकता होती है।

और GDnative भी दर्द होता है जब मैं तीसरे पक्ष के आईएपी और अमेज़ॅन, लीडबॉल्ट इत्यादि के विज्ञापनों के साथ एकीकृत करने का प्रयास करता हूं।

प्रस्ताव २ निश्चित रूप से।

कॉर्डोवा और फ़्लटर जैसी कुछ बड़ी परियोजनाओं में पहले से ही इसी तरह के दृष्टिकोण का उपयोग किया जाता है। यदि उपयोगकर्ता एपीके निर्माण पर अधिक नियंत्रण रखना चाहता है तो एंड्रॉइड स्टूडियो में प्रोजेक्ट खोलने की संभावना एक बढ़िया विकल्प होगा।

विकल्प 2 बाकी गोडोट की तरह साफ और अधिक लगता है ... यानी ठीक से किया गया।

मैं एंड्रॉइड एक्सपोर्ट को काम पर लाने के दर्द से गुजरा। सबसे अधिक दर्द सही (संस्करण) उपकरण स्थापित हो रहा था; गोडोट में कॉन्फ़िगर करना आसान था।
मेरी पुस्तक में, यदि इसे सही तरीके से करने में समान मात्रा में दर्द शामिल है तो सही उपकरण स्थापित करना अभी भी सही दिशा में एक कदम है, इसलिए मैं # 2 के लिए भी वोट करता हूं।
मैं डिबगिंग के लिए एंड्रॉइड पर लॉन्च करने की गति के बारे में चिंताओं को साझा करता हूं, लेकिन अगर मैं अंत में स्टोर पर रिलीज नहीं कर सकता तो यह एक बड़ा मुद्दा है जिसे संबोधित करने की आवश्यकता है; मुझे यह जानने की जरूरत है कि जब मैं रिलीज करने के लिए तैयार हूं तो स्टोर उपलब्ध होगा।

निश्चित रूप से # 2 :)

मैं विकल्प 2 के लिए हूं - एंड्रॉइड एसडीके स्थापित करना कोई समस्या नहीं है, और यह कई अन्य संभावनाओं को खोलता है।

उच्च स्तर पर, यह फ़्लटर के काम करने के तरीके के समान लगता है, https://github.com/flutter/buildroot

क्या विकल्प #2 का अर्थ है कि हमें प्रत्येक प्रोजेक्ट के लिए हर बार एक एंड्रॉइड एपीके फ़ाइल निर्यात करने के लिए पूरे इंजन को सी ++ और जावा कोड शामिल करना होगा?

यह एक आपदा होगी! Cocos Creator ऐसे भयानक कार्यप्रवाह का उपयोग करता है।

@Geequlim अगर मैं सही समझता हूं, सी ++ नहीं बल्कि java.

मैं विकल्प # 1 के लिए हूं। जब मैं कुछ प्रयोग करता हूं या वर्कफ़्लो डीबग करता हूं। मैं एक छोटे प्रोजेक्ट को डीबग करने के लिए ऐसा एंड्रॉइड बंडल नहीं चाहता हूं। हैक रास्ता रखें। प्रोगैमर को एसडीके वर्कफ़्लो करने दें।

@Geequlim हाँ, यह मेरी भी चिंता है। अगर परियोजना को हर बार एक एपीके में पुन: संकलित और पैक करने की आवश्यकता होती है तो मुझे लगता है कि इसमें काफी समय लगेगा।

@Geequlim @JFonS पूर्ण

@ veloc1 हमें अभी भी एसेट लिब से टेस्ट डेमो के लिए प्रत्येक प्रोजेक्ट इवेंट के लिए होल इंजन को संकलित करना है?

ग्रेडेल बिल्ड वर्कफ़्लो कई कारणों से टूट सकता है：

• गलत संस्करण एसडीके स्थापित।
• निर्भरता को खराब नेटवर्क कनेक्शन के साथ डाउनलोड नहीं किया जा सकता है (जो वास्तव में चीन में प्रॉक्सी के बिना होता है)।
• मशीन की उपलब्ध मेमोरी 4GB से कम है लेकिन कुछ तृतीय-पक्ष SDK को संकलन करने के लिए multiDexEnabled true को सक्षम करना होगा।
• ...

और ग्रेडेल हमेशा अपेक्षित रूप से पुन: संकलित नहीं होता है।

शायद मैं गलत हूँ, लेकिन मुझे लगता है कि #1 एक गिलास दूध है और #2 एक डेयरी गाय है। क्या मैं सही हूँ?

@Geequlim जैसा कि मैं कल्पना कर सकता हूं, हमें वास्तव में पूरे इंजन को पुन:
इस तरह हम निर्माण समय, स्मृति उपयोग को कम कर सकते हैं और एंड्रॉइड प्रोजेक्ट की सादगी में सुधार कर सकते हैं।

लेकिन आप सही कह रहे हैं, इसमें बहुत सी सीमाएँ भी शामिल हैं।

और संभावित रूप से टूटी हुई चीजों की आपकी सूची में कुछ टिप्पणियां:

• एसडीके ज्यादा भूमिका नहीं निभाता है, क्योंकि गोडोट इंजन नए एसडीके से बहुत सारी सुविधाओं का उपयोग नहीं करता है। साधारण परियोजनाओं के लिए लगभग कोई भी एसडीके ठीक रहेगा। साथ ही, उपयुक्त sdk को डाउनलोड करना स्वचालित किया जा सकता है।
• निर्भरता की समस्या, जिसका आपने वर्णन किया है, एक दर्द हो सकता है। हम मावेन से लिंक के साथ निर्भरता शामिल कर सकते हैं, लेकिन हम प्रोजेक्ट फ़ोल्डर में लाइब्रेरी फाइलें (जार या आर) भी डाल सकते हैं, और निर्भरता का उपयोग कर सकते हैं, इसलिए खराब नेटवर्क कनेक्शन के साथ आप अन्य जगहों पर सभी निर्भरताओं को डाउनलोड कर सकते हैं, उन्हें यूएसबी स्टिक पर रख सकते हैं और स्थानांतरित कर सकते हैं अनुमान लगाना। लेकिन निर्यात दस्तावेज़ीकरण में इसका बहुत वर्णन किया जाना चाहिए।
• मल्टीडेक्स और मेमोरी एक दूसरे को प्रभावित नहीं करते हैं। मल्टीडेक्स को हमेशा टेम्प्लेट प्रोजेक्ट में सक्षम किया जा सकता है। स्मृति एक मजबूत सीमा होगी। मैं ठीक-ठीक यह नहीं कह सकता कि उसके लिए कितनी मात्रा में उपलब्ध मेमोरी की आवश्यकता होगी, लेकिन यह 2GB से अधिक होनी चाहिए।

और गोडोट में लागू किए जाने वाले परिवर्तनों का एक आवरण है (जिस तरह से, मैंने ऊपर वर्णित किया है):

• एंड्रॉइड लाइब्रेरी बनाएं, जिसमें इंजन और प्लगइन सिस्टम हो। (यह कठिन है)
• रिलीज पर एंड्रॉइड लाइब्रेरी का निर्माण स्वचालित करें और इसे मेवेन पर रखें।
• Android प्रोजेक्ट टेम्प्लेट बनाएं।
• पर्यावरण को मान्य करने के लिए स्क्रिप्ट का एक सेट एकत्र करें, ग्रैडल, जावा, एंड्रॉइड एसडीके डाउनलोड करें
• गोडोट इंजन में बदलाव करें, इसलिए जब उपयोगकर्ता एंड्रॉइड डिवाइस पर प्रोजेक्ट चलाता है, तो इंजन को सभी संसाधनों की प्रतिलिपि बनानी चाहिए और प्रोजेक्ट बनाने और चलाने के लिए ग्रैडल टास्क को कॉल करना चाहिए।
• सभी चीजों के लिए दस्तावेज।

@गीकुलिम

क्या विकल्प #2 का अर्थ है कि हमें प्रत्येक प्रोजेक्ट के लिए हर बार एक एंड्रॉइड एपीके फ़ाइल निर्यात करने के लिए पूरे इंजन को सी ++ और जावा कोड शामिल करना होगा?

नहीं.. मैं वास्तव में इसका कोई कारण नहीं देखता। अब यह मामला है, लेकिन नए वर्कफ़्लो को केवल पूर्व-निर्मित स्थिति में (Godot .so फ़ाइलों के साथ) Android प्रोजेक्ट मिलेगा। अन्य निर्देशिकाओं (जैसे, Admob) में आपके द्वारा डाउनलोड किए गए बाहरी मॉड्यूल को जोड़ना ग्रैडल के साथ वास्तव में आसान है, इसलिए आप सैद्धांतिक रूप से उस समर्थन को संपत्ति पुस्तकालय से डाउनलोड कर सकते हैं और यह जादुई रूप से काम करेगा।

@veloc1

वहाँ _is_ पहले से ही एक प्लगइन सिस्टम है जो सामान जोड़ने के लिए ग्रैडल बिल्ड को संशोधित करता है, जिसके लिए सबसे अधिक संभावना नहीं या थोड़े बदलाव की आवश्यकता होगी।

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

इसी तरह, मुझे लगता है कि गोडोट निर्माण से पहले AndroidManifest.xml में आवश्यक संपादन कर सकता है (नाम बदलें, अनुमतियां और अन्य सामान जोड़ें), आइकन जोड़ें, आदि उन उपयोगकर्ताओं पर इसे आसान बनाने के लिए जो अभी भी मैनिफेस्ट के काम करने के अनुकूल नहीं हो सकते हैं। अच्छी बात यह है कि यह गैर-विनाशकारी तरीके से किया जाता है, इसलिए आप अभी भी मेनिफेस्ट में अपना सामान जोड़ सकते हैं।

@reduz

मुझे यकीन नहीं था कि हस्ताक्षर गोडोट की तरफ होना चाहिए। ग्रैडल के लिए एंड्रॉइड प्लगइन में उस https://developer.android.com/studio/build/build-variants#signing के लिए बहुत अच्छी सुविधा है, इसलिए निर्यात पर हम केवल कीस्टोर और पासवर्ड की जांच करते हैं, और ग्रैडल सभी काम करते हैं।

और मैनिफेस्ट के लिए। जब मैं प्लगइन सिस्टम के बारे में कहता हूं, मेरा मतलब ठीक उसी चीज से है: प्रत्येक प्लगइन अनुमतियों की घोषणा करता है, और निर्यात पर हम सभी शामिल प्लगइन्स एकत्र करते हैं और AndroidManifest.xml उत्पन्न करते हैं। साथ ही, इस तरह हम लाइब्रेरी सर्विसेज और ब्रॉडकास्ट रिसीवर्स को शामिल कर सकते हैं।

नाम और आइकन जैसे संसाधनों के लिए - प्लेसहोल्डर संसाधनों के बारे में क्या है, और जब प्रोजेक्ट सेटिंग्स में कॉन्फ़िगर किया जाता है, तो बस प्लेसहोल्डर को प्रोजेक्ट सेटिंग्स के मानों से बदलें? तो, अंतिम उपयोगकर्ताओं को यह सब भयानक एंड्रॉइड चीजें बिल्कुल नहीं दिखाई देंगी।

क्या नए निर्यात वर्कफ़्लो के साथ गेम पैक को फिर से ज़िप किए जाने के बजाय APK के बाहर रखना संभव होगा (फ़ोल्डर या .pck)?

@LinuxUserGD उसके लिए Apk Expansion (.obb) नहीं है?
यह पहले से ही है।

हम जो कुछ भी करते हैं, वह लचीला होना चाहिए और यह सुनिश्चित करने की आवश्यकता है कि यह एकता के तरीके की तरह नहीं है। यह एक गड़बड़ है जब हम कई प्लगइन्स को मिलाते हैं और मेल खाते हैं जिनमें समान निर्भरताएं होती हैं।

मैनिफेस्ट के लिए, मैं इसे मैन्युअल रूप से संपादन योग्य भी रखना चाहता हूं।

वर्तमान निर्माण बहुत लचीला है कि मैं टेम्पलेट को संपादित कर सकता हूं और जो कुछ भी चाहता हूं उसे जोड़/हटा सकता हूं और टेम्पलेट बनाने में कुछ भी हस्तक्षेप नहीं करेगा।

मुझे लगता है कि हाइब्रिड सिस्टम जैसा कुछ काम करेगा?

निःसंदेह प्रस्ताव 2 बेहतर, स्वच्छ और अधिक "उचित" लगता है।
@reduz प्रस्ताव 2 का विपक्ष? मुझे लगता है कि यह केवल एक परेशानी है जब तेज़ इंटरनेट उपलब्ध नहीं है।
एंड्रॉइड स्टूडियो की तरह गोडोट शायद बहुत आसानी से (एक टेक्स्ट फ़ाइल के रूप में?) एसडीकेमैनगर को https://developer.android.com/studio/command-line/sdkmanager डाउनलोड करने के लिए आवश्यक पैकेजों की एक सूची पास कर सकता है।

प्रस्ताव २, निश्चित रूप से।

प्रस्ताव #2। एंड्रॉइड एसडीके इंस्टॉलेशन आजकल काफी आसान है!

@reduz , मैं प्रस्ताव 2 के लिए मतदान कर रहा हूं। लेकिन, कृपया #18141 के बारे में मत भूलना

प्रस्ताव 2. ग्रैडल भी प्रलेखित है इसलिए हमारे पास और संसाधन होंगे। अधिकांश मोबाइल देवों के पास वैसे भी उनके सिस्टम पर कहीं न कहीं एंड्रॉइड एसडीके स्थापित होगा।

प्रस्ताव २

यह कब लागू होगा, कोई जानकारी या कुछ भी
@ akien-mga क्या यह अभी भी 3.1 के लिए मील का पत्थर है?

23 नवंबर, 2018 से godotengine.org/news के इस ब्लॉगपोस्ट के अनुसार:

गोडोट 3.1 एक ऐसी रिलीज़ होगी जो हमारे उपयोगकर्ताओं की अपेक्षा के बहुत व्यापक सतह क्षेत्र को कवर करती है, इसलिए हमें अब नई सुविधाओं की उतनी आवश्यकता नहीं है। 3.1 के बाद नियोजित एकमात्र बड़ी सुविधा वल्कन को प्रतिपादन पोर्ट कर रही है ...

ऐसा लगता है कि वर्तमान मुद्दे की विशेषता ने 3.2 के लिए विचार करने के लिए पर्याप्त ध्यान आकर्षित किया है। क्या कोई कारण है कि इसे ब्लॉगपोस्ट में क्यों नहीं जोड़ा गया?

Android निर्यात के एक बड़े रिफ्लेक्टर के लिए हमारे पास समय समाप्त हो गया है, इसलिए यह 3.2 के लिए होगा।

चूंकि एंड्रॉइड विभिन्न प्रकार के तीसरे पक्ष के प्लगइन्स और डेटाबेस (फायरबेस, क्लाउड, एमएल,) प्रदान करता है, ऐसा लगता है कि निरंतर विकास के लिए एंड्रॉइड एसडीके/जेडीके/एनडीके स्थापित करना एक अच्छा विचार है। इसका कारण यह है कि एंड्रॉइड पुस्तकालय संस्करणों के साथ बदलते हैं शायद कुछ निर्भरता पुस्तकालय गायब हैं जब निर्यात एसडीके के उचित संस्करण के बिना किया जाता है। लेकिन इसके विपरीत इस दृष्टिकोण के लिए उपयोगकर्ता या अंतिम डेवलपर को पूरे उत्पाद को एंड्रॉइड प्लेटफॉर्म पर केवल परीक्षण के लिए शिप करने की आवश्यकता होती है जो समय के ऊपर की ओर जाता है एंड्रॉइड के लिए एक एप्लिकेशन बनाने की तरह एक वैकल्पिक दृष्टिकोण किया जा सकता है जो परीक्षण के लिए डिवाइस पर एंड्रॉइड स्टूडियो एसडीके और जेडीके का उपयोग करता है। उपयोगकर्ता केवल केबल पोर्ट के साथ कंप्यूटर से एप्लिकेशन कनेक्ट कर सकता है और फिर गेम को चला सकता है गोडोट संपादक स्वयं और फोन या मोबाइल पर परिवर्तन देखें। मोबाइल अपने पोर्ट के माध्यम से कंप्यूटर के एंड्रॉइड एसडीके का उपयोग करता है और जहां तक ​​​​प्रस्ताव 1 का संबंध है, समय का थोड़ा ओवरहेड है और लगभग पारदर्शी भी है, हैकिंग की आवश्यकता नहीं है।
क्योंकि एंड्रॉइड कर्नेल कोड में कुछ पुस्तकालय हैं जो स्थापित नहीं होने पर ज्यादातर java.lang.io.exceptions के साथ रनटाइम क्रैश हो जाएगा। यह भी संबोधित किया जाना है कि यदि प्रस्ताव 1 को प्राथमिकता दी जाती है तो इसका मतलब है कि अलग से हैकिंग एंड्रॉइड के प्रत्येक संस्करण में पिछले वाले की तुलना में अधिक निर्भरता है। प्रस्ताव 2 को केवल कंप्यूटर पर एंड्रॉइड एसडीके स्थापित करके और डेवलपर्स द्वारा मोबाइल पर अपने गेम को तुरंत जांचने के लिए एक एंड्रॉइड ऐप (बनाया जाने वाला) का उपयोग करके बनाया जा सकता है; रिमोट की तरह। ऐप के पूर्ण निर्माण या सामान्यीकृत दृष्टिकोण को निर्यात करने के लिए 2 लिया जा सकता है।
जहां तक ​​टेम्पलेट्स की बात है, एक android8+ अनुकूली टेम्प्लेट का उपयोग किया जा सकता है। इसके अलावा एप्लिकेशन के निर्माण के समय को कम करने के लिए (एसडीके का उपयोग करके) इंजन ऑप्टिमाइज़ेशन के रूप में कचरा संग्रहकर्ता को बढ़ाने के लिए और संरचना आधारित दृष्टिकोण जैसे अनुकूलन भी हो सकते हैं उपयोग किया गया।
यह पूरी तरह से मेरा दृष्टिकोण है, अगर यह ठीक है तो मेरे पास एप्लिकेशन (एंड्रॉइड) के संबंध में कुछ योजनाएं हैं जो एप्लिकेशन गेम के तत्काल निर्माण के लिए डिवाइस के एसडीके का उपयोग करती हैं।

Google Play अब अपने नए Android ऐप बंडल (AAB) प्रारूप में अपलोड किए गए ऐप्स को स्वीकार करता है।

यह प्रारूप Google Play को कई डिवाइस प्रकारों के लिए एपीके को गतिशील रूप से उत्पन्न करने की अनुमति देता है और गोडोट में बने गेम को सीधे प्रभावित करने वाली सुविधाओं में से एक एपीके पैक करना है जिसमें केवल उस विशेष सीपीयू आर्किटेक्चर के लिए बनाई गई मूल लाइब्रेरी शामिल है।

इसका मतलब यह है कि डाउनलोड आकार को x86 डिवाइस द्वारा डाउनलोड किए गए एपीके में केवल x86 लाइब्रेरी होने से काफी सुधार किया जा सकता है, आर्म 64 द्वारा डाउनलोड किए गए में केवल आर्म 64 लाइब्रेरी होती है और इसी तरह आगे भी।

मेरा मानना ​​​​है कि गोडोट जो भी दृष्टिकोण अपनाता है उसे इस नए पैकेजिंग प्रारूप का समर्थन करना चाहिए, लेकिन मुझे नहीं पता कि एपीके पैकेज के विपरीत एएबी पैकेज को "हैक" करना कितना आसान है, जो मूल रूप से एक ज़िप फ़ाइल है।

इसका मतलब यह है कि डाउनलोड आकार को x86 डिवाइस द्वारा डाउनलोड किए गए एपीके में केवल x86 लाइब्रेरी होने से काफी सुधार किया जा सकता है, आर्म 64 द्वारा डाउनलोड किए गए में केवल आर्म 64 लाइब्रेरी होती है और इसी तरह आगे भी।

ध्यान दें कि यह पहले से ही संभव है, लेकिन इसके लिए प्रति आर्किटेक्चर एक एपीके बनाकर और फिर इसके एकाधिक एपीके समर्थन का उपयोग करके इसे Google Play पर अपलोड करके मैन्युअल कार्य की आवश्यकता है।

यह #27781 द्वारा तय किया गया था, जो मूल रूप से 1 और 2 के मिश्रण को लागू करता है। पुरानी प्रणाली को एक क्लिक परिनियोजन के लिए संरक्षित किया जाता है, लेकिन रिलीज़ अब पूर्व-संकलित टेम्पलेट स्रोत के साथ शिप की जाएगी जिसे कस्टम मॉड्यूल के साथ एक नए एपीके में पुन: संकलित किया जा सकता है। /प्रकट परिवर्तन/आदि। ग्रेडेल का उपयोग करना।