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. Entregado como un programa y no como una lista de verificación, eso es lo que cubre dispositivos Android con marca y preparados para aplicaciones.

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. Cuando la aplicación incluya voz o vídeo en tiempo real, amplíe esa línea base con el perfil de llamada y las pruebas de muestra de la guía de hardware Android para videollamadas WebRTC.

Cómo probar la compilación en un dispositivo candidato

La mayoría de las listas de verificación indican qué comprobar y dan por supuesto el método, y ahí es donde la evaluación se tuerce sin hacer ruido: las pruebas se ejecutan, se aprueban y demuestran menos de lo que el equipo cree. Empiece por la vía de instalación, porque cambia el significado de todos los resultados posteriores. Durante la evaluación, lo normal es que un ingeniero envíe la compilación por adb desde una estación de trabajo con la depuración por USB habilitada, y esa es una forma razonable de iterar rápido sobre un defecto funcional. No es la vía que usará la flota. Una instalación administrada dirigida por un controlador de políticas del dispositivo ocurre sin ningún usuario presente, potencialmente antes de que nadie inicie sesión, bajo las restricciones que la política ya aplica y con la instalación atribuida al canal administrado y no a una sesión local. El conjunto de restricciones de producción es lo que sorprende a los equipos: una política que prohíbe la instalación desde orígenes desconocidos, o que bloquea directamente la depuración por USB o la instalación de aplicaciones, cierra la vía de la que dependía la evaluación, de modo que el paquete que se instaló sin incidencias en una unidad de banco de pruebas no tiene ninguna vía de acceso a un dispositivo de producción. Pruebe la vía administrada en el candidato antes de dar la aplicación por instalable, y reserve la instalación externa para las iteraciones de depuración que después se vuelven a probar. El marco de vías de entrega en sí se expone en precargar aplicaciones en dispositivos Android a escala; aquí el punto es más limitado: la vía usada para ejecutar una prueba forma parte del resultado de esa prueba. A continuación, confirme la arquitectura que realmente se entrega. Los dispositivos declaran una ABI primaria y una secundaria —habitualmente arm64-v8a con compatibilidad de 32 bits allí donde la plataforma aún la ofrece— y la documentación sobre ABI de Android describe cómo se emparejan las bibliotecas nativas de un paquete con el dispositivo. Los fallos por ABI incorrecta rara vez parecen fallos de ABI: o bien se rechaza la instalación porque no coincide ningún código nativo, o bien la instalación se completa porque el paquete resulta llevar una carpeta de bibliotecas utilizable y la aplicación muere más tarde con un error de carga de biblioteca nativa la primera vez que se ejercita el escáner, la canalización de la cámara o el módulo de criptografía. Si la aplicación se distribuye como Android App Bundle, el APK universal que se instala externamente durante las pruebas y el paquete dividido (split) que un canal administrado genera para ese dispositivo concreto no son el mismo artefacto; registre cuál se probó y concílielo con lo que recibirá la flota. Los límites de versión merecen la misma literalidad. Los niveles de API mínimo y objetivo declarados en el manifiesto deciden tanto la elegibilidad como el comportamiento: un candidato que ejecuta una versión de Android por debajo del mínimo declarado queda filtrado del canal administrado en lugar de recibir un error, de modo que el síntoma es un dispositivo que nunca llega a recibir la asignación, mientras que el nivel objetivo determina qué comportamientos de compatibilidad de la plataforma se aplican. Google además impone un requisito de nivel de API objetivo que avanza con el tiempo para las cargas nuevas, así que una compilación interna antigua puede ser perfectamente comprobable y aun así no ser publicable por el canal que el programa piensa utilizar. Después, pruebe la compilación que recibirá la flota, no la que el desarrollador tiene abierta. Una compilación de depuración difiere de la candidata a versión final de formas que ocultan fallos reales: otra clave de firma, el indicador debuggable activo, la reducción de código y la ofuscación atenuadas u omitidas, el registro detallado conservado y —una sorpresa tardía frecuente— las anulaciones de depuración de la configuración de seguridad de red activas, de modo que un certificado interno o autofirmado que funcionó durante toda la evaluación deja de funcionar en la versión firmada. La reducción de código trae su propia clase de defecto, ya que la reflexión, la serialización y la inyección de dependencias suelen romperse solo una vez aplicada la ofuscación. La identidad de firma importa además más allá de la primera instalación, porque de ella depende la aceptación de las actualizaciones; resuelva la custodia de la firma, descrita en la firma de aplicaciones, antes de aceptar la muestra y no después. Ejecute todo esto en el SKU regional exacto que se va a pedir. Una misma familia de modelos puede compartir nombre comercial entre números de modelo que difieren en bandas de radio, nivel de memoria, software preinstalado, canal de firmware, conjunto de idiomas predeterminado y, en algunos mercados, en si los servicios de Google están presentes siquiera: una unidad parecida prestada por un colega es un buen dispositivo para encontrar errores y un mal dispositivo de aceptación. Por último, registre los mismos campos en cada ejecución o los resultados no podrán compararse después: modelo y número de modelo del dispositivo, huella de compilación y nivel de parche de seguridad, nombre de paquete con nombre y código de versión, resumen del certificado de firma, vía de instalación, versión de política en vigor, responsable de la prueba y fecha, además de los artefactos en bruto: un extracto de registro en torno a cada fallo, una grabación del flujo de trabajo y cualquier registro de fallo o de ANR. Ese conjunto es lo que permite que un resultado de prueba se convierta en una fila de la matriz de aceptación y lo que permite que la preparación de lotes Android reproduzca las condiciones probadas en lugar de aproximarlas.

