EDLA frente a GMS frente a AOSP: qué significa cada término para los dispositivos empresariales

Respuesta directa

EDLA, GMS y AOSP no son tres sistemas operativos Android equivalentes. AOSP es la base de la plataforma de código abierto. GMS es un conjunto de aplicaciones y API de Google con licencia independiente que se añade a una compilación de Android. Los materiales públicos de OEM y socios describen EDLA como una ruta de licenciamiento para que las categorías de dispositivos empresariales elegibles incorporen esa capa de GMS. Esta revisión no localizó una especificación pública general de Google sobre EDLA que cubra elegibilidad, pruebas, tarifas y alcance de modelos; trate EDLA como una afirmación que requiere evidencia específica del modelo por parte del OEM o la contraparte de licenciamiento aplicable.

Comience con un modelo por capas, no con tres opciones paralelas

Una etiqueta de folleto le indica al comprador qué pregunta hacer; no responde todas las preguntas del proyecto. Trate los términos como capas diferentes.

Cómo se relacionan las capas

Un dispositivo comercializado como EDLA sigue basándose en Android. La decisión no es “EDLA o GMS o AOSP”. Pregunte qué compilación de Android utiliza, si la capa de Google tiene licencia legítima, qué ruta aplica a la categoría de dispositivo y si los requisitos del proyecto están validados.

Qué significa AOSP

La descripción general de AOSP describe el código fuente de Android disponible públicamente y modificable, a partir del cual los fabricantes de dispositivos pueden crear variantes. El programa de compatibilidad de Android exige, de forma independiente, el Documento de Definición de Compatibilidad (CDD) aplicable y el CTS para la compatibilidad con Android. Esto establece que AOSP puede ser una base de plataforma y que la compatibilidad es un estado adicional que debe evidenciarse. No establece el licenciamiento de GMS, el comportamiento de las aplicaciones, la gestión empresarial, las actualizaciones, ni que una compilación AOSP sea exclusivamente sin conexión o de aplicaciones privadas. Identifique la compilación exacta, las dependencias de distribución y nube, la evidencia de compatibilidad, las pruebas de aplicaciones, la ruta de gestión y el responsable del ciclo de vida, en lugar de aceptar “AOSP” como una arquitectura completa.

Qué significa GMS

Google define Google Mobile Services como un conjunto con licencia de aplicaciones y API de Google que no forma parte de AOSP; el conjunto puede variar según la disponibilidad y los requisitos de cada país. Google Play services es una capa de servicios en el dispositivo utilizada por los SDK de Google, y no es sinónimo de la totalidad de GMS. Una afirmación legítima de GMS identifica una capa de software de Google con licencia, pero no establece que cada aplicación de Google requerida, SDK, flujo de cuenta, canal de aplicaciones administradas o veredicto de Play Integrity funcione para la aplicación y el mercado en cuestión.

• Inventaríe las aplicaciones, API, cuentas, canal de distribución, servicios en segundo plano, comportamiento sin conexión y llamadas de integridad requeridas; pruébelas en la compilación cotizada.
• No traslade un requisito de integridad obsoleto a un nuevo brief: Google indica que SafetyNet Attestation se desactivó por completo en enero de 2025.
• Registre y pruebe la implementación de Play Integrity de la aplicación de producción en lugar de inferirla a partir de la etiqueta del dispositivo.

Qué significa EDLA, y qué no dice la evidencia pública

La explicación de EDLA de BenQ describe EDLA como algo que habilita GMS integrado en soluciones empresariales como pizarras inteligentes, y la página de socios de Kuori describe una asociación EDLA para pantallas comerciales compatibles con GMS. La página pública de socios de Android Enterprise de Google remite algunos requisitos de programas de dispositivos a materiales de socios o contactos comerciales, en lugar de publicar una especificación general de EDLA. Estas fuentes de proveedores y socios establecen un uso de mercado documentado en torno a los servicios de Google con licencia en categorías de dispositivos empresariales elegibles. No establecen los términos contractuales privados de Google, la elegibilidad universal, el estado de otro proveedor ni el estado de todos los quioscos, pantallas, terminales, teléfonos o tablets.

• Considere a BenQ y Kuori como descripciones de proveedores/socios, no como términos del programa de Google.
• Exija una declaración que indique el modelo exacto, el SKU, la versión de Android, la compilación, el mercado, el responsable de la afirmación y la evidencia aplicable.
• No acepte una frase de folleto o un ícono visible de Play Store como evidencia suficiente.

