Како OEM проекти за интелигентни домашни централи избираат помеѓу AOSP и GMS Android архитектури

Кога компаниите развиваат смарт хаб за дома , архитектурата на Android системот често се одлучува многу порано од фазата на производство на хардверот.

На прв поглед, дисплејот на хабот за дома може да изгледа како стандарден екран со тачен интерфејс. Меѓутоа, за многу B2B проекти, дисплејот не е само екран со оперативен систем. Тој станува посебен интерфејс што ги поврзува софтверските услуги, корисниците и поврзаните домашни средини.

Затоа некои купувачи започнуваат да поставуваат по-длабоки прашања за Android архитектура : Дали уредот треба да користи стандарден Android со Google Mobile Services ( GMS )? Дали проектот бара систем базиран на AOSP без Google услуги? Колку контрола има купувачот врз деплојментот на софтверот и однесувањето на уредот?

Три вистински OEM-баранја за домашни хабови од Норвешка, Белгија и Соединетите Американски Држави претставуваат корисни примери. Тие не го претставуваат целиот пазар на интелигентни домови, но покажуваат како различните купувачи ја проценуваат потребата од системот според своите цели за имплементација.

Важниот сигнал не е дека секој проект за интелигентен дом се движи кон дез-гуглизирани дисплеј решенија. Наместо тоа, овие баранја покажуваат дека купувачите стануваат поспецифични во однос на контролата на софтверот, имплементацијата на апликации и прилагодувањето на уредите.

Зошто некои проекти за хабови на интелигентни домови имаат потреба од повеќе контрола врз Android-системите

Традиционалниот потрошувачки таблет е дизајниран околу флексибилноста. Корисниците инсталираат различни апликации, пристапуваат до онлајн услуги и комуницираат со широк екосистем.

Посебниот хаб за интелигентен дом следи друга логика. За многу OEM-проекти, уредот има една примарна цел: да извршува специфична апликација доверливо во контролирана средина.

Купувачот може да има потреба дисплејот да стартува директно во неговиот сопствен софтвер, да спречи непотребен пристап на корисниците или да одржи конзистентно однесување помеѓу сите инсталирани единици. Во овие сценарија, Android архитектурата станува бизнис одлука, а не само технички избор.

И тоа е AOSP -базирано решение може да обезбеди подлабока контрола врз системската средина, додека Android-омогудено решение обезбедува пристап до Google-овиот екосистем и услуги. GMS ниту една од опциите не е универзално подобра. Правилниот избор зависи од тоа како ќе биде распоредено, одржувано и користено уредот.

Ова разлика е особено важна за компании кои влегуваат во хардверот од софтверски позадини. На пример, една SaaS компанија што гради посебен интелигентен дисплеј може помалку да се грижи за општата функционалност на Android, а повеќе за тоа дали хардверот може доверливо да достави неговото софтверско искуство.

Три барања од страна на OEM покажуваат различни причини зад прилагодувањето на Android

Овие примери ги одразуваат вистинските дискусии на OEM-производители со купувачи низ различни пазари. Споредба не се фокусира на поединечни компании, туку го истакнува како различните цели на проектите влијаат врз изборот на Android системот, дистрибуцијата на софтверот и барањата за апаратска персонализација.

Еден интегратор на системи базиран во Норвешка побарал AOSP -базиран дисплеј без GMS , заедно со апаратски ограничувања како што се отстранувањето на компонентите за камера и микрофон. Проектот исто така побарал режим на киоск со автоматско стартување на APK-файлови.

Оваа побарување јасно покажува предност кон контролиран Android-околу. Купувачот не барал таблет за општа употреба, туку посебен хардверски терминал каде софтверското искуство може да се управува од системско ниво.

Сепак, причината зад побарувањето треба да се потврди во текот на дискусиите за проектот. Барањето за GMS-free може да е поврзано со очекувања за приватност, контрола на апликации, политики за вградување во корпоративна средина или други специфични за проектот размислувања.

Вториот проект, од доставувач на решенија за грижа за постари лица базиран во Белгија, се фокусирал на други приоритети. Бараните функции вклучуваат 4G поврзаност, WiFi, режим на киоск , и поедноставено искуство во интеракцијата.

За разлика од првиот проект, овој купувач не барал експлицитно де-Гуглизиран систем. Ова разлика е значајна бидејќи покажува дека персонализацијата на Android со фокус врз приватноста не е автоматски потребна за секоја примена на паметни домашни уреди или решенија за грижа за постари лица.

Третиот проект потекнувал од американска SaaS компанија која истражувала дистрибуција на хардвер за нејзината софтверска услуга. Главните барања вклучувале прединсталирана апликација, дистрибуција во киоск-режим и прилагодување според брендот.

За софтверските компании кои влегуваат во производството на хардвер, предизвикот често не е изборот на спецификациите на таблетот. Поголемиот предизвик е создавањето на доверлив физички интерфејс кој ќе го прошири нивниот постоен софтверски платформа.

На овие три примери, заедничкиот барање не беше потребата од Android без Google. Заедничкиот барање беше поголема контрола врз тоа како софтверот работи на посебна хардверска платформа.

