Hvordan OEM-prosjekter for smarte hjem-sentraler velger mellom AOSP- og GMS-Android-arkitekturer

Når selskaper utvikler en smart hjemmehub , bestemmes ofte Android-systemarkitekturen langt før produksjonsstadiet for maskinvaren.

Ved første øyekast kan en hjemmehub-skjerm virke som en vanlig pekeskjerm. For mange B2B-prosjekter er imidlertid skjermen ikke bare en skjerm med et operativsystem. Den blir en dedikert grensesnitt-løsning som kobler programvaretjenester, brukere og tilkoblede hjemmemiljøer.

Dette er grunnen til at noen kjøpere begynner å stille dypere spørsmål om Android-arkitektur : Skal enheten bruke standard Android med Google Mobile Services ( GMS )? Krever prosjektet et AOSP -basert system uten Google-tjenester? Hvor mye kontroll trenger kjøperen over programvareinstallasjon og enhetsatferd?

Tre reelle forespørsler fra OEM-er av hjemmesentraler fra Norge, Belgia og USA gir nyttige eksempler. De representerer ikke hele markedet for smarte hjem, men de viser hvordan ulike kjøpere vurderer systemkrav basert på egne distribusjonsmål.

Det viktige signalet er ikke at alle prosjekter for smarte hjemssentraler beveger seg mot de-googla skjermløsninger . I stedet viser disse forespørslene at kjøpere blir mer spesifikke når det gjelder programvarkontroll, applikasjonsinstallasjon og enhetsanpassing.

Hvorfor noen prosjekter for smarte hjemmesentraler trenger mer kontroll over Android-systemer

En tradisjonell forbrukertablet er designet med fleksibilitet i fokus. Brukerne installerer ulike applikasjoner, får tilgang til nettbaserte tjenester og samhandler med et bredt økosystem.

En dedikert smart-hjem-sentral følger en annen logikk. For mange OEM-prosjekter har enheten ett hovedformål: å kjøre en spesifikk applikasjon pålitelig i en kontrollert miljø.

Kjøperen kan trenge at displayet starter direkte inn i deres egne programvare, forhindre unødvendig brukeradgang eller opprettholde konsekvent oppførsel over alle installerte enheter. I disse scenariene blir Android-arkitekturen en forretningsbeslutning, ikke bare et teknisk valg.

En AOSP -basert løsning kan gi dypere kontroll over systemmiljøet, mens en GMS -aktivert Android-løsning gir tilgang til Googles økosystem og tjenester. Ingen av alternativene er universelt bedre. Det riktige valget avhenger av hvordan enheten vil bli distribuert, vedlikeholdt og brukt.

Denne forskjellen er spesielt viktig for selskaper som går fra programvare til maskinvare. Et SaaS-selskap som bygger en dedikert smart skjerm, for eksempel, kan ha mindre interesse for generell Android-funksjonalitet og mer interesse for om maskinvaren kan levere programvareopplevelsen pålitelig.

Tre OEM-forespørsler viser ulike grunner bak tilpasning av Android

Disse eksemplene gjenspeiler reelle OEM-diskusjoner med kjøpere i ulike markeder. Istedenfor å fokusere på enkelte selskaper, understreker sammenligningen hvordan ulike prosjektmål påvirker valg av Android-system, programvaredistribusjon og krav til maskinvaretilpasning.

En systemintegrator med base i Norge ba om en AOSP -basert skjerm uten GMS , samt maskinvarebegrensninger som fjerning av kamera- og mikrofonkomponenter. Prosjet krevede også kioskmodus med automatisk APK-start.

Denne forespørselen viser tydelig preferanse for et kontrollert Android-miljø. Kjøperen lette ikke etter en allmenn bruks-tablet, men etter en dedikert hardware-terminal der programvareopplevelsen kunne styres på systemnivå.

Årsaken til denne forespørselen bør likevel verifiseres under prosjektdiskusjonene. En GMS-fri krav kan være knyttet til personverntiltak, applikasjonskontroll, bedriftsinstallasjonspolicyer eller andre prosjektspecifikke vurderinger.

Det andre prosjektet, fra en belgisk leverandør av eldreomsorgsløsninger, fokuserte på andre prioriteringer. De forespurte funksjonene inkluderte 4G-tilkobling, WiFi, kioskmodus , og en forenklet interaksjonsopplevelse.

I motsetning til det første prosjektet ba ikke denne kjøperen uttrykkelig om et «de-Googlet» system. Denne forskjellen er betydningsfull, fordi den viser at Android-tilpasninger med fokus på personvern ikke automatisk kreves for alle smarte hjem- eller eldreomsorgsapplikasjoner.

Det tredje prosjektet kom fra et amerikansk SaaS-selskap som undersøkte hardware-utplassering for sin programvaretjeneste. Hovedkravene inkluderte forhåndsinstallasjon av applikasjoner, kioskutplassering og merkevaretilpasning.

For programvareselskaper som går inn i hardware-sektoren er utfordringen ofte ikke å velge en spesifikk tabletspesifikasjon. Den større utfordringen er å skape en pålitelig fysisk grensesnittløsning som utvider deres eksisterende programvareplattform.

I disse tre eksemplene var det felles kravet ikke nødvendigvis en «de-Googlet» Android-plattform. Det felles kravet var større kontroll over hvordan programvaren kjører på dedisert hardware.