Cuándo es relevante EDLA

Los ejemplos públicos de EDLA revisados aquí se concentran en pantallas interactivas y comerciales. Esto respalda la pregunta sobre EDLA cuando un proveedor lo invoca para una categoría de dispositivo empresarial fuera de la ruta habitual de teléfonos o tablets; no establece una lista completa de dispositivos elegibles. Para un teléfono, tablet o dispositivo portátil convencional, pregunte si la compilación exacta que se envía tiene licencia legítima de GMS y está certificada por Play Protect. Esa verificación demuestra un estado de certificación observado, no el comportamiento del EMM, la duración de las actualizaciones, la aprobación regional ni el flujo de trabajo en campo. Registre el resultado junto con el modelo/SKU/compilación y luego use la guía de decisión de implementación GMS frente a AOSP para evaluar la aplicación, la gestión, el aprovisionamiento y el ajuste del ciclo de vida.

Aplique cinco filtros antes de una cotización o decisión de muestra

Use estos filtros para una pantalla comercializada como EDLA, un dispositivo portátil GMS convencional o un terminal industrial basado en AOSP. Cada filtro genera un registro que puede probarse o cuestionarse antes de que el proyecto se convierta en un compromiso de compra.

1. 1Fije la línea base del dispositivo: registre el factor de forma, el fabricante, el modelo exacto y el SKU regional, la versión de Android, el número de firmware/compilación, el nivel de parche de seguridad y cualquier unidad de cómputo modular.
2. 2Audite las dependencias de aplicaciones y servicios: enumere cada aplicación de Google, SDK, flujo de cuenta, canal de distribución, servicio en segundo plano y comportamiento sin conexión requeridos; pruebe la aplicación real.
3. 3Verifique la evidencia de licenciamiento aplicable: identifique al responsable de la afirmación y el modelo/compilación/mercado exacto que cubre; separe el uso del código fuente de AOSP, la compatibilidad con Android, la certificación Play Protect, el licenciamiento de GMS y el estado EDLA descrito por el proveedor.
4. 4Valide la gestión y la inscripción por separado: identifique el modo de propiedad, el EMM, el DPC o agente, el canal de aplicaciones, el requisito de modo quiosco, la ruta de aprovisionamiento, el modelo de cuenta y el procedimiento de recuperación.
5. 5Confirme la región y el ciclo de vida: registre la disponibilidad por país, el responsable de las actualizaciones, la declaración de soporte del sistema operativo y de seguridad, la ruta OTA, el comportamiento de restablecimiento, la vía de reemplazo, las limitaciones conocidas y los factores que activan una revalidación.

Mantenga separados Android Enterprise, EMM, zero-touch y AER

La descripción general de Android Enterprise de Google describe una consola EMM, un componente de política en el dispositivo y Google Play administrado. La descripción general de gestión de dispositivos de AOSP documenta los conceptos de propietario del dispositivo, propietario del perfil, DPC y marco de políticas. Los requisitos de Android Enterprise Recommended son una señal de programa independiente y versionada. Por lo tanto, el licenciamiento, la arquitectura de gestión, el aprovisionamiento y AER son capas de evidencia distintas.

Acepte evidencia, no etiquetas

Antes de aprobar una muestra, reúna evidencia no confidencial que pueda acompañar al dispositivo hacia producción. La muestra debe demostrar el flujo de trabajo requerido, no todas las capacidades que sugiere una etiqueta.

Asigne las responsabilidades

Este es un modelo de planificación, no un contrato universal. Vantora puede coordinar una revisión de viabilidad de plataforma y ayudar a convertir las afirmaciones en requisitos comprobables. No otorga licencias de Google, no certifica dispositivos EDLA, no opera el tenant EMM de un cliente ni promete una vía de licenciamiento para todos los modelos.

Solicite una revisión de viabilidad de plataforma

Comparta un brief con datos sensibles omitidos que incluya la categoría de dispositivo, el modelo/SKU candidato, los países objetivo, el rango de cantidades, la compilación de Android, las dependencias de la aplicación, los servicios de Google requeridos, la pila de gestión, las expectativas de actualización y las prioridades de aceptación. No se necesitan nombres de clientes finales ni material de licencia privado para una revisión inicial. La guía de métodos de aprovisionamiento de dispositivos Android puede ayudar a definir la siguiente decisión de gestión e inscripción.