Android उपकरणों के एपीआई का रहस्य। यैंडेक्स रिपोर्ट

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


- मैं स्कूल के बाद से प्रोग्रामिंग कर रहा हूं, मैं इसे तीन साल से एंड्रॉइड के लिए विकसित कर रहा हूं। इनमें से, मैंने यैंडेक्स में एक साल बिताया, लॉन्चर और फोन जैसी परियोजनाओं में भाग लिया।



मैं इस बारे में बात करना चाहता हूं कि एंड्रॉइड डिवाइसों के एपीआई का विखंडन कैसा दिखता है - बाहर से, एप्लिकेशन डेवलपर्स के तरफ से, और अंदर से, मंच और फोन के डेवलपर्स के दृष्टिकोण से।

मेरी रिपोर्ट में दो भाग हैं। सबसे पहले, आइए इस बारे में बात करें कि एपीआई बाह्य रूप से कैसे खंडित है। फिर हम कोड के माध्यम से जाएंगे - हम यह पता लगाएंगे कि अमूर्त टेलीफोन की अनूठी विशेषता कैसे महसूस की जाती है, विकास कैसे बनाया जाता है।

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





हमारे कोड में, यह कुछ इस तरह दिखता है: हम कुछ कार्यक्षमता को चालू करते हैं, कुछ को बंद करते हैं - एसडीके के किस संस्करण के आधार पर हम वर्तमान में हैं। यदि आप किसी का उपयोग करते हैं, तो वे आमतौर पर ऐसा ही करते हैं, लेकिन अंदर।

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

हम इसके साथ कैसे काम करते हैं? जब हम पुराने संस्करणों का समर्थन करने से इनकार करते हैं तो हम पुस्तकालयों का उपयोग करते हैं और बहुत खुश होते हैं। मुझे लगता है कि हर किसी के जीवन में जो एक साल से अधिक समय से ऐसा कर रहा है, ऐसा एक क्षण था। यह सिर्फ खुशी है। यह एक स्पष्ट और सरल विखंडन विकल्प है। अगला अप एंड्रॉइड टाइप विखंडन है। उनमें से कई हैं। एंड्रॉइड टीवी खुद के लिए बोलता है, एंड्रॉइड ऑटो मुख्य रूप से कार रेडियो, एंड्रॉइड थिंग्स के लिए इरादा है - IoT और इसी तरह के एम्बेडेड उपकरणों के लिए। डब्ल्यू पहनें ओएस, पूर्व Android घड़ी, Android के लिए घड़ी है। हम यह विचार करने की कोशिश करेंगे कि यह डेवलपर की तरफ से कैसा दिखता है। और, सबसे दिलचस्प बात, आइए विचार करने की कोशिश करें कि यह अंदर से कैसा दिखता है।



Developer.android.com से दो उदाहरण लें। पहला है OS पहनना। हमें एक आवेदन करने की क्या आवश्यकता है? हम build.gradle में एक अतिरिक्त निर्भरता जोड़ते हैं और मैनिफ़ेस्ट में दो अतिरिक्त लाइनें लिखते हैं: उपयोग-सुविधा android.hardware.type.watch और उपयोग-लाइब्रेरी, जो उसी लाइब्रेरी के पैकेज के नाम से मेल खाती है जिसे हमने कनेक्ट किया था।



हम कुछ कैसे लागू करते हैं? हम एक गतिविधि बनाते हैं, केवल इस मामले में हम एक मानक गतिविधि का खर्च नहीं उठाते हैं जिसका उपयोग हम काम करने के लिए करते हैं, और एक समग्र एक भी नहीं, लेकिन पहनने योग्य वस्तु, और इसके लिए विशिष्ट तरीके कॉल करते हैं, इस मामले में setAmbientEnabled ()। इसलिए, हमारे पास एक संकलन निर्भरता है, अर्थात यह हमारे आवेदन के पाठ्यक्रम में नहीं आता है। उपयोग-पुस्तकालय, जो, जाहिरा तौर पर, इन कक्षाओं को कनेक्ट करने के लिए ओएस को मजबूर करता है और डिवाइस पर रनटाइम में, और हमारे द्वारा उपयोग की जाने वाली नई कक्षाएं।



एंड्रॉइड थिंग्स एपीआई व्यावहारिक रूप से अलग नहीं है। हम उपयोग-सुविधा को निर्धारित नहीं करते हैं, केवल उपयोग करता है-पुस्तकालय, संकलन-निर्भरता।



हम गतिविधि बनाते हैं, इस मामले में यह एंड्रॉइड थिंग्स एपीआई, पेरिफेरल मैनजर वर्ग के लिए अद्वितीय है। हम GPIO को मतदान कर रहे हैं और प्रतिज्ञा करने की कोशिश कर रहे हैं।



ऐसे ऐप आपके फ़ोन पर कैसा व्यवहार करेगा? दो विकल्प हैं।



यदि हमने संकेत दिया है कि उपयोग करने वाली लाइब्रेरी एंड्रॉइड: आवश्यक = "सही" है, तो हमने एप्लिकेशन इंस्टॉल करने के लिए पैकेजमेन्जर की अनिवार्य आवश्यकताओं को पूरा नहीं किया है, और यह मूल रूप से इसे स्थापित करने से इनकार करता है। अगर हमने Android निर्दिष्ट किया है: आवश्यक = "गलत", तो एप्लिकेशन इंस्टॉल हो जाएगा, लेकिन जब हम पेरिफेरल मैनजर क्लास तक पहुंचने का प्रयास करते हैं, तो हमें NoClassDefFoundError मिलता है, क्योंकि मानक Android में ऐसी कोई क्लास नहीं है।

निष्कर्ष क्या हैं? हम असेंबली के दौरान इसके संपर्क में आने के लिए केवल कंपाइलऑन निर्भरता को कनेक्ट करते हैं, और जो कक्षाएं हम उपयोग करते हैं वे डिवाइस पर हमारा इंतजार कर रहे हैं, वे प्रकट में कुछ पंक्तियों का उपयोग करके जुड़े हुए हैं। कभी-कभी हम एक ऐसी सुविधा को लिखते हैं जो Google Play पर अंतर करने के लिए अधिक बार आवश्यक होती है एक उपकरण है जिसमें यह एप्लिकेशन वितरित या वितरित नहीं किया जा सकता है।

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

इसके साथ कैसे काम करें? अधिक एप्लिकेशन लिखें। सामान्य अनुशंसा सभी प्रकार के एंड्रॉइड के लिए एप्लिकेशन के एक से अधिक संस्करण लिखना है, लेकिन फिर भी अलग-अलग करते हैं। एक घड़ी के लिए कम होना चाहिए, एंड्रॉइड थिंग्स के लिए व्यावहारिक रूप से फोन पर जो कुछ भी लिखा गया है वह उपयुक्त नहीं है, और इसी तरह। और Android डेवलपर्स और कभी-कभी, डिवाइस डेवलपर्स हमें प्रदान करने वाले पुस्तकालयों का उपयोग करते हैं।

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



इस विषय पर, हमारे पास हमारे विकास लांचर से एक अद्भुत कहानी है। हमें एक बग रिपोर्ट मिली, जहां गतिविधि पूर्ण स्क्रीन तक नहीं हुई थी, और हमारा पसंदीदा डिफ़ॉल्ट वॉलपेपर बिल्कुल भी प्रदर्शित नहीं हुआ था। इसे डिकोड नहीं किया गया था, एक खाली खिड़की दिखाई दी। हमारे पास इसे पुन: उत्पन्न करने के लिए उपकरण भी नहीं हैं। स्क्रीन पर स्ट्रेचिंग करके, हम अभी भी एक कम-अंत डिवाइस को खोजने में सक्षम थे, जिस पर यह काम नहीं करता था, और एंड्रॉइड का उपयोग करके काफी आसानी से सब कुछ तय किया गया था: प्रकट में उपयुक्तता = "सही"। वॉलपेपर के साथ, सब कुछ बहुत अधिक जटिल हो गया। लगभग दो दिन हमने और अधिक विस्तृत जानकारी प्राप्त करने का प्रयास किया। अंत में, उन्हें पता चला कि प्रगतिशील jpeg को डिकोड करने के लिए या तो कई उपकरणों पर बग्स के साथ लागू किया गया था, जब एक दूसरे के परिणामों पर कई संपीड़न एल्गोरिदम का उपयोग किया गया था। इस मामले में, हमने सिर्फ एक लिंट-चेक लिखा है, जो कि एप्लिकेशन का निर्माण करते समय बिल्ड को विफल करता है, अगर हम एपीके में ही प्रगतिशील तरीके से एन्कोडेड वॉलपेपर लगाते हैं। सभी वॉलपेपर को रीकोड किया, बैकएंड पर स्थिति को दोहराया, जो बाकी वॉलपेपर सेटों को वितरित करता है, और सब कुछ बहुत अच्छा काम करता है। लेकिन इसने हमें लगभग दो दिनों की कार्यवाही की लागत दी।



