Jak si projekty OEM chytrých domácích centrálních jednotek vybírají mezi architekturami Androidu AOSP a GMS

Když společnosti vyvíjejí chytrou domácí centrálu , architektura systému Android je často rozhodnuta mnohem dříve než fáze výroby hardwaru.

Na první pohled může displej domácí centrály vypadat jako standardní dotykové zařízení. Pro mnoho projektů B2B však displej není pouze obyčejnou obrazovkou s operačním systémem. Stává se specializovaným rozhraním propojujícím softwarové služby, uživatele a propojené domácí prostředí.

Právě proto někteří zákazníci začínají klást hlubší otázky ohledně Architektuře Android : Mělo by zařízení používat standardní Android s Google Mobile Services ( GMS )? Vyžaduje projekt systém založený na AOSP bez služeb Google? Jak velkou kontrolu potřebuje kupující nad nasazováním softwaru a chováním zařízení? AOSP -založený systém bez služeb Google? Jak velkou kontrolu potřebuje kupující nad nasazováním softwaru a chováním zařízení?

Tři skutečné požadavky OEM výrobců domácích center pro chytré domácnosti z Norska, Belgie a Spojených států poskytují užitečné příklady. Nezastupují celý trh chytrých domácností, ale ukazují, jak různí kupující hodnotí požadavky na systém na základě svých vlastních cílů nasazení.

Důležitý signál není ten, že každý projekt chytrého domácího centra se posouvá k řešením s de-googled display . Místo toho tyto požadavky ukazují, že kupující jsou stále konkrétnější ohledně kontroly softwaru, nasazování aplikací a přizpůsobení zařízení.

Proč některé projekty chytrých domácích center potřebují větší kontrolu nad systémy Android

Tradiční spotřebitelský tablet je navržen s ohledem na flexibilitu. Uživatelé instalují různé aplikace, přistupují k online službám a interagují s rozsáhlým ekosystémem.

Specializované chytré domácí centrum funguje podle jiné logiky. U mnoha projektů výrobců originálních zařízení má zařízení jeden primární účel: spolehlivě provozovat konkrétní aplikaci v řízeném prostředí.

Zákazník může potřebovat, aby se displej spouštěl přímo do jeho vlastního softwaru, zabránil nepotřebnému uživatelskému přístupu nebo zajistil konzistentní chování napříč nasazenými jednotkami. V těchto scénářích se architektura Android stává obchodním rozhodnutím, nikoli pouze technickou volbou.

An AOSP -založené řešení může poskytnout hlubší kontrolu nad systémovým prostředím, zatímco GMS -povolené řešení pro Android poskytuje přístup k ekosystému a službám společnosti Google. Žádná z těchto možností není univerzálně lepší. Správná volba závisí na tom, jak bude zařízení nasazováno, udržováno a využíváno.

Toto rozlišení je zvláště důležité pro společnosti, které vstupují do hardwarového segmentu z pozice softwarových firem. Například SaaS společnost vyvíjející specializovaný chytrý displej může mít menší zájem o obecnou funkčnost systému Android a větší zájem o to, zda hardware dokáže spolehlivě poskytnout požadované softwarové prostředí.

Tři žádosti výrobců ukazují různé důvody přizpůsobení systému Android

Tyto příklady odrážejí skutečné diskuse výrobců s nákupními týmy na různých trzích. Místo zaměření na jednotlivé společnosti srovnání zdůrazňuje, jak se různé cíle projektů odrážejí ve volbě systému Android, nasazení softwaru a požadavcích na přizpůsobení hardwaru.

Jeden systémový integrátor se sídlem v Norsku požadoval displej založený na AOSP bez GMS , spolu s hardwarovými omezeními, jako je odstranění komponent kamery a mikrofonu. Projekt také vyžadoval režim kiosku s automatickým spuštěním APK.

Tato žádost jasně ukazuje preferenci řízeného prostředí Android. Zakoupený výrobek nebyl určen jako univerzální tablet, ale jako specializovaný hardwarový terminál, kde by bylo možné spravovat softwarové prostředí na úrovni systému.

Přesto by měl být důvod za touto žádostí stále ověřen během projektových diskusí. Požadavek na Bez GMS může souviset s očekáváními ohledně soukromí, kontroly aplikací, podnikových nasazovacích politik nebo jiných projektově specifických aspektů.

Druhý projekt od belgického poskytovatele řešení pro péči o seniory se zaměřoval na jiné priority. Požadované funkce zahrnovaly připojení 4G, WiFi, režim kiosku a zjednodušené interakční prostředí.

Na rozdíl od prvního projektu tento zákazník explicitně nepožadoval systém bez Google služeb. Tento rozdíl je významný, protože ukazuje, že přizpůsobení Androidu zaměřené na soukromí není automaticky vyžadováno pro každou chytrou domácnost nebo aplikaci pro péči o seniory.

Třetí projekt pocházel od americké společnosti poskytující služby SaaS, která zkoumala nasazení hardwaru pro svou softwarovou službu. Hlavní požadavky zahrnovaly předinstalaci aplikací, nasazení kiosků a přizpůsobení značky.

Pro softwarové společnosti, které se přesouvají do oblasti hardwaru, často není výzvou výběr specifikace tabletu. Větší výzvou je vytvořit spolehlivé fyzické rozhraní, které rozšiřuje jejich stávající softwarovou platformu.

Ve všech třech uvedených příkladech nebyl společný požadavek nutně de-Googled Android. Společným požadavkem byla vyšší míra kontroly nad tím, jak běží software na specializovaném hardwaru.

