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

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



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

ऑडियो डिवाइस

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

टेलीफोनी सेवा के साथ बातचीत को लागू करने के लिए भी आवश्यक है ताकि एक टेलीफोन बातचीत के दौरान ऑडियो डिवाइस रिकॉर्ड हो और उपयोगकर्ता की आवाज को सेलुलर नेटवर्क तक पहुंचा सके और सेलुलर नेटवर्क से प्राप्त इंटरलोक्यूटर की आवाज को पुन: पेश करे।

प्रॉक्सी क्लाइंट

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

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

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

प्रॉक्सी सर्वर

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



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

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

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

ध्वनि स्तर नियंत्रण

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

ध्वनि उत्पादन उपकरण

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

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

एक टेलीफोनी सेवा के साथ सहभागिता

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

टेलीफोनी

सबसे दिलचस्प और जटिल तकनीक कंटेनरों के बीच टेलीफोन कॉल का प्रेषण था। एंड्रॉइड पर मोबाइल नेटवर्क तक पहुंचने के लिए सॉफ्टवेयर उपकरण प्रबंधन स्टैक में निम्नलिखित घटक हैं:

1. एपीआई पैकेज com.android.internal.telephony।
2. मोबाइल नेटवर्क के उपयोग के उपकरण में उपयोगकर्ता अनुप्रयोग अनुरोधों को रिल्ड डेमॉन, मल्टीप्लेक्सिंग।
3. मालिकाना उपकरण पहुंच पुस्तकालय।
4. जीएसएम मॉडम ड्राइवर।

घटकों (2) और (3) के बीच के इंटरफेस को प्रलेखित किया जाता है और रेडियो इंटरफेस लेयर या आरआईएल कहा जाता है। यह फ़ाइल विकास / पीडीडी / डॉक्स / पोर्टिंग / टेलीफोनी.जेड में वर्णित है।

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

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

ग्राहक भाग

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

सर्वर साइड

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

रूटिंग नीति का अनुरोध करें

OnRequest द्वारा प्राप्त प्रत्येक प्रकार के अनुरोध के लिए, एक प्रसंस्करण नीति को परिभाषित किया गया है। वर्तमान में, तीन नीतियाँ परिभाषित हैं:

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

प्रत्येक प्रकार की अतुल्यकालिक अधिसूचना के लिए, इसकी रूटिंग नीतियों को भी परिभाषित किया गया है:

• अधिसूचना के बिना शर्त अवरुद्ध।
• एक सक्रिय कंटेनर में रूटिंग। नीति एसएमएस और कॉल की स्वीकृति से संबंधित अधिसूचनाओं के लिए निर्धारित है।
• सभी कंटेनरों को रूटिंग। सेवा सूचना "हार्डवेयर" के लिए - उदाहरण के लिए, सेलुलर नेटवर्क के सिग्नल स्तर में बदलाव के बारे में।

इनपुट सबसिस्टम

Android कर्नेल इनपुट घटनाओं को इकट्ठा करने के लिए एवदेव सबसिस्टम का उपयोग करता है। फ़ाइल / देव / इनपुट / ईवेंटएक्स खोलने वाली प्रत्येक प्रक्रिया के लिए, यह ड्राइवर इनपुट सबसिस्टम के कर्नेल से आने वाली घटनाओं की एक कतार बनाता है।



इस तरह, आने वाली इनपुट घटनाओं को सभी कंटेनरों तक पहुंचाया जा सकता है। Evdev_event () फ़ंक्शन एक इनपुट ईवेंट डिस्पैचर है, इसलिए निष्क्रिय कंटेनर में इनपुट संदेशों की डिलीवरी को रोकने के लिए, इस फ़ंक्शन को संशोधित किया गया है ताकि सभी आने वाली इनपुट घटनाओं को केवल सक्रिय कंटेनर की प्रक्रिया कतार में जोड़ा जाए।

परीक्षण के बारे में थोड़ा सा

