El Proyecto de código abierto de Android (AOSP) ofrece varias herramientas y paquetes de pruebas para probar varias partes de tu implementación. Antes de usar las páginas de esta 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). Compatible con Android son aptos para participar en el ecosistema de Android, que incluye una posible licencia de Google Play, de la paquete de Servicios de Google para dispositivos móviles (GMS) la app y las APIs, y el uso de la marca de Android. Todos son bienvenidos a usar el código fuente de Android, pero para que se considere parte del ecosistema de Android, Un dispositivo debe ser compatible con Android.
- artefacto
- Un registro relacionado con la compilación que habilita la solución de 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 durante todo el proceso de desarrollo.
Las pruebas de CTS y de plataforma no son excluyentes mutuamente. Estos son algunos conceptos generales lineamientos:
- Si una prueba afirma la precisión de las funciones o los comportamientos de la API de framework, y la prueba debe aplicarse a todos los socios OEM, debe estar en CTS.
- Si una prueba tiene como objetivo detectar regresiones durante el desarrollo de la plataforma, y pueden requerir permiso con privilegios para llevarlas a cabo y pueden ser dependientes sobre los detalles de implementación (como se lanzó en el AOSP), debe ser una plataforma la prueba.
- 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)
Un framework de prueba y simulación de C++. Objetos binarios de GTest en general acceder a capas de abstracción de nivel inferior o realizar IPC sin procesar en varios sistemas de Google Cloud. El enfoque de prueba de GTest suele tener un acoplamiento alto con el servicio que se está probando. El CTS contiene el framework de GTest.
- prueba de instrumentación
Un entorno de ejecución de pruebas especial que se inicia con el comando
am instrument
, donde el proceso de la app de destino se reinicia y se inicializa con el contexto básico de la app, y una el subproceso de instrumentación se inicia dentro del proceso virtual de la app máquina. El CTS contiene pruebas de instrumentación.- Logcat
Una herramienta de línea de comandos que crea un registro de los mensajes del sistema, incluido lo siguiente: seguimientos de pila de cuando el dispositivo arroja un error y mensajes que tienes escrito desde tu app con la clase
Log
.- Registro
Usar un registro para realizar un seguimiento de los eventos del sistema informático, como como errores. El registro en Android es complejo debido a la combinación de estándares que se usan se combinan en la herramienta Logcat.
- prueba posterior al envío
Es una prueba de Android que se realiza cuando se confirma un nuevo parche en un rama de kernel común. Si ingresas
aosp_kernel
como nombre de rama parcial, puede ver una lista de ramas de kernel con resultados disponibles. Por ejemplo, los resultados deandroid-mainline
en https://ci.android.com/builds/branches/aosp_kernel-common-android-mainline/grid.- prueba previa al envío
Es una prueba que se usa para evitar que se introduzcan fallas en el kernels comunes.
- Federación de Comercio
También llamado Tradefed, un sistema de pruebas 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 de proveedores.
- Conjunto de pruebas de proveedores (VTS)
Un conjunto de capacidades extensas para Pruebas de Android, promoción de un proceso de desarrollo basado en pruebas y automatización capa de abstracción de hardware (HAL) y pruebas del kernel del SO.
Tipos de prueba de la plataforma
Una prueba de plataforma generalmente interactúa con uno o más de los dispositivos del sistema Android servicios o capas de HAL, ejecuta la funcionalidades del sujeto de prueba y afirma la veracidad de las resultado de la prueba. Una prueba de plataforma podría tener las siguientes características:
- (Tipo 1) APIs del framework de ejercicio con el framework de Android. APIs específicas
ejercido pueden incluir:
- APIs públicas diseñadas para apps de terceros
- Las APIs ocultas destinadas a aplicaciones con privilegios, es decir, las APIs del sistema o
APIs privadas (
@hide
oprotected
,package private
)
- (Tipo 2) Invocar servicios del sistema Android con enlaces sin procesar o proxies IPC directamente.
- (Tipo 3) Interactúa directamente con las HALs usando interfaces de IPC o APIs de bajo nivel.
Las pruebas de tipo 1 y 2 suelen ser de instrumentación, mientras que las de tipo 3 generalmente GTests.
¿Qué sigue?
Esta es una lista de documentos que puedes leer para obtener información más detallada:
Si todavía no estudiaste la arquitectura de Android, consulta Descripción general de la arquitectura.
Si estás creando un dispositivo compatible con Android, consulta Descripción general del Programa de compatibilidad de Android
Para integrar pruebas de host de instrumentación, funcionales, de métricas y JAR en un servicio de pruebas continuas de plataforma, consulta Flujo de trabajo de desarrollo de pruebas.
Para detectar y endurecer tus dispositivos contra vulnerabilidades, consulta Pruebas de seguridad.
Para obtener información sobre cómo probar las implementaciones del kernel y la HAL, consulta Infraestructura y Conjunto de pruebas de proveedores (VTS).
Para probar apps, lee lo siguiente: Aspectos básicos para probar Android apps y realizar el curso Advanced Android in Kotlin 05.1:Testing Conceptos básicos con el muestras proporcionadas.
Obtén más información sobre las pruebas básicas previas al envío disponibles a través de hooks de repositorio. Estos hooks se pueden usar para ejecutar linters, verificar el formato y activar unidades. realizar pruebas antes de continuar, como subir una confirmación. Estos hooks están inhabilitados de forma predeterminada. Para obtener más información, consulta Carga previa de AOSP Ganchos
Para leer más sobre el registro, consulta Comprende el registro.
Para comprender cómo depurar código de Android, consulta Depura el código nativo de la plataforma de Android.