Pruebas de la plataforma de Android

El Proyecto de código abierto de Android (AOSP) proporciona varias herramientas y paquetes de pruebas para probar diferentes partes de tu implementación. Antes de usar las páginas de esta sección, debes familiarizarte con los siguientes términos:

Dispositivo compatible con Android
Un dispositivo que puede ejecutar cualquier app escrita por desarrolladores externos que utilicen el SDK y el NDK de Android. Los dispositivos compatibles con Android deben cumplir con los requisitos del documento de definición de compatibilidad (CDD) y aprobar el Conjunto de pruebas de compatibilidad (CTS). Los dispositivos compatibles con Android son aptos para participar en el ecosistema de Android, que incluye una licencia potencial de Google Play y del paquete de aplicaciones y APIs de los Servicios de Google para dispositivos móviles (GMS), y el uso de la marca Android. Si bien todos pueden usar el código fuente de Android, para ser considerado parte del ecosistema, un dispositivo debe ser compatible con Android.
artefacto
Es un registro relacionado con la compilación que permite solucionar problemas locales.
Documento de definición de compatibilidad (CDD)
Un documento que enumera los requisitos de software y hardware para un dispositivo compatible con Android.
Conjunto de pruebas de compatibilidad (CTS)

Un paquete de pruebas gratuito y de calidad comercial disponible para descargar como objeto binario o como fuente en el AOSP. El CTS es un conjunto de pruebas de unidades diseñado para integrarse en tu flujo de trabajo diario. El objetivo del CTS es revelar incompatibilidades y garantizar que el software siga siendo compatible a lo largo del proceso de desarrollo.

Las pruebas de CTS y de la plataforma no son mutuamente excluyentes. A continuación, se indican algunos lineamientos generales:

  • Si una prueba afirma la corrección de las funciones o los comportamientos de la API del framework, y la prueba se debe aplicar en todos los socios OEM, debe estar en el CTS.
  • Si una prueba tiene como objetivo detectar regresiones durante el desarrollo de la plataforma, puede requerir permisos privilegiados para llevarse a cabo y puede depender de detalles de implementación (como se lanzó en AOSP), debe ser una prueba de plataforma.
Servicios de Google para dispositivos móviles (GMS)

Una colección de apps y APIs de Google que se pueden preinstalar en dispositivos.

GoogleTest (GTest)

Es un framework de prueba y simulación de C++. Por lo general, los objetos binarios de GTest acceden a capas de abstracción de nivel inferior o realizan IPC sin procesar con varios servicios del sistema. El enfoque de prueba para GTest suele estar estrechamente relacionado con el servicio que se prueba. El CTS contiene el framework de GTest.

prueba de instrumentación

Es un entorno especial de ejecución de pruebas que se inicia con el comando am instrument, en el que se reinicia el proceso de la app objetivo y se inicializa con el contexto básico de la app, y se inicia un subproceso de instrumentación dentro de la máquina virtual del proceso de la app. El CTS contiene pruebas de instrumentación.

Logcat

Es una herramienta de línea de comandos que crea un registro de mensajes del sistema, incluidos los seguimientos de pila de cuando el dispositivo muestra un error y los mensajes que escribiste desde tu app con la clase Log.

logging

Usa un registro para hacer un seguimiento de los eventos del sistema informático, como los errores. El registro en Android es complejo debido a la combinación de estándares que se utilizan y que se combinan en la herramienta Logcat.

prueba posterior al envío

Es una prueba de Android que se realiza cuando se confirma un parche nuevo en una rama de kernel común. Si ingresas aosp_kernel como nombre de rama parcial, podrás ver una lista de ramas de kernel con resultados disponibles. Por ejemplo, los resultados de android-mainline se pueden encontrar en https://ci.android.com/builds/branches/aosp_kernel-common-android-mainline/grid.

Prueba previa a la confirmación

Es una prueba que se usa para evitar que se introduzcan fallas en los kernels comunes.

Federación de Comercio

También llamado Tradefed, es un framework de pruebas continuas diseñado para ejecutar pruebas en dispositivos Android. Por ejemplo, Tradefed se usa para ejecutar pruebas del Conjunto de pruebas de compatibilidad y del Conjunto de pruebas del proveedor.

Conjunto de pruebas de proveedores (VTS)

Un conjunto de capacidades extensas para las pruebas de Android, que promueve un proceso de desarrollo basado en pruebas y automatiza las pruebas del kernel de la capa de abstracción de hardware (HAL) y del SO.

Tipos de pruebas de plataformas

Por lo general, una prueba de plataforma interactúa con uno o más servicios del sistema Android o capas de HAL, ejercita las funcionalidades del sujeto en prueba y afirma la corrección del resultado de la prueba. Una prueba de plataforma podría hacer lo siguiente:

  • (Tipo 1) APIs del framework de ejercicios con el framework de Android Las APIs específicas que se ejercitan pueden incluir las siguientes:
    • APIs públicas diseñadas para apps de terceros
    • APIs ocultas destinadas a apps con privilegios, es decir, APIs del sistema o APIs privadas (@hide, protected, package private)
  • (Tipo 2) Invoca los servicios del sistema Android directamente con proxies de IPC o de Binder sin procesar.
  • (Tipo 3) Interactúa directamente con las HAL usando APIs de bajo nivel o interfaces de IPC.

Las pruebas de tipo 1 y 2 suelen ser pruebas de instrumentación, mientras que las de tipo 3 suelen ser GTests.

Próximos pasos

A continuación, se incluye una lista de documentos que puedes leer para obtener información más detallada: