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

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

На пръв поглед умният домашен хъб може да изглежда като стандартно устройство с докосваем екран. Въпреки това, за много B2B проекти дисплеят не е просто екран с операционна система. Той става специализиран интерфейс, свързващ софтуерни услуги, потребители и свързани домашни среди.

Затова някои купувачи започват да задават по-дълбоки въпроси относно Android архитектура : Трябва ли устройството да използва стандартен Android с Google Mobile Services ( GMS )? Проектът изисква ли система, базирана на AOSP без Google услуги? Колко контрол има купувачът върху разпространението на софтуера и поведението на устройството?

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

Важният сигнал не е, че всеки проект за умен домашен хъб се движи към дисплеи без Google решения. Вместо това тези заявки показват, че купувачите стават по-конкретни относно контрола върху софтуера, разпространението на приложения и персонализацията на устройствата.

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

Традиционният потребителски таблет е проектиран с оглед на гъвкавост. Потребителите инсталират различни приложения, получават достъп до онлайн услуги и взаимодействат с широк екосистемен набор.

Специализираната умна домашна хъб следва различна логика. За много проекти на производители на оригинално оборудване (OEM) устройството има една основна цел: да изпълнява конкретно приложение надеждно в контролирана среда.

Покупателят може да има нужда дисплейът да стартира директно в собственото му софтуерно решение, да предотвратява ненужен достъп от страна на потребителите или да осигурява последователно поведение между всички разгърнати единици. В тези сценарии архитектурата на Android става бизнес решение, а не само технически избор.

Един AOSP -базираното решение може да осигури по-дълбок контрол върху системната среда, докато GMS -активираното решение с Android осигурява достъп до екосистемата и услугите на Google. Нито един от двата варианта не е универсално по-добър. Правилният избор зависи от начина, по който устройството ще бъде разгърнато, поддържано и използвано.

Това различие е особено важно за компании, които преминават от софтуерни към хардуерни решения. Например една SaaS компания, която разработва специализиран интелигентен дисплей, може да проявява по-малко интерес към общата функционалност на Android и повече – към това дали хардуерът може надеждно да предлага нейния софтуерен потребителски опит.

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

Тези примери отразяват реални дискусии между производители на оригинално оборудване и покупатели в различни пазари. Вместо да се фокусираме върху отделни компании, сравнението подчертава как различните цели на проектите влияят върху избора на Android системата, разпространението на софтуера и изискванията за персонализиране на хардуера.

Един норвежки системен интегратор поиска AOSP дисплей, базиран на GMS без киосков режим с автоматично стартиране на APK файлове.

Това искане ясно показва предпочитание към контролирана Android среда. Покупателят не търсеше таблет за обща употреба, а специализиран хардуерен терминал, при който софтуерното изживяване може да се управлява на системно ниво.

Все пак причината за това искане трябва да бъде проверена по време на проектните дискусии. Изискването за GMS-free може да е свързано с очаквания за поверителност, контрол върху приложенията, политики за внедряване в корпоративна среда или други проектоспецифични съображения.

Вторият проект, от доставчик на решения за грижа за възрастни в Белгия, се фокусираше върху различни приоритети. Изискваните функции включваха 4G свързаност, WiFi, киосков режим , и опростено взаимодействие.

За разлика от първия проект, този покупател не поиска изрично дегуглифицирана система. Тази разлика е значима, защото показва, че Android персонализацията с акцент върху поверителността не е автоматично задължителна за всяко приложение за умен дом или грижа за възрастни.

Третият проект идва от американска SaaS компания, която изследва разгъване на хардуер за своя софтуерен сервис. Основните изисквания включваха предварителна инсталация на приложение, разгъване в киосков режим и персонализация според бранда.

За софтуерни компании, които преминават към хардуер, предизвикателството често не е изборът на спецификация за таблет. По-голямото предизвикателство е създаването на надежден физически интерфейс, който разширява вече съществуващата им софтуерна платформа.

В тези три примера общото изискване не беше непременно Android без Google. Общото изискване беше по-голям контрол върху начина, по който софтуерът работи на специализиран хардуер.

Правилната Android архитектура зависи от това кой контролира потребителския софтуерен опит.

Решението между AOSP и GMS трябва да започне с модела на приложението, а не с предпочитанията към операционната система.

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

