Lista de verificación de dispositivos Android preparados para aplicaciones para equipos de SaaS y software

La respuesta corta

Esta lista ayuda a los equipos de SaaS y software a decidir si realmente existe evidencia de que un dispositivo está preparado para la aplicación antes de comprometer un lote. En esta guía, «preparado para la aplicación» es un término de proyecto de Vantora, no una certificación de Google ni de Android. El equipo debe conectar los mecanismos independientes de compatibilidad, permisos, distribución, gestión y actualización de Android con un flujo de trabajo real en una configuración exacta.

Una aplicación instalada no equivale a un dispositivo preparado para ella

Una prueba de instalación demuestra que un paquete puede llegar al dispositivo probado por la vía ensayada. No demuestra todo el recorrido operativo. Android define la compatibilidad de una aplicación frente a una versión concreta de la plataforma y advierte que los cambios de plataforma pueden afectarla; por eso, valide la versión objetivo de Android y la compilación de firmware. Consulte la guía de compatibilidad de aplicaciones de Android.

Registre la base de referencia antes de realizar las pruebas

No apruebe «la versión de Android» ni «el APK» en abstracto. Asigne un registro de configuración a la muestra de referencia. Como mínimo, registre el modelo exacto y el SKU regional del dispositivo, las compilaciones de Android y firmware, el paquete y la versión de la aplicación, el origen de la firma, la vía de distribución, el modo de gestión, la versión de las políticas, los periféricos, los supuestos de red, los mercados objetivo y la fecha de la prueba.

1. Compruebe el flujo real de la aplicación

Una prueba genérica de rendimiento del dispositivo no puede responder estas preguntas. El hardware debe elegirse en torno al trabajo que realiza la aplicación, no a una cifra destacada de procesador o memoria.

• Están definidos el usuario principal, la tarea, el entorno y el resultado satisfactorio.
• Se dispone de vías representativas de inicio de sesión, tenant, función y recuperación de cuenta para las pruebas.
• Cuando corresponda, se cubren el funcionamiento en línea, con red débil y sin conexión, además de la sincronización y las sesiones interrumpidas.
• Se enumeran las interacciones necesarias con cámara, NFC, códigos de barras, impresora, escáner, base de acoplamiento, Bluetooth o USB.
• Se registran los supuestos sobre backend, certificados, VPN, dominio, hora, ubicación o API.

2. Compruebe el hardware y la variante de mercado exactos

Estos son datos de entrada para evaluar la viabilidad, no afirmaciones universales sobre el producto. Compare las vías convencionales, resistentes o de OEM más profundo con los requisitos antes de comprometer una cantidad.

• La pantalla, la memoria, el almacenamiento, la arquitectura de CPU, la cámara, los sensores y los puertos se adaptan al flujo de trabajo.
• La batería, la carga, los accesorios, el montaje y las necesidades ambientales son realistas para el turno operativo.
• Se registra el SKU regional exacto, no solo la familia del modelo.
• Las bandas celulares, la adecuación al operador, las certificaciones, las obligaciones del importador y los supuestos del país objetivo tienen responsables identificados.
• La disponibilidad del modelo, la vía de reemplazo y el ciclo de vida probable se ajustan al programa.

3. Compruebe la entrega de la aplicación y la identidad de la versión

Elija deliberadamente una vía de entrega: Google Play administrado, una precarga acordada o una preparación controlada del APK. No son intercambiables. Google documenta que Google Play administrado puede instalar aplicaciones mediante las políticas del dispositivo y restringir una aplicación privada a una sola empresa; consulte la documentación sobre distribución administrada de aplicaciones. Esto resulta útil en despliegues administrados compatibles, pero no hace que la misma vía esté disponible en todas las compilaciones AOSP, sin GMS, de OEM o sin administración.

• Se registran el nombre del paquete, el código de versión, el canal de lanzamiento y el responsable de la firma.
• La vía seleccionada funciona desde el estado limpio previsto del dispositivo.
• La visibilidad de la aplicación privada y la asignación al tenant son correctas cuando se utiliza Google Play administrado.
• Existe una vía de soporte para fallas de instalación, descargas interrumpidas y reinstalaciones.
• El lote de producción recibirá el mismo paquete y la misma vía aprobados.

4. Compruebe el primer inicio, los permisos y la configuración

Una aplicación puede instalarse sin problemas y fallar en la primera solicitud de permisos. En las versiones modernas compatibles, Android exige solicitar los permisos peligrosos durante la ejecución, y la aplicación debe gestionar una denegación en vez de dar por sentado el acceso. Pruebe la secuencia real de solicitud, justificación, concesión, denegación y recuperación descrita en el flujo de permisos durante la ejecución de Android. Para la configuración remota, confirme que la aplicación exponga y consuma los campos necesarios: la guía de configuraciones administradas de Android atribuye a la aplicación la definición de su esquema; un EMM no puede inventar campos que no admite.

• El primer inicio llega a la pantalla prevista sin pasos manuales que no estén documentados.
• Los permisos necesarios se solicitan en contexto y, si se deniegan, la aplicación falla de forma segura.
• La configuración de cuenta, tenant, idioma, región, certificado y endpoint es correcta.
• Se prueban el reinicio, la reapertura, el cierre de sesión, el vencimiento de tokens y los escenarios de restablecimiento acordados.
• La configuración no incorpora credenciales de producción, claves de firma ni datos del cliente que no sean necesarios.