Den riktige Android-arkitekturen avhenger av hvem som styrer programvareopplevelsen.

Valget mellom AOSP og GMS bør begynne med applikasjonsmodellen, ikke med preferanse for operativsystem.

For prosjekter som avhenger sterkt av Google-tjenester, forbrukerapplikasjoner eller det eksisterende Android-økosystemet, kan GMS-aktivert Android gi praktiske fordeler på grunn av bredere applikasjonskompatibilitet .

For dedikerte terminaler der kjøperen kontrollerer applikasjonsmiljøet, kan et AOSP-basert system gi mer fleksibilitet. Dette er spesielt relevant når enheten krever tilpasset oppstartatferd, begrenset brukeradgang eller langvarig programvarekonsistens.

Forskjellen påvirker også OEM-utviklingsprosessen. Et tilpasset Android-prosjekt kan innebære mer enn bare endringer av brukergrensesnittet. Det kan påvirke  firmware-konfigurasjon , håndtering av systemavbildninger, arbeidsflyt for applikasjonsinstallasjon , Strategi for OTA-oppdateringer , og produksjonsvalidering .

For kjøpere er spørsmålet derfor ikke bare:

"Kan denne leverandøren levere en Android-tablett?"

Det viktigere spørsmålet er:

"Kan denne leverandøren støtte det komplette maskinvare- og programvaredistribusjonsmodellen som prosjektet vårt krever?"

Personvernkrav bør verifiseres, ikke antas

Forespørsler som «ingen GMS», «ingen kamera» eller «ingen mikrofon» tiltrekker ofte oppmerksomhet, fordi de kan indikere sterke forventninger til personvern.

Men den nøyaktige motivasjonen bør ikke antas.

I de tre gjennomgåtte prosjektene ba bare én kjøper uttrykkelig om et GMS-fri  AOSP miljø. De to andre prosjektene nevnte ikke denne kravet.

Dette betyr at tilpassing med fokus på personvern oppstår i spesifikke kjøperscenarioer, snarere enn å representere et universelt krav for alle smarte hjemmesentraler.

For leverandører og kjøpere bør tidlige samtaler avklare om prosjektet krever et fullstendig kontrollert Android-miljø, om Google-tjenester er nødvendige og om maskinvarebegrensninger er knyttet til forventninger om personvern, etterlevelsekrav eller produktposisjonering.

Å bekrefte disse kravene tidlig kan redusere unødvendig ingeniørarbeid og unngå kostbare endringer etter at utviklingen har startet.

Kiosk-deployering blir en grunnstein for dedikerte smarte skjermer

Selv om de tre kjøperne hadde ulike prioriteringer, delte alle prosjektene en lik retning: skjermen måtte fungere som et dedikert tjeneste-grensesnitt.

Det er her kioskmodus blir viktig. Det muliggjør automatisk oppstart av applikasjoner, begrenset brukeradgang og en konsekvent opplevelse etter implementering.

For eldreomsorgssystemer, smarte hjem-sentraler og programvarestyrt maskinvareprodukter er skjermen ikke lenger bare en Android-skjerm. Den blir en del av et komplett tjenstesystem.

Dette skaper også nye krav til OEM-leverandører. Å støtte slike prosjekter krever forståelse ikke bare av maskinvarespesifikasjoner, men også av programvare-hårdvaruintegrasjon gjennom utvikling, produksjon og langsiktig drift.

Før du starter et OEM-smartskjerm-prosjekt, definer først disse avgjørelsene

Før du ber om en Android-skjerm-OEM løsning, bør kjøperne først klargjøre fire prosjektgrenser:

Om applikasjonen avhenger av Google-tjenester, hvor mye kontroll som kreves over Android-systemet, om det finnes personvernknyttede begrensninger og hvordan enheten vil administreres etter distribusjon.

Disse avgjørelsene påvirker direkte hvilken maskinvareplattform som er egnet, Android-arkitekturen, omfanget av tilpasning og kravene til leverandørkompetanse.

En leverandørvurdering bør derfor gå utover prosessor-, minne- eller skjermspesifikasjoner. Kjøpere bør bekrefte om OEM-partneren kan støtte systemtilpasning , applikasjonsdistribusjon, firmwareadministrasjon og langsiktig produktvedlikehold.

De tre reelle behovene diskutert i denne artikkelen beviser ikke at alle smarte hjem-prosjekter krever en de-googla skjermløsninger . De demonstrerer en mer praktisk endring: kjøpere vurderer økende grad av maskinvare basert på hvor godt den støtter deres programvarestrategi.

For selskaper som utvikler smarte hjem-sentraler , visningsskjermer for eldrepleie eller programvaredrevne maskinvareprodukter, kan å definere riktig Android-arkitektur tidlig redusere utviklingsrisiko og skape en mer pålitelig distribusjonsvei.

Hvis du planlegger et smart-visningsskjermprosjekt basert på Android, kan å definere riktig systemarkitektur tidlig hjelpe til å redusere utviklingsrisiko og unngå unødvendige tilpasningskostnader.

Vårt team kan hjelpe deg med å vurdere applikasjonskravene dine, alternativer for Android-arkitektur (AOSP eller GMS) og behovet for maskinvaretilpasning for å identifisere en passende distribusjonsmåte.

Å kontakte vårt team for å diskutere prosjektkravene dine eller sende inn forespørselen din om en tilpasset Android-visningsskjermløsning.