چگونه پروژه‌های تولید تجهیزات اصلی (OEM) مراکز خانه هوشمند بین معماری‌های اندروید AOSP و GMS انتخاب می‌کنند

وقتی شرکت‌ها یک مرکز هوشمند خانه , معماری سیستم اندروید معمولاً بسیار زودتر از مرحلهٔ تولید سخت‌افزار تعیین می‌شود.

با نگاه اولیه، یک نمایشگر مرکزی خانگی ممکن است شبیه یک دستگاه لمسی معمولی به نظر برسد. با این حال، برای بسیاری از پروژه‌های B2B، نمایشگر صرفاً یک صفحه‌نمایش با سیستم عامل نیست. بلکه به یک رابط اختصاصی تبدیل می‌شود که خدمات نرم‌افزاری، کاربران و محیط‌های خانگی متصل‌شده را به هم پیوند می‌زند.

به همین دلیل برخی از خریداران شروع به پرسیدن سؤالات عمیق‌تری دربارهٔ معماری اندروید : آیا دستگاه باید از اندروید استاندارد با خدمات موبایل گوگل ( GMS ) استفاده کند؟ آیا این پروژه نیازمند یک سیستم مبتنی بر اُاس‌پی سیستمی مبتنی بر اُاس‌پی بدون سرویس‌های گوگل؟ خریدار تا چه حد نیاز به کنترل نرم‌افزار و رفتار دستگاه دارد؟

سه درخواست واقعی از سوی سازندگان تجهیزات اصلی (اُئی‌ام) مرکز خانه هوشمند از نروژ، بلژیک و ایالات متحدهٔ آمریکا نمونه‌های مفیدی ارائه می‌دهند. این درخواست‌ها کل بازار خانه‌های هوشمند را نمایندگی نمی‌کنند، اما نشان می‌دهند که خریداران مختلف چگونه نیازهای سیستمی را بر اساس اهداف خود در زمینهٔ راه‌اندازی ارزیابی می‌کنند.

سیگنال مهم این نیست که هر پروژه‌ای از خانهٔ هوشمند به سمت نمایشگرهای غیرگوگلی در حال حرکت است. بلکه این درخواست‌ها نشان می‌دهند که خریداران در مورد کنترل نرم‌افزار، راه‌اندازی برنامه‌ها و سفارشی‌سازی دستگاه‌ها دقیق‌تر شده‌اند.

چرا برخی از پروژه‌های مرکز خانهٔ هوشمند نیاز به کنترل بیشتری بر سیستم‌های اندروید دارند

یک تبلت مصرفی سنتی حول انعطاف‌پذیری طراحی شده است. کاربران برنامه‌های مختلفی را نصب می‌کنند، به سرویس‌های آنلاین دسترسی پیدا می‌کنند و با اکوسیستم گسترده‌ای تعامل دارند.

هاب هوشمند اختصاصی خانه منطق متفاوتی دارد. در بسیاری از پروژه‌های سازنده تجهیزات اصلی، این دستگاه تنها یک هدف اصلی دارد: اجرای قابل اعتماد یک برنامهٔ خاص در محیطی کنترل‌شده.

خریدار ممکن است نیاز داشته باشد صفحه‌نمایش مستقیماً به نرم‌افزار خودش بروز شود، دسترسی غیرضروری کاربران را مسدود کند یا رفتار یکسانی را در تمام واحدهای نصب‌شده حفظ کند. در این سناریوها، معماری اندروید تبدیل به یک تصمیم تجاری می‌شود نه صرفاً یک انتخاب فنی.

و سیستم مبتنی بر اُاس‌پی راه‌حل مبتنی‌بر — کنترل عمیق‌تری بر محیط سیستم فراهم می‌کند، درحالی‌که راه‌حل اندرویدی مجهز‌به — دسترسی به اکوسیستم و خدمات گوگل را فراهم می‌کند. GMS هیچ‌کدام از این دو گزینه به‌طور کلی برتر نیستند. انتخاب مناسب بستگی به نحوهٔ نصب، نگهداری و استفاده از دستگاه دارد.