जब हम स्मार्टफ़ोन पर अपने समाधान को लॉन्च करने में कामयाब रहे, तो हमने अपने समाधान की विशेषताओं को निर्धारित करने के लिए कई प्रयोग किए। मुझे तुरंत कहना होगा कि हमने अनुकूलन पर काम नहीं किया है - यह काम अभी तक किया जाना है।

परीक्षण के मुख्य उद्देश्य इस प्रकार थे:

• विकसित प्रौद्योगिकी की तत्परता का प्रदर्शन;
• वर्चुअलाइज्ड फोन पर मेमोरी खपत की माप;
• विकसित प्रौद्योगिकी की ऊर्जा खपत का निर्धारण।

निम्नलिखित स्मार्टफोन उपयोग परिदृश्यों के अनुसार सैमसंग गैलेक्सी एस II स्मार्टफोन पर परीक्षण किया गया था:

1. सरल (वे फोन को चालू करते हैं और इसके साथ कुछ भी नहीं करते हैं);
2. स्क्रीन बैकलाइट पर संगीत चलाएं;
3. गुस्से में पक्षियों (जहां उनके बिना?) और एक साथ संगीत प्लेबैक।

परीक्षण स्क्रिप्ट तीन कॉन्फ़िगरेशन पर चलाए गए थे:
1. सैमसंग गैलेक्सी एस II (1) के लिए CyanogenMod 7 का मूल वातावरण;
2. एक कंटेनर CyanogenMod 7 (2) के साथ;
3. CyanogenMod 7 के साथ दो कंटेनर: संगीत एक कंटेनर में खेला गया था, दूसरे (3) में एक गेम लॉन्च किया गया था।

प्रत्येक परीक्षण रन में निम्नलिखित मापदंडों को मापा गया था:
1. मुफ्त मेमोरी की मात्रा और फ़ाइल सिस्टम कैश का आकार (जानकारी / खरीद / मेमरीनोफ़ के अनुसार);
2. बैटरी चार्ज (/ sys / class / power_supply / बैटरी / क्षमता के अनुसार।

प्रत्येक परीक्षण 30 मिनट तक चला, 2 एस की आवृत्ति के साथ माप लिया गया। यहाँ हमें क्या मिला है:



यह अजीब लग सकता है कि कंटेनरों के मामले में मेमोरी की खपत वास्तविक वातावरण की तुलना में कम है। सटीक कारण स्थापित नहीं किया गया है (हमने अभी तक यह पता लगाने की कोशिश नहीं की है), हालांकि, सेल परियोजना में भी यही प्रभाव देखा जाता है, जो उन्होंने अपने लेख में वर्णित किया है ।

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

जैसा कि आप मेमोरी खपत के मूल्यों से देख सकते हैं, जब आप दूसरा कंटेनर शुरू करते हैं, तो यह 2 गुना से अधिक बढ़ जाता है, जो एक स्मार्टफोन पर कई कंटेनरों को लॉन्च करने के लिए एक बाधा है: प्रयोगों से पता चलता है कि 380 एमबी के साथ Google Nexus S स्मार्टफोन एक से अधिक के बिना शुरू नहीं हो सकता है पेजिंग फ़ाइल सक्रियण।

निष्कर्ष

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

हमारे समाधान बनाने के बारे में कुछ रोचक तथ्य और आंकड़े:

• परियोजना के तीन मुख्य डेवलपर्स हैं, जिनमें से दो काम के समय सेंट पीटर्सबर्ग में शैक्षणिक विश्वविद्यालय के छात्र थे, और एक ने स्नातक परियोजना का नेतृत्व किया;
• परियोजना 11 महीने तक चली;
• परियोजना को पैराल्स मॉस्को कार्यालय में इंजीनियरों से सलाह द्वारा सहायता प्रदान की गई थी;
• परियोजना में तीन एंड्रॉइड डिवाइस शामिल थे।

यदि पर्दे के पीछे कुछ महत्वपूर्ण बचा है, तो टिप्पणियों में सवाल पूछें। मैं उन्हें जवाब देने की कोशिश करूंगा।