Como os proxectos OEM de centros de control de vivendas intelixentes elixen entre as arquitecturas Android AOSP e GMS

Cando as empresas desenvolven un centro para o fogar intelixente , a arquitectura do sistema Android adoita decidirse moito antes da fase de produción do hardware.

Á primeira vista, unha pantalla para centro doméstico pode parecer un dispositivo estándar con pantalla táctil. Non obstante, para moitos proxectos B2B, a pantalla non é simplemente unha pantalla cun sistema operativo. Converte-se nunha interface dedicada que conecta servizos de software, usuarios e entornos domésticos conectados.

É por iso que algúns compradores comezan a formular preguntas máis profundas sobre Arquitectura Android : Debería o dispositivo usar Android estándar con Google Mobile Services ( GMS )? Requírese un proxecto un sistema base en AOSP sen servizos de Google? Canto control necesita o comprador sobre a implantación de software e o comportamento do dispositivo?

Tres solicitudes reais de OEM de centros domésticos de Noruega, Bélxica e Estados Unidos proporcionan exemplos útiles. Non representan todo o mercado de fogares intelixentes, pero amosan como distintos compradores avalían os requisitos do sistema base nos seus propios obxectivos de implantación.

A señal importante non é que cada proxecto de centro de fogar intelixente se mova cara a solucións de pantalla sen Google . En troques, estas solicitudes amosan que os compradores están volvéndose máis específicos respecto ao control de software, á implantación de aplicacións e á personalización de dispositivos.

Por que algúns proxectos de centros de fogar intelixente necesitan máis control sobre os sistemas Android

Unha tablet tradicional para consumidores está deseñada arredor da flexibilidade. Os usuarios instalan distintas aplicacións, acceden a servizos en liña e interactúan cun amplo ecosistema.

Un centro intelixente para o fogar dedicado segue unha lóxica diferente. Para moitos proxectos de fabricantes orixinais de equipo (OEM), o dispositivo ten un propósito principal: executar unha aplicación específica de forma fiable nun entorno controlado.

O comprador pode necesitar que a pantalla inicie directamente na súa propia software, impedir o acceso innecesario do usuario ou manter un comportamento consistente entre as unidades despregadas. Nestes escenarios, a arquitectura Android convértese nunha decisión empresarial e non só nunha opción técnica.

An AOSP -base pode proporcionar un control máis profundo sobre o entorno do sistema, mentres que unha solución Android GMS habilitada ofrece acceso ao ecosistema e aos servizos de Google. Ningunha das dúas opcións é universalmente mellor. A elección adecuada depende de como se despregue, mantenha e use o dispositivo.

Esta distinción é especialmente importante para empresas que pasan do software ao hardware. Por exemplo, unha empresa de SaaS que constrúa unha pantalla intelixente dedicada pode dar menos importancia á funcionalidade xeral de Android e máis á capacidade do hardware para entregar de forma fiable a súa experiencia de software.

Tres solicitudes de OEM amosan distintas razóns detrás da personalización de Android

Estes exemplos reflicten discusións reais entre OEM e compradores en distintos mercados. En vez de centrarse nas empresas individuais, a comparación resalta como os obxectivos diferentes dos proxectos influencian as eleccións do sistema Android, a implementación de software e os requisitos de personalización do hardware.

Un integrador de sistemas con sede en Noruega solicitou unha AOSP pantalla baseada en GMS , xunto con limitacións de hardware como a eliminación dos compoñentes de cámara e micrófono. O proxecto tamén requiría modo quiosco con inicio automático da APK.

Esta solicitude mostra claramente unha preferencia por un entorno Android controlado. O comprador non buscaba unha tableta de uso xeral, senón un terminal de hardware dedicado no que a experiencia de software puidese ser xestionada a nivel do sistema.

Non obstante, a razón detrás da solicitude debería seguir verificándose durante as conversas do proxecto. Unha Sen GMS pode estar relacionada coas expectativas de privacidade, o control de aplicacións, as políticas de despregue empresarial ou outras consideracións específicas do proxecto.

O segundo proxecto, dun fornecedor belga de solucións para o coidado de persoas maiores, centrouse en prioridades diferentes. As características solicitadas incluían conectividade 4G, WiFi, modo quiosco , e unha experiencia de interacción simplificada.

Ao contrario do primeiro proxecto, este comprador non solicitou explicitamente un sistema des-Googleado. Esta diferenza é significativa porque amosa que a personalización de Android centrada na privacidade non é automaticamente necesaria para todas as aplicacións de fogar intelixente ou de coidado de persoas maiores.

O terceiro proxecto proviña dunha empresa estadounidense de software como servizo (SaaS) que exploraba a implantación de hardware para o seu servizo de software. Os principais requisitos incluían a preinstalación de aplicacións, a implantación en quioscos e a personalización da marca.

Para as empresas de software que pasan ao hardware, o reto non é, con frecuencia, escoller a especificación dun tablet. O reto maior é crear unha interface física fiable que estenda a súa plataforma de software existente.

Nos tres exemplos anteriores, o requisito común non era necesariamente Android sen Google. O requisito común era un maior control sobre como se executa o software nun hardware dedicado.

A arquitectura adecuada de Android depende de quen controla a experiencia de software.