این تمایز به‌ویژه برای شرکت‌هایی که از حوزه نرم‌افزار وارد سخت‌افزار می‌شوند بسیار مهم است. برای مثال، یک شرکت نرم‌افزار به‌عنوان سرویس (SaaS) که صفحه‌نمایش هوشمند اختصاصی می‌سازد، ممکن است نسبت به قابلیت‌های عمومی اندروید کمتر اهمیت قائل شود و بیشتر به این موضوع توجه کند که آیا سخت‌افزار می‌تواند تجربه نرم‌افزاری آن را به‌طور پایدار ارائه دهد یا خیر.

سه درخواست سازنده اصلی (OEM) دلایل متفاوتی را برای سفارشی‌سازی اندروید نشان می‌دهند.

این نمونه‌ها بازتابی از گفت‌وگوهای واقعی سازندگان اصلی (OEM) با خریداران در بازارهای مختلف هستند. به‌جای تمرکز بر شرکت‌های خاص، این مقایسه بر این نکته تأکید دارد که اهداف پروژه‌های متفاوت چگونه بر انتخاب‌های سیستم اندروید، اجرای نرم‌افزار و نیازهای سفارشی‌سازی سخت‌افزار تأثیر می‌گذارند.

یک ادغام‌کننده سیستم مبتنی بر نروژ درخواست کرد که یک سیستم مبتنی بر اُاس‌پی صفحه‌نمایش مبتنی بر GMS باشد، بدون حالت کیوسک و با راه‌اندازی خودکار فایل‌های APK.

این درخواست به‌وضوح نشان‌دهندهٔ ترجیح محیط اندروید کنترل‌شده است. خریدار به دنبال یک تبلت عمومی نبود، بلکه به دنبال یک ترمینال سخت‌افزاری اختصاصی بود که تجربهٔ نرم‌افزاری آن را می‌شد از سطح سیستم مدیریت کرد.

با این حال، دلیل پشت این درخواست همچنان باید در طول بحث‌های پروژه بررسی شود. یک بدون GMS ممکن است مربوط به انتظارات حریم خصوصی، کنترل برنامه‌ها، سیاست‌های استقرار در محیط‌های سازمانی یا سایر ملاحظات خاص پروژه باشد.

پروژهٔ دوم، که از یک ارائه‌دهندهٔ راه‌حل‌های مراقبت از سالمندان در بلژیک مطرح شده بود، بر اولویت‌های متفاوتی تمرکز داشت. ویژگی‌های درخواستی شامل اتصال ۴G، وای‌فای، حالت کیوسک و تجربهٔ تعاملی ساده‌شده بود.

برخلاف پروژهٔ اول، این خریدار به‌صورت صریح درخواستی برای سیستمی بدون گوگل نداشت. این تفاوت اهمیت دارد، زیرا نشان می‌دهد که سفارشی‌سازی اندروید با تمرکز بر حریم خصوصی لزوماً برای هر کاربردی در حوزهٔ خانهٔ هوشمند یا مراقبت از سالمندان اجباری نیست.

سومین پروژه از یک شرکت نرم‌افزاری آمریکایی با مدل SaaS آمده بود که در حال بررسی راه‌اندازی سخت‌افزار برای سرویس نرم‌افزاری خود بود. نیازمندی‌های اصلی شامل نصب پیش‌از‌اجراي نرم‌افزار، راه‌اندازی حالت کیوسک و شخصی‌سازی برند بود.

برای شرکت‌های نرم‌افزاری که وارد حوزه سخت‌افزار می‌شوند، چالش اغلب انتخاب مشخصات تبلت نیست؛ بلکه چالش بزرگ‌تر، طراحی یک رابط فیزیکی قابل‌اطمینان است که پلتفرم نرم‌افزاری موجود آن‌ها را گسترش می‌دهد.

در این سه نمونه، نیازمندی مشترک لزوماً استفاده از نسخه‌ای از اندروید بدون خدمات گوگل نبود؛ بلکه نیازمندی مشترک، کنترل بیشتر بر نحوه اجرای نرم‌افزار روی سخت‌افزار اختصاصی بود.

