Hogyan választanak okos otthonközpontok OEM-projektjei az AOSP és a GMS Android-architektúrák között

Amikor vállalatok egy intelligens otthoni központot fejlesztenek, az Android rendszerarchitektúrát gyakran jóval korábban döntik el, mint a hardver gyártásának szakasza.

Első pillantásra egy otthoni központ megjelenítője úgy néz ki, mint egy szokványos érintőképernyős eszköz. Azonban sok B2B-projekt esetében a megjelenítő nem csupán egy képernyő operációs rendszerrel. Egy speciális felületként funkcionál, amely összeköti a szoftveres szolgáltatásokat, a felhasználókat és az összekapcsolt otthoni környezetet.

Ezért néhány vásárló mélyebb kérdéseket kezd feltenni a Android architektúra : Használja-e az eszköz a szokványos Android rendszert Google Mobile Services ( GMS )? Igényli-e a projekt egy Google-szolgáltatások nélküli, AOSP-alapú rendszert? Mekkora mértékű szoftvertelepítési és eszközviselkedés-vezérlésre van szüksége a vevőnek? AOSP – alapú rendszer Google-szolgáltatások nélkül? Mekkora mértékű szoftvertelepítési és eszközviselkedés-vezérlésre van szüksége a vevőnek?

Három valós otthoni központ (home hub) OEM-kérelmet küldtek Norvégiából, Belgiumból és az Egyesült Államokból, amelyek hasznos példákat nyújtanak. Ezek nem tükrözik az egész okos otthoni piacot, de bemutatják, hogyan értékelik különböző vevők a rendszerkövetelményeket saját telepítési céljaik alapján.

A fontos jelzés nem az, hogy minden okos otthoni projekt a de-googled display megoldások felé tart. Ehelyett ezek a kérelmek azt mutatják, hogy a vevők egyre pontosabban határozzák meg a szoftvervezérlés, az alkalmazások telepítése és az eszközök testreszabása iránti igényüket.

Miért van néhány okos otthoni központ (home hub) projektnek több ellenőrzésre szüksége az Android-rendszerek felett

Egy hagyományos fogyasztói tablet a rugalmasságra épül. A felhasználók különböző alkalmazásokat telepítenek, online szolgáltatásokhoz férnek hozzá, és széles körű ökoszisztémával lépnek kapcsolatba.

Egy dedikált okos otthon központ más logikát követ. Sok OEM-projektnél az eszköznek egy fő feladata van: egy meghatározott alkalmazás megbízható futtatása ellenőrzött környezetben.

A vevőnek szüksége lehet arra, hogy a kijelző közvetlenül a saját szoftverükbe induljon, megakadályozza a felesleges felhasználói hozzáférést, vagy konzisztens működést biztosítson az üzembe helyezett egységek között. Ezekben az esetekben az Android-architektúra üzleti döntés, nem csupán technikai választás.

Egy AOSP -alapú megoldás mélyebb irányítást biztosít a rendszerkörnyezet fölött, míg egy GMS -engedélyezett Android-megoldás hozzáférést nyújt a Google ökoszisztémájához és szolgáltatásaihoz. Egyik megoldás sem univerzálisan jobb. A megfelelő választás attól függ, hogyan helyezik üzembe, karbantartják és használják az eszközt.

Ez a különbség különösen fontos azok számára a vállalatok számára, amelyek szoftveres háttérből lépnek be a hardverpiacra. Például egy SaaS-cég, amely különleges okos kijelzőt fejleszt, kevesebbet törődhet az általános Android-funkcionalitással, és jobban érdekli őt, hogy a hardver megbízhatóan képes-e nyújtani a szoftveres élményt.

Három OEM-kérés különböző okokat mutat be az Android testreszabása mögött

Ezek a példák valós OEM-tárgyalásokat tükröznek vásárlókkal különböző piacokon. Az egyes cégek helyett a hasonlítás arra világít rá, hogyan befolyásolják a különböző projektcélok az Android-rendszer kiválasztását, a szoftver telepítését és a hardver testreszabásának követelményeit.

Egy norvégiai rendszerintegrátor kérte egy AOSP -alapú kijelzőt GMS nélkül, együtt olyan hardveres korlátozásokkal, mint a kamera- és mikrofonalkatrészek eltávolítása. A projekt szükséges feltétele volt a kioszk üzemmód az automatikus APK-indítással.