Správná architektura Androidu závisí na tom, kdo ovládá softwarový zážitek.

Rozhodnutí mezi AOSP a GMS měl by začít modelem aplikace, nikoli preferencí operačního systému.

U projektů, které silně závisí na službách Google, spotřebitelských aplikacích nebo stávající ekosystému Androidu, může Android s povolenými službami GMS poskytnout praktické výhody díky širšímu kompatibilita aplikace .

Pro vyhrazené terminály, kde zákazník ovládá prostředí aplikací, může systém založený na AOSP nabídnout větší flexibilitu. To je zvláště důležité, pokud zařízení vyžaduje přizpůsobené chování při spuštění, omezený přístup uživatelů nebo dlouhodobou konzistenci softwaru.

Rozdíl také ovlivňuje proces vývoje OEM. Přizpůsobený projekt Androidu může zahrnovat více než jen změnu uživatelského rozhraní. Může ovlivnit  konfiguraci firmware , správu systémových obrazů, pracovní postup nasazení aplikací , Strategii aktualizací OTA , a validace výroby .

Pro zákazníky se proto otázka neklade jednoduše takto:

"Může tento dodavatel dodat tablet s Androidem?"

Důležitější otázkou je:

"Může tento dodavatel podporovat kompletní model nasazení hardwaru a softwaru, který náš projekt vyžaduje?"

Požadavky na ochranu soukromí je třeba ověřit, nikoli předpokládat

Požadavky jako „bez GMS“, „bez kamery“ nebo „bez mikrofonu“ často upoutávají pozornost, protože mohou naznačovat vyšší očekávání ohledně soukromí.

Přesné motivace však nesmí být předpokládány.

Ve třech přezkoumaných projektech pouze jeden zakázkař výslovně požadoval Bez GMS  AOSP prostředí. Ostatní dva projekty tento požadavek nezmínily.

To znamená, že přizpůsobení zaměřené na soukromí se objevuje pouze v konkrétních scénářích zakázkařů, nikoli jako univerzální požadavek pro všechny chytré domácí centrály.

Pro dodavatele i zakázkaře by měly být rané diskuze zaměřeny na upřesnění, zda projekt vyžaduje zcela kontrolované prostředí Android, zda jsou nutné služby Google a zda jsou hardwarová omezení spojena s očekáváními ohledně soukromí, požadavky na soulad s předpisy nebo pozicováním produktu.

Ověření těchto požadavků v rané fázi může snížit zbytečnou inženýrskou práci a zabránit drahým změnám po zahájení vývoje.

Nasazení režimu kiosku se stává základem pro specializované chytré displeje

Ačkoli tři zakázky měly odlišné priority, všechny projekty směřovaly stejným směrem: displej musel fungovat jako specializované rozhraní služby.

Právě zde režim kiosku získává na významu. Umožňuje automatické spouštění aplikací, omezený přístup uživatelů a konzistentní zážitek po nasazení.

U systémů pro péči o seniory, chytrých domácností a hardwarových produktů řízených softwarem již displej není jen obyčejnou obrazovkou s Androidem. Stává se součástí kompletního služebního systému.

To také vytváří nové požadavky na dodavatele OEM. Podpora těchto projektů vyžaduje nejen porozumění technickým specifikacím hardwaru, ale také integrace softwaru a hardwaru v oblasti vývoje, výroby a dlouhodobého provozu.

Než začnete projekt chytrého displeje OEM, nejprve definujte tyto rozhodnutí

Než požádáte o Android display OEM řešení, měl by zakoupený nejprve objasnit čtyři hranice projektu:

Zda aplikace závisí na službách Google, jak velkou kontrolu je třeba mít nad systémem Android, zda existují omezení související s ochranou soukromí a jak bude zařízení spravováno po nasazení.

Tyto rozhodnutí přímo ovlivňují vhodnou hardwarovou platformu, architekturu systému Android, rozsah přizpůsobení a požadavky na schopnosti dodavatele.

Hodnocení dodavatele by proto mělo jít dál než pouhé specifikace procesoru, paměti nebo displeje. Zakoupení by mělo potvrdit, zda partner OEM dokáže podporovat přizpůsobení systému nasazení aplikací, správu firmwaru a dlouhodobou údržbu produktu.

Tři skutečné požadavky diskutované v tomto článku neprokazují, že každý projekt chytrého domu vyžaduje de-googled display . Ukazují spíše praktičtější změnu: zakoupení stále více hodnotí hardware podle toho, jak dobře podporuje jejich softwarovou strategii.

Pro firmy vyvíjející centrály pro chytrý dům , displeje pro péči o starší lidi nebo softwarově řízené hardwarové produkty – včasná definice správné architektury Androidu může snížit rizika vývoje a zajistit spolehlivější nasazovací cestu.

Pokud plánujete projekt chytrého displeje založeného na Androidu, včasná definice vhodné systémové architektury může pomoci snížit rizika vývoje a vyhnout se nepotřebným nákladům na přizpůsobení.

Náš tým vám může pomoci posoudit požadavky vaší aplikace, možnosti architektury Androidu (AOSP nebo GMS) a potřeby hardwarového přizpůsobení, abychom určili vhodný nasazovací přístup.

Kontaktujte naše tým abychom probrali požadavky vašeho projektu nebo abyste odeslali svůj dotaz týkající se přizpůsobeného řešení displeje pro Android.