5. Compruebe la gestión, el quiosco y los límites del usuario

Primero decida si el dispositivo es personal, propiedad de la empresa con uso mixto, totalmente administrado o dedicado. En Android Management API, el token de inscripción y el método de aprovisionamiento establecen el modo de propiedad y gestión; consulte la documentación de aprovisionamiento de Google. Otras arquitecturas EMM pueden diferir, así que verifique la plataforma elegida en vez de copiar una política de ejemplo. El ejemplo de política para dispositivos dedicados de Google puede iniciar automáticamente una aplicación de quiosco designada al arrancar; es un ejemplo de implementación, no una promesa universal de control.

• La inscripción puede repetirse desde el estado previsto de restablecimiento de fábrica o dispositivo limpio.
• La asignación de aplicaciones, las políticas, las restricciones, los ajustes de red y los informes llegan al tenant y grupo correctos.
• Los requisitos de aplicación única, varias aplicaciones, launcher personalizado, lista de aplicaciones permitidas y acceso al soporte son explícitos.
• Se prueban el reinicio, el bloqueo, el desbloqueo, el restablecimiento, la actualización de políticas y las vías de salida inaceptables.
• El equipo de soporte dispone de una vía de recuperación que no depende de una contraseña desconocida ni de un paso de configuración oculto.

6. Compruebe las actualizaciones, la recuperación y el control de cambios

La primera versión es solo el comienzo del programa de dispositivos. Android acepta una actualización de la aplicación únicamente cuando se cumplen las condiciones de identidad y firma: el ID de la aplicación debe coincidir, el certificado de firma debe coincidir o utilizar una prueba válida de rotación y debe cumplirse la condición de versión. Revise las reglas de actualización de aplicaciones de Android antes de cambiar el canal de distribución o la custodia de la firma. La guía de actualizaciones de Android Management API de Google describe los modos predeterminado, de alta prioridad y de aplazamiento condicional para las aplicaciones administradas; estos modos no controlan las versiones de firmware del OEM.

• Están documentados el responsable de las versiones de la aplicación, la custodia de la firma, la aprobación y el momento del despliegue.
• Se comprende el comportamiento normal, urgente y por fases de las versiones en el canal elegido.
• Cuando sean relevantes, se prueban los escenarios de actualización fallida o interrumpida, migración de datos y recuperación.
• Los cambios de firmware, aplicación, backend, políticas y periféricos tienen criterios que activan la revalidación.
• No se promete una «reversión» salvo que el canal exacto y el modelo de datos de la aplicación admitan una vía de recuperación probada.

7. Compruebe la aceptación de la muestra

Convierta cada expectativa crítica en un criterio de aprobación, un método de prueba, un resultado observado, una referencia de evidencia, un responsable y una resolución. Utilice Aprobado, Condicional, Fallido o No aplicable solo cuando su significado esté definido. La Matriz de aceptación de la muestra ofrece una estructura útil, pero la autoridad designada del proyecto, no la plantilla, decide qué es suficiente para liberar el lote.

• La muestra aceptada está identificada físicamente y vinculada con su registro de configuración.
• Los flujos críticos del usuario se aprueban en la configuración exacta de la muestra.
• Los elementos condicionales indican la dependencia, el impacto, el responsable, la condición de cierre y si puede continuar el trabajo del lote.
• Los elementos críticos fallidos bloquean la liberación hasta que una autoridad designada apruebe una nueva vía.
• Cuando corresponda, capturas de pantalla, registros, grabaciones, registros de consola o notas de inspección respaldan los resultados sustanciales.

8. Compruebe la preparación del lote y la entrega

La preparación convierte la muestra aceptada en un lote controlado, y la entrega determina si el equipo receptor puede operarlo realmente.

• Las unidades de producción se preparan a partir de la base aceptada de aplicación, firmware, políticas y configuración.
• Según corresponda, se registran los datos de serie, IMEI, activo, sitio, tenant, SIM/APN, accesorios, etiquetas, cajas y excepciones.
• El QA compara el lote con la muestra de referencia e incluye una regla de detención ante desviaciones sustanciales.
• Están listas las instrucciones de activación, reemplazo, garantía, soporte, escalamiento y nuevos pedidos.
• El equipo receptor sabe qué acciones quedan por realizar en el sitio y en qué estado debe llegar el dispositivo.

Asigne responsabilidades antes del piloto

El siguiente es un modelo de planificación, no un contrato universal. Confirme cada fila en la matriz de responsabilidades del proyecto activo. La página de Vantora para socios de aplicaciones y SaaS describe el alcance de entrega relacionado.

Libere el lote solo cuando la evidencia esté conectada

El dispositivo está preparado para el lote acordado cuando se registra la base exacta, se aprueban los escenarios críticos, los elementos condicionales tienen responsable, el proceso de preparación reproduce la muestra y las reglas de soporte y control de cambios son utilizables. Esa preparación deja de ser válida cuando un cambio sustancial invalida la evidencia. Este límite más amplio explica por qué estar preparado para MDM no equivale a estar preparado para el despliegue: la inscripción puede ser necesaria sin ser suficiente. Conectar las capas de hardware, aplicación, políticas, validación y entrega es la labor de coordinación de un integrador de despliegues de dispositivos Android. La pregunta práctica es: ¿pueden aceptarse y repetirse esta aplicación, este dispositivo, esta vía de gestión y este flujo operativo exactos en las condiciones objetivo?