Правилната Android архитектура зависи од тоа кој го контролира софтверското искуство.

Одлуката помеѓу AOSP и GMS треба да започне со моделот на апликација, а не со предпочитаниот оперативен систем.

За проекти кои силно зависат од Google услуги, потрошувачки апликации или од постојачкиот Android екосистем, Android со GMS може да обезбеди практични предности поради поширока компатибилност со апликации .

За посебни терминали каде што купувачот го контролира апликацискиот окружување, систем заснован на AOSP може да понуди повеќе флексибилност. Ова е особено релевантно кога уредот има потреба од прилагодено стартување, ограничена корисничка пристапност или долго-трајна софтверска конзистентност.

Разликата исто така влијае врз процесот на развој од страна на OEM. Прилагоден Android проект може да вклучи повеќе од менување на корисничкиот интерфејс. Тоа може да влијае врз  конфигурација на фирмверот , управување со системските слики, работен тек за разместување на апликации , Стратегија за OTA ажурирање , и валидација во производството .

За купувачите, прашањето затоа не е само:

"Дали овој доставувач може да обезбеди Андроид таблет?"

Поматното прашање е:

"Дали овој доставувач може да поддржи целосниот модел за разместување на хардвер и софтвер потребен за нашиот проект?"

Барањата за приватност треба да се потврдат, а не да се претпоставуваат

Барањата како „без GMS“, „без камера“ или „без микрофон“ често привлекуваат внимание бидејќи може да укажуваат на посилни очекувања за приватност.

Сепак, точната мотивација не треба да се претпоставува.

Во трите прегледани проекти, само еден купувач јасно побарал GMS-free  AOSP околина. Другите два проекти не споменале ова барање.

Ова значи дека прилагодувањата со фокус врз приватност се појавуваат во специфични сценарија на купувачи, а не претставуваат универзално барање за сите интелигентни домашни хабови.

За доставувачите и купувачите, раните дискусии треба да ги појаснат дали проектот бара целосно контролирана Android околина, дали Google услугите се потребни и дали ограничувањата на хардверот се поврзани со очекувањата за приватност, размислувања за соодветност или позиционирање на производот.

Потврдувањето на овие барања на рана фаза може да намали непотребна инженерска работа и да избегне скапи промени откако ќе започне развојот.

Имплементацијата на киоскови станува основа за посебни интелигентни дисплеи

Иако трите купувачи имаа различни приоритети, сите проекти имаа слична насока: дисплејот мора да функционира како посебен интерфејс за услуга.

Тука режим на киоск станува важно. Овозможува автоматско стартување на апликации, ограничен пристап на корисниците и конзистентно искуство по доделувањето.

За системите за грижа за поголемите возрасни, центри за интелигентни домови и хардверски производи со софтверска поддршка, дисплејот повеќе не е само Android екран. Тој станува дел од целосен систем за услуги.

Ова исто така создава нови барања за OEM доставувачите. Поддршката за овие проекти бара разбирање не само на техничките спецификации на хардверот, туку и интеграција на софтвер и хардвер во фазите на развој, производство и долготрајна операција.

Пред да започнете OEM проект за интелигентен дисплеј, прво дефинирајте ги овие одлуки

Пред да побарате Android дисплеј OEM решение, купувачите прво треба да ги појаснат четирите граници на проектот:

Дали апликацијата зависи од Google услуги, колку контрола е потребна врз Android системот, дали постојат ограничувања поврзани со приватноста и како ќе се управува уредот по дистрибуцијата.

Овие одлуки директно влијаат врз соодветната хардверска платформа, Android архитектурата, опсегот на персонализација и барањата кон капацитетите на доставувачот.

Затоа, проценката на доставувачот треба да надмине спецификации за процесор, меморија или дисплеј. Купувачите треба да потврдат дали OEM партнерот може да обезбеди прилагодување на системот , дистрибуција на апликации, управување со фермвер и долготрајно одржување на производот.

Трите вистински барања разгледани во овој член не докажуваат дека секој проект за паметни домови бара дез-гуглизирани дисплеј . Тие демонстрираат попрактична промена: купувачите сѐ повеќе го проценуваат хардверот според тоа колку добро поддржува нивната софтверска стратегија.

За компании кои развиваат паметни домски хабови , прикази за старији луѓе или софтверски потикнати хардверски производи, дефинирањето на правилната Android архитектура во рана фаза може да го намали ризикот од развој и да создаде посигурен пат за доделување.

Ако планирате проект за интелигентен приказ базиран на Android, дефинирањето на правилната системска архитектура во рана фаза може да помогне да се намали ризикот од развој и да се избегнат непотребни трошоци за прилагодување.

Нашиот тим може да ви помогне да ги процените барањата за вашата апликација, опциите за Android архитектура (AOSP или GMS) и потребите за прилагодување на хардверот за да се идентификува соодветен пристап за доделување.

Контактирајте го нашиот тим за да ги разгледаме барањата за вашиот проект или да поднесете барање за прилагодено решение за Android приказ.