Dispositivos empresariales GMS frente a AOSP: una guía de decisión para la implementación
Elija la ruta de servicios de plataforma que requieren su aplicación y mercado, y luego valide la gestión, el aprovisionamiento, las actualizaciones y la recuperación en la compilación exacta del dispositivo antes de aprobar una implementación.
- Por
- Vantora Device Rollout Team
- Publicado
- Actualizado
La decisión es bidimensional
Comience con un candidato GMS exacto y certificado por Play Protect cuando la aplicación o la implementación dependan de Google Play services, Google Play administrado, zero-touch de Google o la ruta estándar de Android Enterprise respaldada por Google. Luego verifique esa elegibilidad de servicio e inscripción en el SKU y la compilación objetivo. Considere AOSP sin GMS únicamente cuando esas dependencias estén ausentes o sean reemplazables, y cuando la distribución, la gestión, la firma, el OTA, el mantenimiento, la recuperación y la propiedad del ciclo de vida estén asignados y validados.
Seis hechos publicados detrás de la elección
Estas fuentes establecen límites de plataforma útiles. No convierten a una familia de modelos, un logotipo o una declaración de proveedor en evidencia de aceptación para un proyecto en particular.
| Hecho verificado | Qué establece | Qué no establece | Acción del comprador o de aceptación |
|---|---|---|---|
| AOSP es código fuente público para variantes de Android; GMS es una capa de aplicaciones y API de Google con licencia independiente que no forma parte de AOSP. | El código fuente de la plataforma y los servicios de Google son decisiones independientes. | Que una compilación AOSP tenga mantenimiento o que una compilación GMS cotizada tenga licencia. | Registre la compilación exacta y su evidencia de Play Protect y GMS. |
| Los clientes del SDK de Google Play services llaman a la aplicación instalada de Google Play services en tiempo de ejecución. | La sola instalación del APK no constituye una auditoría de dependencias. | Qué SDK utiliza la aplicación de producción o su comportamiento ante fallos. | Pruebe los estados de ausencia, desactivación, desactualización, restricción y falta de conexión. |
| Google describe una solución de Android Enterprise como una consola EMM, Android Device Policy y Google Play administrado. | La ruta estándar respaldada por Google tiene componentes identificados. | Que todo EMM exponga todos los controles o que la misma pila exista en una compilación sin GMS. | Fije el EMM exacto, el modo de gestión, el canal de aplicaciones, la política y la compilación. |
| AOSP documenta los flujos del marco de aprovisionamiento administrado y las responsabilidades del DPC. | Una compilación sin GMS puede implementar los fundamentos de gestión de Android. | Una ruta de producción completa, segura, mantenida o aceptada en una compilación específica. | Exija evidencia del asistente de configuración (Setup Wizard) o del DPC, distribución de aplicaciones, restablecimiento, recuperación y responsables. |
| La inscripción zero-touch de Google requiere dispositivos elegibles, GMS con Play services habilitado, un EMM compatible, una cuenta creada por un distribuidor autorizado, una configuración asignada y conectividad para la configuración. | Zero-touch es una ruta específica de cadena de suministro y servicio. | Que una familia de modelos, una cotización de distribuidor o una cuenta de portal cubra las unidades exactas. | Verifique los identificadores, la asignación, la configuración, la red, el primer arranque limpio y la recuperación. |
| La compatibilidad con Android requiere el CDD y el CTS aplicables, mientras que las imágenes publicadas y los paquetes OTA dependen de claves de firma controladas. | La compatibilidad y la autoridad de lanzamiento son categorías de evidencia comprobables. | El licenciamiento de GMS, la duración de las actualizaciones, la aprobación de mercado o la aceptación del flujo de trabajo del cliente. | Contrate por separado la evidencia de compatibilidad, licenciamiento, firma, actualización, recuperación y aceptación. |
Los servicios de plataforma y la gestión de dispositivos son decisiones independientes
Elija la ruta de servicios de plataforma que requieren la aplicación y el mercado, y luego valide la implementación de gestión, aprovisionamiento, actualización y recuperación en la compilación exacta. Ni GMS ni AOSP por sí solos demuestran zero-touch, soporte de EMM, condiciones de actualización, comportamiento sin conexión, seguridad o aprovisionamiento por QR.
Comparación de dispositivos empresariales GMS frente a AOSP
Aquí, la ruta GMS se refiere a una compilación de producción con licencia y certificada por Play Protect. La ruta AOSP se refiere a una compilación de producción con un alcance definido deliberadamente, sin la capa de GMS con licencia.
| Dimensión de decisión | Ruta GMS con licencia | Ruta AOSP sin GMS | Evidencia antes de la aprobación |
|---|---|---|---|
| Tiempo de ejecución de la aplicación | Proporciona las API de Google Play services presentes en la compilación certificada exacta. | Las funciones que dependen de Google deben estar ausentes, ser reemplazadas o estar diseñadas para fallar de forma segura. | Inventario de dependencias más pruebas de la aplicación de extremo a extremo. |
| Distribución de aplicaciones | Puede usar Google Play administrado cuando la arquitectura de gestión lo admite. | Requiere un canal de distribución y actualización definido por el proyecto, con responsables identificados. | Resultados de instalación limpia, actualización, reversión, firma y funcionamiento sin conexión. |
| Gestión empresarial | Puede usar rutas compatibles de Android Enterprise y EMM respaldadas por Google. | Requiere un marco verificado, un DPC o agente, política, canal de aplicaciones y ruta de soporte. | Modo de propiedad exacto, componente de gestión, política y resultados del dispositivo/compilación. |
| Aprovisionamiento | Usa los métodos específicos del estado de gestión compatibles con la ruta exacta respaldada por Google. | Requiere una implementación verificada de aprovisionamiento administrado de AOSP u otra definida por el proyecto. | Inscripción repetible desde el estado limpio previsto. |
| Evidencia de plataforma | Certificación Play Protect, modelo/SKU/compilación exacto, estado de GMS y soporte de EMM aplicable. | Identidad de la compilación, lista de componentes, ruta de aplicación y gestión, responsable de la firma y línea base de lanzamiento. | Artefactos registrados, no solo un logotipo o una declaración del proveedor. |
| Control del sistema | Limitado por la compilación certificada del OEM, las API públicas, las funciones compatibles del OEM y las condiciones de licencia. | Puede ser más profundo únicamente cuando el proyecto cuenta con acceso viable a OEM/BSP, privilegios y firma. | Ruta de implementación autorizada y requisito comprobable. |
| Ciclo de vida del sistema operativo | El OEM o el propietario de la plataforma sigue controlando los lanzamientos de firmware y las condiciones de soporte. | Un responsable identificado de la compilación debe integrar, firmar, probar, distribuir y respaldar los lanzamientos. | Política de parches, responsable del lanzamiento, ruta OTA, recuperación y registro de fin de soporte. |
| Restablecimiento y recuperación | La reinscripción y la restauración de aplicaciones/políticas aún requieren validación. | El comportamiento de restablecimiento y la restauración pueden ser totalmente específicos del proyecto. | Pruebas de restablecimiento de fábrica, reinscripción, actualización fallida y recuperación. |
Audite la aplicación antes de seleccionar el hardware
No seleccione la plataforma a partir de la frase “funciona en Android”. Audite la aplicación real, los SDK, el flujo de identidad, las actualizaciones y el comportamiento ante fallos. Google explica que los SDK de Play services se comunican con la aplicación instalada de Play services, por lo que los dispositivos que no la tienen no ofrecen ese tiempo de ejecución. Pruebe la aplicación de producción cuando los servicios estén actualizados, no disponibles, desactivados, desactualizados, restringidos o sin conexión. Registre si la aplicación inicia, autentica, completa el trabajo, sincroniza y falla de forma recuperable.
- Inventaríe Play services, notificaciones push, Maps, Google Sign-In, Play Integrity, licenciamiento de Play y otras dependencias de API de Google.
- Trate la distribución de la aplicación como una dependencia independiente, con responsables identificados para la firma, la segmentación de versiones, el lanzamiento, las actualizaciones y la recuperación.
- Use Google Play administrado cuando la arquitectura de gestión compatible exacta lo requiera; defina una alternativa controlada para una compilación sin GMS.
Dónde encaja Android Enterprise
Google describe la solución estándar de Android Enterprise respaldada por Google como una consola EMM, Android Device Policy y Google Play administrado. Esa ruta no debe generalizarse a todas las compilaciones sin GMS. Al mismo tiempo, los fundamentos de gestión de Android existen en AOSP: su documentación de aprovisionamiento administrado cubre los casos de uso de propietario del dispositivo y propietario del perfil, incluidos los flujos por QR, NFC e iniciados en la nube, cuando la compilación, el asistente de configuración y el DPC ofrecen el comportamiento requerido. AOSP no carece de gestión ni es incompatible con QR de forma inherente; la pregunta de producción es si la compilación exacta del OEM y el componente de gestión ofrecen una implementación completa y mantenible.
- Considere zero-touch como una ruta específica de dispositivo elegible, distribuidor, cuenta, configuración, EMM y conectividad, no como un sinónimo de aprovisionamiento por QR o de propietario del dispositivo.
- Elija el estado de gestión y valide la ruta de entrada precisa mediante la guía de métodos de aprovisionamiento de dispositivos Android.
Use evidencia exacta para la compatibilidad y el licenciamiento
Evite tratar la frase “certificado GMS” como una garantía universal. Google indica que los dispositivos certificados por Play Protect han pasado las pruebas de compatibilidad de Android y pueden incluir aplicaciones propietarias de Google bajo licencia. El programa de compatibilidad de Android utiliza el Documento de Definición de Compatibilidad y el CTS, pero la compatibilidad solo hace que un dispositivo sea elegible para solicitar el licenciamiento de GMS; no otorga esa licencia automáticamente.
- Registre el modelo, el SKU regional, la huella digital de la compilación, el estado de Play Protect, la versión de Android, el nivel de parche y el listado aplicable del OEM o del EMM.
- No infiera el licenciamiento a partir de un ícono de Play Store o de una declaración del proveedor.
- No infiera la cantidad de actualizaciones, la frecuencia de parches, las condiciones de fin de soporte ni la aprobación de mercado a partir de la certificación.
Más control de la plataforma implica más responsabilidad sobre el ciclo de vida
La disponibilidad del código fuente de AOSP no proporciona, por sí sola, el paquete de soporte de placa (BSP), los binarios del proveedor, los permisos privilegiados, las claves de lanzamiento, el servicio OTA, el diseño de reversión ni los responsables de mantenimiento. Un mayor control puede justificarse para un componente privilegiado requerido, hardware especializado, un ecosistema privado o una política no disponible, pero el proyecto debe identificar la ruta de implementación autorizada y a los responsables continuos. Delimite el trabajo de firmware y software Android por dispositivo, plataforma, requisito, MOQ, ruta de lanzamiento y viabilidad, en lugar de asumir acceso a todas las ramas de firmware.
Siga una ruta de selección delimitada
Use una secuencia repetible que evite que el proyecto trate una etiqueta de plataforma como prueba de preparación para la implementación.
- 1Audite la aplicación: API de Google, identidad, distribución, actualizaciones, comportamiento sin conexión, periféricos y dependencias de backend.
- 2Defina la gestión: modo de propiedad, EMM/DPC, política, canal de aplicaciones, método de aprovisionamiento y estado de restablecimiento.
- 3Fije el candidato: modelo exacto, SKU regional, compilación de Android/firmware, estado de GMS/Play Protect y nivel de parche.
- 4Asigne responsables: firma de la aplicación y del sistema, OTA, correcciones de seguridad, reversión, soporte y fin de vida útil.
- 5Pruebe la muestra: flujo de trabajo, inscripción, política, actualizaciones, estado sin conexión, reinicio, restablecimiento y recuperación.
- 6Decida: acepte la línea base evidenciada, cambie de ruta o redefina el alcance antes de preparar el lote.
Exija evidencia antes de aprobar la muestra
La aprobación de la muestra debe describir un sistema reproducible, no simplemente un dispositivo que arrancó una vez. Vantora puede coordinar la selección de dispositivos, la validación de la aplicación y la gestión, el aprovisionamiento, el control de calidad y la entrega; el equipo de la aplicación es responsable del comportamiento de la aplicación, el proveedor del EMM es responsable de su implementación compatible, el OEM o el propietario autorizado de la compilación controla el firmware y la firma, y el cliente o el socio de integración aprueba el riesgo y la aceptación.
| Categoría de evidencia | Qué debe mostrar el registro de la muestra |
|---|---|
| Línea base del dispositivo | Modelo exacto, SKU regional, huella digital de la compilación, versión de Android/firmware, nivel de parche y línea base de componentes. |
| Plataforma y aplicación | Evidencia de Play Protect/GMS para una compilación GMS, o un registro de componentes/responsables para una compilación sin GMS; resultados de primer uso, permisos, identidad, flujo de trabajo, funcionamiento sin conexión, instalación y actualización. |
| Gestión y recuperación | Resultados de inscripción EMM/DPC, política, modo quiosco o restricciones, informes, acceso a soporte, restablecimiento de fábrica, reinscripción, reemplazo y recuperación. |
| Responsabilidad de lanzamiento | Responsables identificados de lanzamiento y soporte, especificación de la compilación, nota de lanzamiento, registro de aceptación y limitaciones conocidas. |
Solicite una revisión de viabilidad
Comparta un brief con datos sensibles omitidos que incluya la categoría de dispositivo prevista, el mercado objetivo, el rango de cantidades, el estado de la aplicación, las dependencias de servicios de Google, el EMM, la ruta de aprovisionamiento, las expectativas de ciclo de vida y las prioridades de aceptación. No se requieren nombres de clientes finales ni detalles comerciales para una revisión inicial. Si el hardware propuesto está fuera de la ruta GMS convencional de teléfono, tablet o dispositivo portátil y un proveedor menciona EDLA, use la guía EDLA frente a GMS frente a AOSP para esa pregunta independiente sobre licenciamiento y categoría de dispositivo.
Preguntas frecuentes
¿Puede un dispositivo AOSP seguir siendo gestionado?
Potencialmente. Android incluye marcos de gestión de dispositivos y de aprovisionamiento administrado, pero la compilación exacta debe ofrecer un asistente de configuración, DPC o agente funcional, modo de propiedad, políticas, distribución de aplicaciones, conectividad, recuperación y ruta de mantenimiento. “AOSP” por sí solo no es evidencia de una solución de gestión completa.
¿Se puede agregar GMS después de que los dispositivos se hayan producido?
No planifique en torno a esa suposición. GMS tiene licencia independiente, y la compilación de producción, el modelo, la ruta del OEM, la compatibilidad con Android y el estado de Play Protect deben respaldarlo. Instalar aplicaciones de Google de manera informal no convierte una compilación sin GMS en un dispositivo de producción con licencia adecuada.
¿GMS garantiza el soporte de Android Enterprise y las actualizaciones del sistema operativo?
No. Confirme el modo de gestión previsto, el conjunto de funciones del EMM, el método de inscripción, el SKU regional y la compilación. Verifique por separado los compromisos del OEM en materia de versión de Android, parches de seguridad, firmware, recuperación y fin de soporte.
¿Es AOSP siempre la mejor ruta para dispositivos sin conexión o altamente controlados?
No. Un dispositivo GMS puede admitir un flujo de trabajo comercial sin conexión, mientras que una compilación AOSP puede seguir dependiendo de redes y servicios externos. Elija AOSP solo cuando su dependencia, control, ciclo de vida y modelo comercial estén respaldados y comprobados de manera deliberada.
Cuéntenos su flujo de trabajo y sus reglas.
Convertimos los requisitos en dispositivos listos para implementar.