यह कोड में कुछ इस तरह दिखता है। अप्रिय, लेकिन दुर्भाग्य से, जैसे। आमतौर पर ये लाइनें लंबी डिबगिंग के बाद दिखाई देती हैं।



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

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

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

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

इस प्रकार, आप में से कोई भी इस प्रकार के विखंडन से भी कुछ लाभ प्राप्त कर सकता है। हम इसके साथ क्या कर रहे हैं? किसी भी मामले में बग्स की रिपोर्ट करने और डिवाइस डेवलपर्स और यहां तक ​​कि एंड्रॉइड डेवलपर्स के लिए बग रिपोर्ट भेजने के लिए स्वतंत्र महसूस न करें। क्योंकि अगर कोई भी API जो CTS टेस्ट लिखने लायक था, तो उसे तोड़ दिया गया, तो यह लिखा जाएगा - और ऐसी मिसालें हैं - और उसके बाद API और अधिक विश्वसनीय हो जाता है।

एंड्रॉइड जानें, जानें कि निर्माता क्या पेश करते हैं, उनके साथ शपथ न लें - उनके साथ काम करें।

यह अंदर से कैसा दिखता है? मैं कुछ सुविधा कैसे लागू कर सकता हूं जो हमारे फोन के लिए अद्वितीय होगी और इस एपीआई का उपयोग एक नियमित एंड्रॉइड एप्लिकेशन से कर सकते हैं?



सिद्धांत की एक बिट। एंड्रॉइड डेवलपर्स स्वयं आंतरिक एओएसपी डिवाइस का वर्णन कैसे करते हैं? शीर्ष परत एक ऐसा एप्लिकेशन है जो या तो आपके द्वारा या फोन के डेवलपर्स द्वारा स्वयं लिखा गया था, जिसमें कोई उच्च अधिकार नहीं है, बस मानक एपीआई का उपयोग करता है। यह एक ढांचा है, ये ऐसी कक्षाएं हैं जो आपके आवेदन का हिस्सा नहीं हैं, जैसे कि गतिविधि, पार्सलेबल, बंडल - वे सिस्टम का हिस्सा हैं, उन्हें एक रूपरेखा के रूप में संदर्भित किया जाता है। डिवाइस पर आपके लिए उपलब्ध कक्षाएं। इसके बाद सिस्टम सेवाएं हैं। यह वही है जो आपको सिस्टम से जोड़ता है: एक्टिविटी मैनजर सर्विस, विंडो मैनजर सर्विस, पैकेजमैनगर सर्विस, जो सिस्टम के साथ बातचीत के आंतरिक पक्ष को लागू करते हैं।

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



यह डिवाइस पर कैसे दिखता है? हमारा आवेदन न केवल मानक ढांचे के साथ बातचीत करता है, बल्कि निर्माता के कस्टम ढांचे के साथ भी बातचीत कर सकता है। इसके अलावा, इस ढांचे के माध्यम से, यह कस्टम सेवाओं के साथ संवाद कर सकता है। यदि ये हार्डवेयर्ड या लो-लेवल फीचर्स हैं, तो उनके लिए HAL लिखा जाता है, और यदि आवश्यक हो तो कर्नेल स्तर पर ड्राइवर भी।