За специализирани терминали, при които купувачът контролира средата за изпълнение на приложенията, система, базирана на AOSP, може да предложи по-голяма гъвкавост. Това е особено важно, когато устройството изисква персонализирано поведение при стартиране, ограничения достъп за потребителите или дългосрочна последователност на софтуера.

Разликата засяга и процеса на разработка от страна на производителя на оригинално оборудване (OEM). Персонализиран проект за Android може да включва повече от промяна на потребителския интерфейс. Той може да повлияе на  конфигурацията на фърмуерите , управлението на системния образ, работния процес за разпространяване на приложенията , Стратегията за актуализации чрез OTA , и валидиране на производството .

За купувачите въпросът следователно не е просто:

"Този доставчик може ли да предостави планшет с Android?"

По-важният въпрос е:

"Този доставчик може ли да поддържа пълната модел за разграждане на хардуера и софтуера, изисквана от нашия проект?"

Изискванията за поверителност трябва да бъдат проверени, а не предполагани

Заявки като "без GMS", "без камера" или "без микрофон" често привличат внимание, тъй като могат да показват по-високи очаквания относно поверителността.

Все пак точната мотивация не трябва да се предполага.

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

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

За доставчиците и купувачите ранните дискусии трябва да изяснят дали проектът изисква напълно контролирана Android-околна среда, дали Google услуги са задължителни и дали ограниченията върху хардуера са свързани с очакванията за поверителност, изисквания за съответствие или позициониране на продукта.

Потвърждаването на тези изисквания на ранен етап може да намали ненужната инженерна работа и да избегне скъпи промени след започване на разработката.

Разглеждането на Kiosk Deployment става основа за специализирани умни дисплеи

Въпреки че тримата купувачи имаха различни приоритети, всички проекти споделяха подобна насока: дисплеят трябваше да функционира като специализиран интерфейс за услуга.

Тук е местото киосков режим става важно. То позволява автоматично стартиране на приложения, ограничения достъп за потребителите и последователен потребителски опит след разграждане.

За системи за грижа за възрастни, умни домашни хъбове и хардуерни продукти, задвижвани от софтуер, дисплеят вече не е само Android екран. Той става част от пълна система за услуги.

Това също създава нови изисквания към OEM доставчиците. Поддръжката на тези проекти изисква разбиране не само на техническите спецификации на хардуера, но и интеграция на софтуер и хардуер по целия жизнен цикъл – от разработката и производството до дългосрочната експлоатация.

Преди да започнете OEM проект за умен дисплей, първо дефинирайте тези решения

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

Дали приложението зависи от Google услуги, колко контрол е необходим върху Android системата, дали съществуват ограничения, свързани с поверителността, и как ще се управлява устройството след внедряването му.

Тези решения директно влияят върху подходящата хардуерна платформа, архитектурата на Android, обхвата на персонализацията и изискванията към доставчика.

Оценката на доставчик затова трябва да надхвърля спецификациите за процесор, памет или дисплей. Покупателите трябва да потвърдят дали партньорът OEM може да поддържа персонализация на системата , разпространение на приложения, управление на фърмуер и дългосрочно поддръжка на продукта.

Трите реални заявки, обсъдени в тази статия, не доказват, че всеки проект за умен дом изисква дисплеи без Google . Те демонстрират по-практична промяна: покупателите все повече оценяват хардуера според това колко добре поддържа софтуерната им стратегия.

За компании, които разработват хабове за умен дом , дисплеи за грижа за възрастни или софтуерно-управлявани хардуерни продукти, определянето на правилната Android архитектура още в началото може да намали рисковете от разработка и да осигури по-надежден път за внедряване.

Ако планирате проект за умен дисплей, базиран на Android, определянето на подходящата системна архитектура още в началото може да помогне за намаляване на рисковете от разработка и избягване на ненужни разходи за персонализация.

Екипът ни може да помогне при оценката на изискванията към вашето приложение, вариантите за Android архитектура (AOSP или GMS) и нуждите от персонализация на хардуера, за да се определи подходящият начин за внедряване.

Свържете се с нашия екип за обсъждане на изискванията към вашия проект или изпращане на заявката ви за персонализирано Android решение за дисплей.