Ez a kérés egyértelműen mutatja az irányított Android-környezet iránti preferenciát. A vevő nem általános célú tablet eszközt, hanem dedikált hardverterminált keresett, ahol a szoftveres élményt rendszerszinten lehetett kezelni.

Ugyanakkor a kérés mögött álló okot továbbra is ellenőrizni kell a projektbeszélgetések során. Egy GMS-mentes követelmény kapcsolódhat adatvédelmi elvárásokhoz, alkalmazás-vezérléshez, vállalati telepítési szabályzatokhoz vagy más, projektspecifikus megfontolásokhoz.

A második projekt egy belga székhelyű időskorúak ellátását segítő megoldást nyújtó cég részéről érkezett, és más prioritásokra helyezte a hangsúlyt. A kért funkciók között szerepelt a 4G-kapcsolat, a WiFi, kioszk üzemmód , valamint egy leegyszerűsített interakciós felület.

Ellentétben az első projekttel, ebben az esetben a vevő nem kérte kifejezetten a Google-mentes rendszert. Ez a különbség jelentős, mivel azt mutatja, hogy az adatvédelemre fókuszáló Android-testreszabás nem feltétlenül szükséges minden okos otthoni vagy időskorúak ellátását célzó alkalmazásnál.

A harmadik projekt egy amerikai székhelyű SaaS-cégtől érkezett, amely hardveres telepítést vizsgált szoftveres szolgáltatásához. A fő követelmények közé tartozott az alkalmazások előtelepítése, a kiosk-telepítés és a márkaközönség testreszabása.

A szoftvercégek számára, amelyek hardveres termékekbe lépnek be, gyakran nem a tablet-specifikáció kiválasztása jelenti a kihívást. A nagyobb kihívás egy megbízható fizikai felület létrehozása, amely kiterjeszti meglévő szoftverplatformjukat.

Ezek három példája közös követelménye nem feltétlenül a Google-mentes Android volt. A közös követelmény az volt, hogy nagyobb ellenőrzést gyakoroljanak a szoftver működésén dedikált hardveren.

A megfelelő Android-architektúra attól függ, hogy ki uralja a szoftveres felhasználói élményt

A döntés AOSP és GMS a szoftveralkalmazás-modellből kell kiindulni, nem az operációs rendszer iránti preferenciából.

Olyan projekteknél, amelyek erősen támaszkodnak a Google-szolgáltatásokra, fogyasztói alkalmazásokra vagy a meglévő Android-ökoszisztémára, a GMS-képes Android gyakorlati előnyöket nyújthat a szélesebb alkalmazási kompatibilitás .

Különálló terminálok esetében, ahol a vevő ellenőrzi az alkalmazáskörnyezetet, egy AOSP-alapú rendszer több rugalmasságot kínálhat. Ez különösen akkor fontos, ha az eszköznek testre szabott indítási viselkedésre, korlátozott felhasználói hozzáférésre vagy hosszú távú szoftveregységességre van szüksége.

A különbség hatással van az OEM-fejlesztési folyamatra is. Egy testre szabott Android-projekt többet is jelenthet, mint a felhasználói felület módosítása. Hatással lehet  a firmware-konfigurációra , a rendszerkép-kezelésre, az alkalmazások telepítési folyamatára , Az OTA-frissítési stratégiára , és gyártásérvényesítés .

A vevő számára tehát a kérdés nem egyszerűen az, hogy

"Ez a szállító biztosítani tud Android-tablet-et?"

A fontosabb kérdés a következő:

"Ez a szállító támogatni tudja a projektünk által megkövetelt teljes hardver- és szoftvertelepítési modellt?"

Az adatvédelmi követelményeket ellenőrizni kell, nem feltételezni

Az olyan kérések, mint például a „nincs GMS”, „nincs kamera” vagy „nincs mikrofon”, gyakran felkeltik a figyelmet, mert erősebb adatvédelmi elvárásokra utalhatnak.

Ugyanakkor a pontos motivációt nem szabad feltételezni.

A három áttekintett projekt közül csak egy vevő kért explicit módon GMS-mentes  AOSP környezetet. A másik két projektben nem említették ezt a követelményt.

