स्मार्ट होम हब ओईएम प्रोजेक्ट्स कैसे एओएसपी और जीएमएस एंड्रॉइड आर्किटेक्चर के बीच चयन करते हैं

जब कंपनियाँ एक स्मार्ट होम हब विकसित करती हैं, तो एंड्रॉइड सिस्टम आर्किटेक्चर का निर्णय अक्सर हार्डवेयर उत्पादन चरण से कहीं अधिक पहले लिया जाता है।

पहली नज़र में, एक होम हब डिस्प्ले एक मानक टचस्क्रीन उपकरण जैसा दिख सकता है। हालाँकि, कई B2B परियोजनाओं के लिए, डिस्प्ले केवल एक ऑपरेटिंग सिस्टम के साथ एक स्क्रीन नहीं होता है। यह सॉफ़्टवेयर सेवाओं, उपयोगकर्ताओं और जुड़े हुए घर के वातावरण को जोड़ने वाला एक समर्पित इंटरफ़ेस बन जाता है।

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

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

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

कुछ स्मार्ट होम हब परियोजनाओं को एंड्रॉइड प्रणालियों पर अधिक नियंत्रण क्यों आवश्यक है

एक पारंपरिक उपभोक्ता टैबलेट लचीलापन के चारों ओर डिज़ाइन किया गया है। उपयोगकर्ता विभिन्न अनुप्रयोग स्थापित करते हैं, ऑनलाइन सेवाओं तक पहुँच प्राप्त करते हैं और एक व्यापक पारिस्थितिकी तंत्र के साथ अंतःक्रिया करते हैं।

एक समर्पित स्मार्ट घर हब एक अलग तर्क का पालन करता है। कई ओईएम परियोजनाओं के लिए, यह उपकरण एक प्राथमिक उद्देश्य रखता है: एक नियंत्रित वातावरण में एक विशिष्ट अनुप्रयोग को विश्वसनीय रूप से चलाना।

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

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

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

तीन ओईएम अनुरोध एंड्रॉइड अनुकूलन के पीछे विभिन्न कारणों को दर्शाते हैं

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

एक नॉर्वे-आधारित सिस्टम इंटीग्रेटर ने एक एओएसपी -आधारित डिस्प्ले का अनुरोध किया, जिसमें GMS शामिल नहीं था, साथ ही कैमरा और माइक्रोफोन घटकों को हटाने जैसी हार्डवेयर सीमाएँ भी थीं। परियोजना में कियोस्क मोड के साथ स्वचालित एपीके लॉन्च की आवश्यकता थी।

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

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

दूसरी परियोजना, बेल्जियम स्थित वृद्ध देखभाल समाधान प्रदाता की ओर से, अलग प्राथमिकताओं पर केंद्रित थी। अनुरोधित विशेषताओं में 4G कनेक्टिविटी, वाईफाई, कियोस्क मोड और एक सरलीकृत अंतःक्रिया अनुभव शामिल था।

पहली परियोजना के विपरीत, इस खरीदार ने स्पष्ट रूप से एक डी-गूगल्ड सिस्टम का अनुरोध नहीं किया था। यह अंतर महत्वपूर्ण है क्योंकि यह दर्शाता है कि गोपनीयता-केंद्रित एंड्रॉइड अनुकूलन प्रत्येक स्मार्ट घर या वृद्ध देखभाल अनुप्रयोग के लिए स्वतः ही आवश्यक नहीं है।

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

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

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

सही एंड्रॉइड आर्किटेक्चर इस बात पर निर्भर करता है कि सॉफ़्टवेयर अनुभव को कौन नियंत्रित करता है

के बीच निर्णय लेना एओएसपी और GMS एप्लिकेशन मॉडल से शुरू करना चाहिए, ऑपरेटिंग सिस्टम की प्राथमिकता से नहीं।

जिन प्रोजेक्ट्स को गूगल सेवाओं, उपभोक्ता एप्लिकेशन्स या मौजूदा एंड्रॉइड पारिस्थितिकी तंत्र पर भारी निर्भरता होती है, वहाँ GMS-सक्षम एंड्रॉइड व्यावहारिक लाभ प्रदान कर सकता है क्योंकि इसका व्यापक अनुप्रयोग संगतता .

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

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

इसलिए खरीदारों के लिए प्रश्न केवल यह नहीं है:

"क्या यह आपूर्तिकर्ता एक एंड्रॉइड टैबलेट प्रदान कर सकता है?"

अधिक महत्वपूर्ण प्रश्न यह है:

"क्या यह आपूर्तिकर्ता हमारी परियोजना द्वारा आवश्यक पूर्ण हार्डवेयर और सॉफ्टवेयर तैनाती मॉडल का समर्थन कर सकता है?"

गोपनीयता आवश्यकताओं की पुष्टि की जानी चाहिए, धारणा नहीं की जानी चाहिए

"कोई जीएमएस नहीं", "कोई कैमरा नहीं", या "कोई माइक्रोफ़ोन नहीं" जैसे अनुरोध अक्सर ध्यान आकर्षित करते हैं, क्योंकि वे मजबूत गोपनीयता की अपेक्षाओं को दर्शा सकते हैं।

हालाँकि, इनके सटीक प्रेरणाओं को अनुमानित नहीं किया जाना चाहिए।

तीन समीक्षित परियोजनाओं में से केवल एक खरीदार ने स्पष्ट रूप से एक GMS-मुक्त  एओएसपी वातावरण का अनुरोध किया। अन्य दो परियोजनाओं में इस आवश्यकता का उल्लेख नहीं किया गया था।

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

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

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

कियोस्क तैनाती समर्पित स्मार्ट डिस्प्ले के लिए एक आधार बन रही है

हालाँकि तीनों खरीदारों के अलग-अलग प्राथमिकता थीं, सभी परियोजनाओं में एक समान दिशा थी: डिस्प्ले को एक समर्पित सेवा इंटरफ़ेस के रूप में कार्य करने की आवश्यकता थी।

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

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

यह OEM आपूर्तिकर्ताओं के लिए नए आवश्यकताएँ भी उत्पन्न करता है। इन परियोजनाओं का समर्थन करने के लिए केवल हार्डवेयर विनिर्देशों को समझना ही नहीं, बल्कि सॉफ्टवेयर-हार्डवेयर एकीकरण विकास, निर्माण और दीर्घकालिक संचालन के दौरान भी समझना आवश्यक है।

एक OEM स्मार्ट डिस्प्ले परियोजना शुरू करने से पहले, इन निर्णयों को पहले परिभाषित करें

एक अनुरोध करने से पहले Android डिस्प्ले OEM समाधान, खरीदारों को पहले चार परियोजना सीमाओं को स्पष्ट कर लेना चाहिए:

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

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

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

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

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

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

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

हमारी टीम से संपर्क करें अपनी परियोजना की आवश्यकताओं पर चर्चा करने या एक अनुकूलित एंड्रॉइड प्रदर्शन समाधान के लिए अपनी जांच जमा करने के लिए।