कंटेनर में BYOD: हम एंड्रॉइड को वर्चुअलाइज करते हैं। एक भाग

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

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

परिचय: यह सब क्यों आवश्यक है?

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

इस तरह के खतरे से खुद को बचाने का एक स्पष्ट तरीका अविश्वसनीय सॉफ्टवेयर के लिए एक विशेष सैंडबॉक्स बनाना है; या, इसके विपरीत, कॉर्पोरेट सॉफ़्टवेयर और व्यावसायिक डेटा के लिए इस तरह के "सैंडबॉक्स" बनाएं। दोनों दृष्टिकोणों को कर्मचारी के निजी जानकारी (एसएमएस, पार्टियों से फोटो आदि) पर अतिक्रमण के बिना, नाजुक रूप से लागू किया जाना चाहिए। इस तरह के "सैंडबॉक्स" अक्सर सॉफ्टवेयर विकास और परीक्षण उद्योग में पाए जाते हैं और वर्चुअलाइजेशन का उपयोग करके बनाए जाते हैं। हमने कुछ ऐसा ही करने का फैसला किया, लेकिन स्मार्टफोन पर।

हम एनालॉग्स की तलाश कर रहे हैं

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



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

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

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

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

ट्रस्टड्रोइड में काफी सुधार करके नुकसान को दूर किया जा सकता है। हालाँकि, TrustDroid केवल डिवाइस पर सुरक्षा सुनिश्चित करने की समस्या को हल करता है, जबकि उपयोगकर्ता विभिन्न वातावरणों में डेटा को अलग करने की क्षमता भी महत्वपूर्ण है।

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

कंटेनर वर्चुअलाइजेशन रास्ता है

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

• OpenVZ पैच का वर्तमान प्रायोगिक संस्करण कर्नेल संस्करण 2.6.32 के लिए है, लेकिन जिन स्मार्टफोन पर प्रौद्योगिकी विकसित की गई थी और कर्नेल संस्करण 2.6.35 चलाए गए थे;
• जब इस्तेमाल की गई लाशों में से एक पर OpenVZ पैच लगाने की कोशिश कर रहा है, तो 1682 से 166 फाइलें पैच करना संभव नहीं था; इसके अलावा, पैच 34 x86- विशिष्ट फ़ाइलों को संशोधित करता है।

2.6.35 कर्नेल में इतने बदलावों को पोर्ट करना हमें अत्यधिक लगा। लेकिन, OpenVZ को छोड़ते हुए, हमने sysfs वर्चुअलाइजेशन के लिए तैयार किए गए समाधान को खो दिया: एक नया वर्चुअल वातावरण बनाते समय, OpenVZ रूट उपयोगकर्ता पर्यावरण के सिस्टम ऑब्जेक्ट्स (kobject) के पेड़ को कॉपी करता है, जिसके लिए हमें अतिरिक्त प्रयासों की आवश्यकता होती है।

इसलिए, मानक LXC लिनक्स कंटेनरों और संपूर्ण कर्नेल अवसंरचना का उपयोग करने का निर्णय लिया गया, जो नामस्थानों के कार्यान्वयन और संसाधन समूहों के भेदभाव के लिए जिम्मेदार है।

आंकड़ा हमारे समाधान की वास्तुकला को दर्शाता है।

• नियंत्रण कक्ष जीयूआई से एलएक्ससी; आपको कंटेनरों को प्रबंधित करने की अनुमति देता है (प्रारंभ, रोकें, सक्रिय कंटेनर स्विच करें)।
• कर्नेल पर्यवेक्षक, चित्र में - AndCont पर्यवेक्षक। ड्राइवरों की आभासी स्थिति को शुरू करता है, जिस क्षण कंटेनर शुरू होता है, कंटेनर के बीच स्विच करने पर लागू होता है।
• इंटरकेंटर तंत्र (आईसीसी)। नेटलिंक पर आधारित कंटेनरों के बीच संचार का एक साधन, एप्लिकेशन नेटवर्क प्रोटोकॉल में चेक को दरकिनार करना और साझा मेमोरी पर आधारित है।
• इनपुट मैनेजर समानांतर में काम करने वाले Android इनपुट उपकरणों को साझा करने के लिए आवश्यक है।
• वर्चुअल फ्रेमबफ़र ड्राइवर। एक साथ डिवाइस स्क्रीन का उपयोग करने की क्षमता प्रदान करता है।
• GPU ड्राइवर। एक साथ सभी कंटेनरों के साथ GPU का उपयोग करने की क्षमता को लागू करता है।
• बाइंडर। IPC ड्राइवर Android ओपन सोर्स प्रोजेक्ट (AOSP) के हिस्से के रूप में बनाया गया है।
• अलार्म। घड़ी का इंटरफ़ेस।
• रेडियो इंटरफ़ेस नियंत्रण तंत्र के लिए प्रॉक्सी सर्वर (रेडियो इंटरफ़ेस परत, आरआईएल)। कई एंड्रॉइड कंटेनरों को मोबाइल नेटवर्क तक पहुंच साझा करने की अनुमति देता है।
• आरआईएल प्रॉक्सी क्लाइंट। यह कंटेनर में अनुप्रयोगों से टेलीफोनी सेवा के अनुरोधों को स्वीकार करता है और उन्हें आरआईएल प्रॉक्सी सर्वर को भेजता है।
• प्रॉक्सी क्लाइंट ऑडियो। कंटेनर की ऑडियो धाराओं को नियंत्रित करता है और उन्हें ऑडियो प्रॉक्सी पर भेजता है।
• प्रॉक्सी सर्वर ऑडियो। कंटेनरों की ध्वनि धाराओं को पुन: प्रस्तुत करता है।
• सहायक कंटेनर। अतिथि Android से हटाए गए विभिन्न कारणों से सिस्टम डेमॉन और एंड्रॉइड लाइब्रेरी चलाने के लिए डिज़ाइन किया गया है।

कंटेनर प्रबंधन तंत्र

• CAP_SYS_BOOT ध्वज अक्षम किया गया है, जो सिस्टम को रिबूट करने की क्षमता के लिए जिम्मेदार है, जिसका उपयोग प्रारंभिक होने पर Dalvik वर्चुअल जावा मशीन द्वारा किया जाता है।
• Lxc_start में मानक के अलावा अन्य ओपन फ़ाइल डिस्क्रिप्टर के लिए चेक छोड़ा गया है।
• एक बग को एडबर्ड डेमन से फ़ाइल डिस्क्रिप्टर के रिसाव की ओर ले जाता है, जिसका उपयोग यूएसबी के माध्यम से स्मार्टफोन तक पहुंचने के लिए किया जाता है।
• Init प्रक्रिया शुरू करने से पहले एक नया कंटेनर लॉन्च करने के लिए कर्नेल स्तर पर्यवेक्षक के लिए अधिसूचनाएँ जोड़ी गई हैं।

बाइंडर

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

इस प्रकार, प्रत्येक कंटेनर के लिए उपरोक्त चर के उदाहरणों को बनाना और कंटेनर से संबंधित आभासी स्थिति का उपयोग करना आवश्यक था जिसके संदर्भ में ioctl () सिस्टम कॉल किया गया था।

परिधीय वर्चुअलाइजेशन

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

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

इस प्रकार, कई एंड्रॉइड कंटेनरों में काम करने के लिए, सभी OSes द्वारा परिधीय उपकरणों को एक साथ उपयोग करने की क्षमता प्रदान करना आवश्यक है।

इसके लिए मुख्य बात यह है कि बाह्य उपकरणों तक एंड्रॉइड की पहुंच को नियंत्रित करने में सक्षम होना चाहिए ताकि वे बाह्य उपकरणों का मनमाने ढंग से उपयोग न कर सकें।

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

• इंटरफ़ेस एंड्रॉइड के सभी उपलब्ध संस्करणों के साथ जितना संभव हो उतना संगत होना चाहिए;
• इंटरफ़ेस एकल होना चाहिए और डिवाइस तक पहुंच के सभी कार्यों के लिए उपयोग किया जाना चाहिए।

अगला, हम देखेंगे कि ग्राफिक स्क्रीन का वर्चुअलाइजेशन कैसे किया जाएगा, और अगले लेख में हम टेलीफोनी, ध्वनि और टचस्क्रीन के वर्चुअलाइजेशन के बारे में बात करेंगे।

प्रदर्शन

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

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

एमएमयू जीपीयू को रीप्रोग्रामिंग करना

फ़्रेमबफ़र ड्राइवर के अलावा, GPU में भौतिक स्क्रीन तक पहुंच है। ताकि निष्क्रिय ऑपरेटिंग सिस्टम स्क्रीन पर अपने यूआई को प्रदर्शित न करें, आपको उनके फ़्रेमों को प्रदर्शित करने के संचालन को बदलने की आवश्यकता है। यह पता चला है कि प्रयोगात्मक Google Nexus S और Samsung Galaxy SII के मामले में, स्मार्टफ़ोन स्क्रीन DMA का उपयोग करके RAM से डिस्प्ले के लिए फ़्रेम की प्रतिलिपि बनाते हैं। फ़्रेमबफ़र ड्राइवर स्क्रीन को वह पता बताता है जिस पर प्रदर्शन के लिए इच्छित फ़्रेम स्थित है (स्क्रीन मेमोरी)। इस प्रकार, स्क्रीन पर एक फ्रेम प्रदर्शित करने का संचालन एक विशिष्ट पते पर डिवाइस रैम में एक फ्रेम की रिकॉर्डिंग के संचालन की तरह दिखता है।

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

छाया चौखटा

एंड्रॉइड यूआई को बदल देता है क्योंकि यह टाइमर से बदलता है। इसलिए, यदि आप सक्रिय एंड्रॉइड को स्विच करते समय केवल एमएमयू को स्क्रीन मेमोरी में रीडायरेक्ट करते हैं, तो सक्रिय एंड्रॉइड स्क्रीन पर फ़्रेम को फिर से नहीं कर सकता है और उस पर छवि पिछले सक्रिय ओएस से होगी।

यदि आप प्रत्येक एंड्रॉइड के लिए एक छाया बफर का चयन करते हैं, तो सक्रिय ओएस को स्विच करते समय, बस स्क्रीन पर फ्रेम को पिछले सक्रिय एंड्रॉइड के छाया बफर पर कॉपी करें। एंड्रॉइड को प्रदर्शित करने के लिए जो सक्रिय हो गया है, आपको इसकी छाया बफर की सामग्री को स्क्रीन मेमोरी में कॉपी करने की आवश्यकता है। लेकिन छाया बफर 2 से 4 एमबी भौतिक मेमोरी से लेता है। सक्रिय एंड्रॉइड को स्विच करते समय एक फ्रेम को फिर से तैयार करने की क्षमता होने के कारण, आप प्रत्येक एंड्रॉइड के लिए छाया बफर आवंटन से छुटकारा पा सकते हैं, एक सिंगल शैडो बफर छोड़ सकते हैं।

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

लिनक्स वर्चुअल ड्राइवर फ्रेमबफ़र

लिनक्स फ़्रेमबफ़र ड्राइवर के लिए एक विशिष्ट उपयोग मामला स्क्रीन मेमोरी को मैप करने के लिए उपयोगकर्ता प्रक्रिया पता स्थान के साथ मिमीप () सिस्टम कॉल और मानक और विशेष आईओसीटीएल कॉल करने के लिए है।

मानक IOCTL कर्नेल में मानक Linux Framebuffer IOCTL प्रोसेसर द्वारा नियंत्रित किया जाता है। विशेष IOCTL में गैर-मानक शब्दार्थ है और इसे केवल भौतिक लिनक्स फ्रेमबफ़र चालक द्वारा संसाधित किया जा सकता है। चूंकि भौतिक लिनक्स फ़्रेमबफ़र को आभासी में बदल दिया गया था, इसलिए mmap () और IOCTL को वर्चुअल लिनक्स फ्रेमबफ़र ड्राइवर कहा जाता है।

सभी Linux () कॉल पूरी तरह से भौतिक लिनक्स फ्रेमबफ़र ड्राइवर का उपयोग किए बिना वर्चुअल लिनक्स फ्रेमबफ़र ड्राइवर में संसाधित होते हैं, क्योंकि इस प्रणाली कॉल के शब्दार्थ मानक हैं। सक्रिय एंड्रॉइड प्रक्रियाएं स्क्रीन मेमोरी तक पहुंचने के लिए mmap () को कॉल करती हैं। मिमीएप पर कॉल करते समय निष्क्रिय एंड्रॉइड प्रक्रियाएं (स्क्रीन मेमोरी के बजाय छाया बफर तक पहुंच प्राप्त करती हैं)। सभी रनिंग एंड्रॉइड के लिए, लिनक्स फ़्रेमबफ़र ड्राइवर की आभासी स्थिति बनाई गई है। सक्रिय एंड्रॉइड के लिए, वर्चुअल लिनक्स फ़्रेमबफ़र ड्राइवर के सभी कॉल तुरंत भौतिक लिनक्स फ़्रेमबफ़र ड्राइवर पर पुनर्निर्देशित किए जाते हैं, जो भौतिक लिनक्स फ़्रेमबफ़र ड्राइवर की स्थिति को बदल देता है। निष्क्रिय एंड्रॉइड के लिए, मानक IOCTL अपने वर्चुअल लिनक्स फ्रेमबफ़र राज्यों को बदलते हैं। निष्क्रिय Android के लिए गैर-मानक IOCTL एक त्रुटि लौटाता है। Google Nexus S और Samsung Galaxy SII उपकरणों पर, यह पर्याप्त था।

इंटरमीडिएट के निष्कर्ष

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



ध्वनि, टेलीफोनी और उपयोगकर्ता इनपुट का वर्चुअलाइजेशन कैसे लागू किया गया - इसके बारे में अगले लेख में ।