معماری مناسب اندروید به این بستگی دارد که چه کسی تجربه نرم‌افزاری را کنترل می‌کند.

تصمیم‌گیری بین سیستم مبتنی بر اُاس‌پی و GMS باید با مدل برنامه‌ها شروع شود، نه با ترجیح سیستم‌عامل.

برای پروژه‌هایی که به‌طور قابل‌توجهی به خدمات گوگل، برنامه‌های مصرفی یا اکوسیستم موجود اندروید وابسته‌اند، اندروید با پشتیبانی از GMS ممکن است به‌دلیل گستردگی بیشتر مزایای عملی ارائه دهد. سازگاری کاربرد .

برای ترمینال‌های اختصاصی که خریدار محیط اجرایی برنامه‌ها را کنترل می‌کند، سیستمی مبتنی بر AOSP ممکن است انعطاف‌پذیری بیشتری ارائه دهد. این موضوع به‌ویژه زمانی اهمیت پیدا می‌کند که دستگاه نیازمند رفتار راه‌اندازی سفارشی، دسترسی محدود کاربران یا ثبات بلندمدت نرم‌افزار باشد.

تفاوت ذکرشده همچنین فرآیند توسعه سازنده اصلی تجهیزات (OEM) را تحت تأثیر قرار می‌دهد. یک پروژه سفارشی‌سازی شده اندروید ممکن است فراتر از تغییر رابط کاربری باشد. این تغییر می‌تواند بر  پیکربندی فریمور ، مدیریت تصویر سیستم، فرآیند انتشار برنامه‌ها , استراتژی به‌روزرسانی از طریق شبکه (OTA) ، و اعتبارسنجی تولید .

بنابراین، سؤال برای خریداران صرفاً این نیست که:

"آیا این تأمین‌کننده می‌تواند تبلت اندرویدی ارائه دهد؟"

سوال مهم‌تر این است:

"آیا این تأمین‌کننده می‌تواند مدل کامل انتشار سخت‌افزار و نرم‌افزار مورد نیاز پروژه ما را پشتیبانی کند؟"

نیازمندی‌های حریم خصوصی باید تأیید شوند، نه اینکه فرض شوند.

درخواست‌هایی مانند «بدون سرویس‌های گوگل»، «بدون دوربین» یا «بدون میکروفون» اغلب توجه را جلب می‌کنند، زیرا ممکن است نشان‌دهنده‌ی انتظارات قوی‌تری در زمینه‌ی حریم خصوصی باشند.

با این حال، انگیزه‌ی دقیق آن‌ها نباید پیش‌فرض در نظر گرفته شود.

در سه پروژه‌ی بررسی‌شده، تنها یک خریدار به‌صورت صریح درخواست محیطی را داشت بدون GMS  سیستم مبتنی بر اُاس‌پی . در دو پروژه‌ی دیگر این نیاز ذکر نشده بود.

این بدان معناست که سفارشی‌سازی متمرکز بر حریم خصوصی در سناریوهای خاصی از خریداران ظاهر می‌شود و نه اینکه نیازی عمومی برای تمام هاب‌های هوشمند خانه باشد.

برای تأمین‌کنندگان و خریداران، بحث‌های اولیه باید روشن کنند که آیا پروژه نیازمند محیط اندرویدی کاملاً کنترل‌شده است، آیا سرویس‌های گوگل ضروری هستند و آیا محدودیت‌های سخت‌افزاری مربوط به انتظارات حریم خصوصی، ملاحظات انطباق یا موقعیت‌یابی محصول است.

تأیید این نیازها در مراحل اولیه می‌تواند کارهای مهندسی غیرضروری را کاهش دهد و تغییرات پرهزینه‌ی پس از شروع توسعه را جلوگیری کند.

استقرار حالت کیوسک در حال تبدیل شدن به پایه‌ای برای نمایشگرهای هوشمند تخصیص‌یافته است