Lo que oculta una prueba de escritorio: ejecución en segundo plano y política de energía

Una prueba de diez minutos en un dispositivo enchufado y con la pantalla encendida no ejercita casi nada del comportamiento de la plataforma que decide si la aplicación sigue funcionando al final de un turno. Android restringe activamente lo que permite un dispositivo en reposo: Doze y el modo de espera de aplicaciones aplazan el trabajo en segundo plano, las alarmas y el acceso a la red cuando un dispositivo está desconectado, inmóvil y a oscuras, y los liberan en ventanas de mantenimiento; y los grupos de espera de aplicaciones reducen la frecuencia con la que una aplicación poco usada puede llegar a ejecutarse. Un dispositivo conectado al cargador nunca entra en ese estado, y por eso precisamente la prueba de escritorio se aprueba. Por tanto, el protocolo de evaluación tiene que forzarlo: desenchufe la unidad, bloquéela, déjela durante un turno realista y, en las iteraciones de ingeniería, coloque el dispositivo en estado de reposo y en un grupo de espera bajo de forma deliberada en vez de esperar a que la plataforma llegue sola. El trabajo de larga duración también necesita un mecanismo que la plataforma respete. Un servicio en primer plano es visible para el usuario y, en las versiones recientes de Android, debe declarar un tipo de servicio con un permiso correspondiente e iniciarse en condiciones que la plataforma permita; el trabajo aplazable corresponde a tareas programadas; y las alarmas exactas están restringidas a las categorías de aplicación que reúnen los requisitos. Una aplicación construida en torno a un simple hilo en segundo plano y una alarma exacta puede comportarse bien durante una semana en el banco de pruebas y después perder su sincronización nocturna en toda la flota. Las exenciones de optimización de batería son la parte que más a menudo se da por supuesta en lugar de verificarse. Una exención cambia cómo trata la plataforma a la aplicación, pero obtenerla es una cuestión de política y no un ajuste de la aplicación: en un dispositivo no gestionado se tramita mediante una solicitud visible para el usuario, mientras que en un dispositivo totalmente administrado o dedicado un EMM puede llegar a aplicarla; y hay capas de gestión de energía propias del OEM que pueden situarse por encima del comportamiento de la plataforma y detener aplicaciones bajo reglas que la documentación de Android no describe. Esas capas dependen del OEM, del modelo y del firmware, y hay que confirmarlas en el candidato en lugar de inferirlas de la documentación de la plataforma. De ahí se derivan dos consecuencias para el despliegue. La primera: la exención de la que dependa la aplicación tiene que formar parte de la versión de política que aplica la preparación del lote; de lo contrario, la muestra se aprueba con una exención que alguien fijó a mano y el lote se envía sin ella, que es la brecha habitual entre un dispositivo que funciona y una flota. La segunda: esa dependencia corresponde a la biblioteca de limitaciones conocidas con un disparador de revalidación, porque una actualización de firmware puede cambiar el comportamiento de la gestión de energía sin que nada cambie en la aplicación. El mismo razonamiento se aplica a todo lo demás que se haya configurado manualmente en la muestra: si no está en la base de referencia registrada, no existe en el lote.