Ez azt jelenti, hogy az adatvédelemre fókuszáló testreszabás konkrét vevői forgatókönyvekben jelenik meg, nem pedig univerzális követelményként minden okos otthoni központ esetében.

A szállítók és vevők számára korai tárgyalások során tisztázni kell, hogy a projekt szükségképpen teljesen ellenőrzött Android-környezetet igényel-e, szükségesek-e a Google-szolgáltatások, valamint hogy a hardveres korlátozások az adatvédelmi elvárásokra, a megfelelőségi szempontokra vagy a termék pozicionálására vonatkoznak-e.

Ezen követelmények korai érvényesítése csökkentheti a felesleges mérnöki munkát, és elkerülheti a drága módosításokat a fejlesztés megkezdése után.

A kioszk telepítés egyre inkább az elkülönített okos kijelzők alapját képezi

Bár a három vevő más-más prioritásokat határozott meg, minden projekt hasonló irányba mutatott: a kijelzőnek szolgáltatás-specifikus felületként kellett működnie.

Itt jön kioszk üzemmód fontossá válik. Lehetővé teszi az automatikus alkalmazásindítást, korlátozott felhasználói hozzáférést és konzisztens élményt a telepítés után.

Idősek gondozására szolgáló rendszerekben, okos otthoni központokban és szoftvervezérelt hardvertermékekben a kijelző már nem csupán egy Android-képernyő. A teljes szolgáltatási rendszer részévé válik.

Ez új követelményeket is támaszt az OEM-szállok iránt. Ezeknek a projekteknek a támogatásához nemcsak a hardverespecifikációkat, hanem szoftver-hardver integráció a fejlesztés, gyártás és hosszú távú üzemeltetés egész folyamatát át kell tekinteni.

OEM okos kijelző projekt megkezdése előtt határozza meg ezeket a döntéseket

Mielőtt egy Android kijelző OEM megoldást kérne, a vevőknek először négy projekt-határt kell tisztázniuk:

Az alkalmazás függ-e a Google-szolgáltatásoktól, mennyire szükséges a vezérlés az Android-rendszer felett, vannak-e adatvédelmi korlátozások, valamint hogyan kerül kezelésre az eszköz a telepítést követően.

Ezek a döntések közvetlenül befolyásolják a megfelelő hardverplatformot, az Android-architektúrát, az egyéni testreszabás mértékét és a beszállítók képességére vonatkozó követelményeket.

Ezért a beszállítók értékelése nem szabad, hogy csak a processzor, a memória vagy a kijelző specifikációira korlátozódjon. A vásárlóknak ellenőrizniük kell, hogy az OEM-partner támogatja-e rendszer testreszabása az alkalmazások telepítését, a firmware-felügyeletet és a hosszú távú termékfenntartást.

A jelen cikkben tárgyalt három valós igény nem bizonyítja, hogy minden okos otthoni projektnek szüksége van egy de-googled display -ra. Inkább egy gyakorlatiasabb változást mutatnak: a vásárlók egyre inkább a hardvert arra alapozva értékelik, hogy mennyire támogatja szoftverstratégiájukat.

Azoknak a cégeknek, amelyek okos otthoni központokat fejlesztenek , az idősek gondozására szolgáló kijelzők vagy szoftverrel vezérelt hardvertermékek esetében a megfelelő Android-architektúra korai meghatározása csökkentheti a fejlesztési kockázatot, és megbízhatóbb üzembe helyezési útvonalat biztosíthat.

Ha Android-alapú intelligens kijelző projektet tervez, a megfelelő rendszerarchitektúra korai meghatározása segíthet csökkenteni a fejlesztési kockázatokat és elkerülni a szükségtelen testreszabási költségeket.

Csapatunk segíthet értékelni az alkalmazási igényeit, az Android-architektúra lehetőségeit (AOSP vagy GMS) és a hardvertestreszabás szükségességét annak meghatározásához, hogy melyik üzembe helyezési megközelítés lenne a legmegfelelőbb.

Lépjen kapcsolatba a csapattal beszélgetni a projektkövetelményeiről, vagy elküldeni lekérdezését egy testreszabott Android-kijelző megoldásra.