हम अपनी सुविधा कैसे लिखते हैं? योजना सरल है: आपको एक रूपरेखा लिखने की ज़रूरत है जो कि उन पुस्तकालयों से बहुत अलग नहीं है जो अधिकांश एंड्रॉइड डेवलपर्स ने लिखा है, मुझे लगता है कि आप सभी यह जानते हैं। आपको एक सिस्टम सेवा लिखने की आवश्यकता है, जो एक साधारण अनुप्रयोग है, केवल सिस्टम में अधिकारों का एक बहुत ही सामान्य सेट नहीं है। और यदि आवश्यक हो, तो आप एचएएल लिख सकते हैं, लेकिन हम इसे छोड़ देते हैं। आप कर्नेल स्तर पर अपने स्वयं के ड्राइवर लिख सकते हैं, लेकिन हम अब इस पर विचार नहीं करेंगे। और एक क्लाइंट एप्लिकेशन लिखें जो यह सब उपयोग करेगा।



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



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



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



इसके अलावा, इस सिस्टम सेवा के उपलब्ध होने के लिए, हमें इसे सिस्टम सेवा प्रबंधक में पंजीकृत करना होगा, और इस मामले में यह वही वर्ग है जो सामान्य अनुप्रयोगों के लिए उपलब्ध नहीं है। यह उन लोगों के लिए सटीक रूप से उपलब्ध है जो सिस्टम विभाजन में प्लेटफ़ॉर्म में हैं। हम सेवा को केवल Application.onCreate () में पंजीकृत करते हैं, इसे उस वर्ग के नाम के तहत उपलब्ध कराते हैं जिसे हमने बनाया था।

मूल रूप से शुरू करने और हमारी सेवा को मेमोरी में लोड करने के लिए हमें ऑनक्रीट () की क्या आवश्यकता है? हम एप्लिकेशन एंड्रॉइड में मैनिफ़ेस्ट में लिखते हैं: लगातार = "सही"। इसका मतलब है कि यह एक निरंतर प्रक्रिया है, इसे लगातार मेमोरी में होना चाहिए, क्योंकि यह सिस्टम फ़ंक्शन करता है।



इसके अलावा स्वयं प्रकट होने पर हम एंड्रॉइड को साझा कर सकते हैं: shareUserId, इस मामले में सिस्टम, लेकिन यह विभिन्न आईडी की एक विस्तृत श्रृंखला हो सकती है, वे एप्लिकेशन को सिस्टम में व्यापक अधिकार प्राप्त करने की अनुमति देते हैं, विभिन्न एपीआई और सेवाओं के साथ बातचीत करते हैं जो सामान्य अनुप्रयोगों के लिए उपलब्ध नहीं हैं।

इस मामले में, उदाहरण के लिए, हमने ऐसा कुछ भी उपयोग नहीं किया।



हमने एक रूपरेखा लिखी, एक प्रणाली सेवा लिखी। हम अंदर के तंत्र को छोड़ देंगे, यह कुछ जटिल विषय है, यह एक अलग रिपोर्ट के योग्य है।

एप्लिकेशन डेवलपर्स को फ्रेमवर्क कैसे वितरित करें? दो प्रारूप। हम पूर्ण-भाग वाली कक्षाएं जारी कर सकते हैं और एक पूर्ण पुस्तकालय बना सकते हैं जिसे आप अपने आवेदन में संकलित करते हैं, और सभी तर्क आपके डेक्स का हिस्सा बन जाएंगे।

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



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

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

आपको डिवाइस डेवलपर्स को उन लोगों के साथ व्यवहार नहीं करना चाहिए जो आपके एप्लिकेशन को तोड़ते हैं। ये समान डेवलपर्स हैं, वे समान स्तर पर, समान कोड लिखते हैं। बग रिपोर्ट लिखें, वे वास्तव में मदद करते हैं, मैं अक्सर उनका विश्लेषण करता हूं। अधिक एप्लिकेशन लिखें और उन अवसरों का लाभ उठाएं जो एंड्रॉइड और डिवाइस दोनों स्वयं प्रदान करते हैं। मेरे पास यह सब है।