• Cargado y enchufado: el dispositivo nunca entra en el estado de reposo en el que se aplaza el trabajo en segundo plano.
• Pantalla encendida y desbloqueada: sin bloqueo de pantalla, sin degradación al modo de espera, sin la temporización de las ventanas de mantenimiento.
• Opciones de desarrollador y depuración por USB habilitadas: un estado que la política de producción normalmente no permitirá.
• Wi-Fi potente, tokens recién emitidos y una base de datos local vacía: nada de eso describe la octava hora de un turno.
• Exenciones y ajustes aplicados a mano en una unidad: ausentes del lote salvo que la política los aplique.

1. Compruebe el flujo de trabajo real de la aplicación

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

• El usuario principal, la tarea, el entorno y el resultado que define el éxito están definidos.
• Se dispone de vías representativas de inicio de sesión, tenant, rol y recuperación de cuenta para las pruebas.
• El comportamiento en línea, con red débil, sin conexión, de sincronización y de sesión interrumpida está cubierto cuando corresponde.
• 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 de backend, certificados, VPN, dominio, hora, ubicación o API.

2. Compruebe el hardware exacto y la variante de mercado

Estos son datos de entrada de viabilidad, no afirmaciones universales sobre el producto. Compare las vías de gama general, resistente o de personalización OEM más profunda frente a 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 ajustan al flujo de trabajo.
• La batería, la carga, los accesorios, el montaje y las necesidades ambientales son realistas para el turno de trabajo.
• Se registra el SKU regional exacto, no solo la familia de modelos.
• Las bandas celulares, la compatibilidad con el operador, las certificaciones, las obligaciones del importador y los supuestos sobre los países objetivo tienen responsables designados.
• La disponibilidad del modelo, la vía de reemplazo y el ciclo de vida previsible se ajustan al programa.

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

Elija la vía de entrega de forma deliberada: 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 políticas del dispositivo y puede restringir una aplicación privada a una sola empresa; consulte la documentación de distribución de aplicaciones administradas. Esto resulta útil en despliegues administrados compatibles, pero no hace que la misma vía esté disponible en cualquier compilación AOSP, sin GMS, de un OEM o no gestionada.

• Se registran el nombre de paquete, el código de versión, el canal de publicación y el responsable de la firma.
• La vía elegida funciona desde el estado limpio previsto del dispositivo.
• La visibilidad de la aplicación privada y la asignación de tenant son correctas cuando se utiliza Google Play administrado.
• El fallo de instalación, la descarga interrumpida y el comportamiento de reinstalación cuentan con una vía de soporte.
• 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 incidencias y fallar en su primera solicitud de permiso. Android exige que los permisos peligrosos se soliciten en tiempo de ejecución en las versiones modernas compatibles, y la aplicación debe gestionar una denegación en lugar de dar por hecho el acceso: pruebe la secuencia real de solicitudes, la justificación, la concesión, la denegación y el comportamiento de recuperación descritos en el flujo de permisos en tiempo de ejecución de Android. Para la configuración remota, confirme que la aplicación expone y consume los campos necesarios: la guía de configuraciones administradas de Android responsabiliza a la aplicación de definir su esquema, y un EMM no puede inventar campos no admitidos.

• El primer inicio llega a la pantalla prevista sin pasos manuales no documentados.
• Los permisos necesarios se solicitan en contexto y los permisos denegados fallan de forma segura.
• La configuración de cuenta, tenant, idioma, región, certificados y endpoints es correcta.
• Se prueban los escenarios de reinicio, reapertura, cierre de sesión, caducidad del token y restablecimiento acordado.
• No hay credenciales de producción, claves de firma ni datos innecesarios de clientes incrustados en la compilación.

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

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

• La inscripción se repite desde el estado limpio o de restablecimiento de fábrica previsto.
• La asignación de aplicaciones, las políticas, las restricciones, los ajustes de red y los informes llegan al tenant y al grupo correctos.
• Los requisitos de aplicación única, varias aplicaciones, launcher personalizado, lista de aplicaciones permitidas y acceso de soporte son explícitos.
• Se prueban el reinicio, el bloqueo, el desbloqueo, el restablecimiento, la actualización de políticas y las rutas 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 aplicación únicamente cuando se cumplen las condiciones de identidad y de firma: el ID de aplicación debe coincidir, el certificado de firma debe coincidir o utilizar una prueba de rotación válida, y debe cumplirse la condición de versión. Revise las reglas de actualización de aplicaciones de Android antes de cambiar de canal de distribución o de custodia de la firma. La guía de actualizaciones de la Android Management API de Google describe los modos predeterminado condicional, de alta prioridad y de aplazamiento para las aplicaciones administradas; estos no controlan las publicaciones de firmware del OEM.

• Se documentan la responsabilidad sobre las publicaciones de la aplicación, la custodia de la firma, la aprobación y los tiempos de despliegue.
• Se comprende el comportamiento del canal elegido en publicaciones normales, urgentes y escalonadas.
• Se prueban los escenarios de actualización fallida, actualización interrumpida, migración de datos y recuperación cuando son relevantes.
• Los cambios de firmware, aplicación, backend, políticas y periféricos tienen disparadores de revalidación.
• No se promete la «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 disposición. Utilice Aprobado, Condicional, Fallido o No aplicable solo cuando el significado esté definido. La Matriz de aceptación de muestras es una estructura útil, pero quien decide qué es suficiente para liberar es la autoridad designada del proyecto, no la plantilla.

• La muestra aceptada está identificada físicamente y vinculada a su registro de configuración.
• Los flujos de trabajo 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 el trabajo del lote puede continuar.
• Los elementos críticos fallidos bloquean la liberación hasta que una autoridad designada apruebe una nueva vía.
• Las capturas de pantalla, los registros, las grabaciones, los registros de consola o las notas de inspección respaldan los resultados relevantes cuando corresponde.

8. Compruebe la preparación del lote y el traspaso

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

• Las unidades de producción se preparan a partir de la base de referencia aceptada de aplicación, firmware, política y configuración.
• Se registran, según corresponda, los datos de número 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 relevantes.
• Las instrucciones de activación, reemplazo, garantía, soporte, escalamiento y pedidos posteriores están listas.
• El equipo receptor sabe qué acciones quedan pendientes en el sitio y qué estado debe existir ya a la llegada.

Asigne responsabilidades antes del piloto

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

Libere el lote solo cuando la evidencia encaje

El dispositivo está preparado para el lote acordado cuando la base de referencia exacta está registrada, los escenarios críticos se han aprobado, los elementos condicionales tienen responsable, el proceso de preparación reproduce la muestra y las reglas de soporte y de control de cambios son utilizables. La preparación caduca cuando un cambio relevante invalida esa evidencia. Este límite más amplio de la evidencia es la razón por la que preparado para MDM no es lo mismo que 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 tarea 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 de trabajo operativo exactos en las condiciones objetivo?