A decisión entre AOSP e GMS debería comezar co modelo de aplicación, non coa preferencia polo sistema operativo.

Para proxectos que dependen fortemente dos servizos de Google, das aplicacións de consumo ou do ecosistema Android existente, Android con GMS pode ofrecer vantaxes prácticas grazas á maior compatibilidade de aplicacións .

Para terminais dedicados onde o comprador controla o entorno de aplicación, un sistema baseado en AOSP pode ofrecer máis flexibilidade. Isto é especialmente relevante cando o dispositivo require un comportamento personalizado ao arrancar, acceso de usuario restrinxido ou consistencia a longo prazo do software.

A diferenza tamén afecta o proceso de desenvolvemento do fabricante de equipos orixinais (OEM). Un proxecto personalizado de Android pode implicar máis que cambiar a interface de usuario. Pode influenciar  a configuración do firmware , a xestión da imaxe do sistema, o fluxo de despregue de aplicacións , A estratexia de actualizacións OTA , e validación de produción .

Para os compradores, a pregunta non é, pois, tan simple como:

"Este fornecedor pode proporcionar unha tablet Android?"

A pregunta máis importante é:

"Este fornecedor pode apoiar o modelo completo de despregue de hardware e software requirido polo noso proxecto?"

Os Requisitos de Privacidade Deben Ser Validados, Non Supostos

Solicitudes como "sen GMS", "sen cámara" ou "sen micrófono" adoitan chamar a atención porque poden indicar expectativas máis estrictas en materia de privacidade.

Non obstante, non se debe supor a motivación exacta.

Nos tres proxectos revisados, só un comprador solicitou explicitamente un Sen GMS  AOSP ambiente. Os outros dous proxectos non mencionaron este requisito.

Isto significa que a personalización centrada na privacidade aparece en escenarios específicos de compradores, e non representa un requisito universal para todos os centros de domótica.

Para fornecedores e compradores, as conversacións iniciais deben esclarecer se o proxecto require un ambiente Android completamente controlado, se son necesarios os servizos de Google e se as restricións de hardware están relacionadas coas expectativas de privacidade, consideracións de conformidade ou posicionamento do produto.

Validar estes requisitos ao principio pode reducir o traballo de enxeñaría innecesario e evitar cambios costosos despois de iniciarse o desenvolvemento.

A implantación de quioscos está converténdose nunha base para pantallas intelixentes dedicadas

Aínda que os tres compradores tiñan prioridades distintas, todos os proxectos compartían unha dirección similar: a pantalla necesitaba funcionar como unha interface de servizo dedicada.

É aquí onde modo quiosco converteuse importante. Permite o lanzamento automático de aplicacións, o acceso restrinxido dos usuarios e unha experiencia consistente despois da implantación.

Para sistemas de coidado de persoas de idade avanzada, centros de control de fogares intelixentes e produtos de hardware impulsados por software, a pantalla xa non é só unha pantalla Android. Conviértese nunha parte dun sistema de servizo completo.

Isto tamén crea novos requisitos para os fornecedores OEM. Apoiar estes proxectos require non só comprender as especificacións do hardware senón tamén integración Software-Hardware ao longo do desenvolvemento, a fabricación e a operación a longo prazo.

Antes de comezar un proxecto OEM de pantalla intelixente, defina primeiro estas decisións

Antes de solicitar un OEM de pantallas Android solución, os compradores deben clarificar primeiro catro límites do proxecto:

Se a aplicación depende dos servizos de Google, o grao de control necesario sobre o sistema Android, se existen restricións relacionadas coa privacidade e como se xestionará o dispositivo despois da súa implantación.

Estas decisións inflúen directamente na plataforma de hardware adecuada, na arquitectura Android, no alcance da personalización e nos requisitos de capacidade do fornecedor.

A avaliación dun fornecedor debería, polo tanto, ir máis aló das especificacións do procesador, da memoria ou da pantalla. Os compradores deberían confirmar se o socio OEM pode ofrecer soporte para personalización do sistema , implementación de aplicacións, xestión de firmware e mantemento a longo prazo do produto.

As tres necesidades reais analizadas neste artigo non proban que cada proxecto de fogar intelixente requira un pantalla sen Google . Mostran un cambio máis práctico: os compradores están a avaliar cada vez máis o hardware en función de ata que punto apoia a súa estratexia de software.

Para empresas que desenvolven centros de fogar intelixente , mostras para o coidado de persoas maiores ou produtos de hardware impulsados por software, definir a arquitectura Android adecuada dende o principio pode reducir o risco de desenvolvemento e crear unha ruta de despregamento máis fiable.

Se está planeando un proxecto de pantalla intelixente baseado en Android, definir a arquitectura do sistema adecuada dende o principio pode axudar a reducir os riscos de desenvolvemento e evitar custos innecesarios de personalización.

O noso equipo pode axudar a avaliar os requisitos da súa aplicación, as opcións de arquitectura Android (AOSP ou GMS) e as necesidades de personalización do hardware para identificar unha aproximación de despregamento axeitada.

Contacte co noso equipo para debater os requisitos do seu proxecto ou presentar a súa consulta para unha solución de pantalla Android personalizada.