اگرچه سه خریدار اولویت‌های متفاوتی داشتند، اما تمام پروژه‌ها جهت مشابهی داشتند: نمایشگر باید به‌عنوان رابط خدمات تخصیص‌یافته عمل کند.

در اینجا حالت کیوسک این امر اهمیت پیدا می‌کند. این قابلیت امکان اجرای خودکار برنامه‌ها، محدودسازی دسترسی کاربران و تجربه‌ای یکپارچه پس از راه‌اندازی را فراهم می‌سازد.

در سیستم‌های مراقبت از سالمندان، هاب‌های هوشمند خانه و محصولات سخت‌افزاری مبتنی بر نرم‌افزار، نمایشگر دیگر صرفاً یک صفحه‌نمایش اندروید نیست. بلکه بخشی از یک سیستم خدمات کامل می‌شود.

این امر همچنین نیازهای جدیدی را برای تأمین‌کنندگان اصلی (OEM) ایجاد می‌کند. پشتیبانی از این پروژه‌ها نیازمند درکی فراتر از مشخصات سخت‌افزاری است و شامل یکپارچه‌سازی نرم‌افزار و سخت‌افزار توسعه، تولید و عملیات بلندمدت می‌شود.

قبل از آغاز پروژهٔ نمایشگر هوشمند OEM، این تصمیمات را ابتدا تعریف کنید.

قبل از درخواست یک نمایشگر اندروید OEM خریداران باید ابتدا چهار مرز پروژه را روشن سازند:

اینکه آیا برنامه به سرویس‌های گوگل وابسته است، چقدر کنترل بر سیستم اندروید لازم است، آیا محدودیت‌های مربوط به حریم خصوصی وجود دارد و پس از راه‌اندازی دستگاه چگونه مدیریت می‌شود.

این تصمیمات مستقیماً بر پلتفرم سخت‌افزاری مناسب، معماری اندروید، میزان سفارشی‌سازی و نیازهای توانایی تأمین‌کننده تأثیر می‌گذارند.

بنابراین ارزیابی تأمین‌کننده نباید فراتر از مشخصات پردازنده، حافظه یا نمایشگر باشد. خریداران باید اطمینان حاصل کنند که شریک OEM قادر به پشتیبانی از سفارشی‌سازی سیستم راه‌اندازی برنامه‌ها، مدیریت فرم‌ور، و نگهداری بلندمدت محصول است.

سه درخواست واقعی مورد بحث در این مقاله این موضوع را ثابت نمی‌کنند که هر پروژه خانه هوشمند به یک نمایشگرهای غیرگوگلی نیاز دارد. بلکه تغییری عملی‌تر را نشان می‌دهند: خریداران اکنون به‌طور فزاینده‌ای سخت‌افزار را بر اساس میزان پشتیبانی آن از استراتژی نرم‌افزاری خود ارزیابی می‌کنند.

شرکت‌هایی که هاب‌های خانه هوشمند توسعه می‌دهند , نمایشگرهای مراقبت از سالمندان یا محصولات سخت‌افزاری که توسط نرم‌افزار راه‌اندازی می‌شوند، تعیین به‌موقع معماری مناسب اندروید می‌تواند خطر توسعه را کاهش دهد و مسیر استقراری قابل‌اطمینان‌تر ایجاد کند.

اگر قصد اجرای پروژه‌ای مبتنی بر اندروید برای نمایشگر هوشمند را دارید، تعیین به‌موقع معماری مناسب سیستم می‌تواند به کاهش خطرات توسعه و جلوگیری از هزینه‌های سفارشی‌سازی غیرضروری کمک کند.

تیم ما می‌تواند نیازهای کاربردی شما، گزینه‌های معماری اندروید (AOSP یا GMS) و نیازهای سفارشی‌سازی سخت‌افزاری را ارزیابی کند تا رویکرد استقرار مناسبی را شناسایی کند.

با تیم ما تماس بگیرید برای بحث درباره نیازهای پروژه‌تان یا ارسال درخواست شما برای راه‌حل نمایشگر اندروید سفارشی.