El Programa de compatibilidad de Android es el impulsor clave para sustentar los comentarios positivos del ecosistema de Android. CTS es la herramienta clave para garantizar la calidad de compatibilidad en la escala. El El equipo de Android continúa mejorando la cobertura de pruebas y de la herramienta CTS. El de agregar casos de prueba mejoró significativamente la calidad de dispositivos compatibles.
Preguntas generales
En esta sección, se proporcionan preguntas frecuentes generales sobre el CTS.
¿Qué tipo de pruebas incluye el CTS?
El CTS comprueba que todas las APIs de tipado fuerte compatibles con Android están presentes y se comporten de forma correcta. El CTS también prueba otros sistemas que no son de API de seguridad, como el ciclo de vida y el rendimiento de la app.
¿Cómo se otorga la licencia del CTS?
El CTS está protegido bajo la misma licencia de software Apache 2.0 que utiliza la mayor parte de Android.
¿El CTS verifica los códecs?
Sí. El CTS verifica todos los códecs obligatorios.
Preguntas específicas de la prueba
En esta sección, se proporcionan preguntas frecuentes que ayudan a ejecutar pruebas del CTS de manera más eficiente.
¿Cuál es la diferencia entre la fragmentación de CTS y la fragmentación de TF?
La fragmentación de CTS y la fragmentación de TF son planes de prueba totalmente diferentes potenciados por en una base de código de infraestructura de prueba diferente. Si bien el comando run es el en diferentes versiones, el resultado de la fragmentación se comporta de manera diferente. La fragmentación de CTS asigna casos de prueba de forma estática a los dispositivos en prueba (DUT) de la siguiente manera:
- Comando: run cts
- Configuración para Android 8.1 y versiones anteriores: /tools/cts-tradefed/res/config/cts.xml
La fragmentación de TF asigna de forma dinámica casos de prueba a los DUT disponibles de la siguiente manera:
- Comando: run cts
- Configuración para Android 9: /platform/test/suite_harness/+/pie-cts-dev/tools/cts-tradefed/res/config/cts-suite.xml
¿Qué se espera de un dispositivo que admita varias ABI?
El dispositivo debe pasar todas las pruebas del verificador del CTS y el CTS para cada modo de ABI en el que afirma respaldar. Por lo tanto, es necesario ejecutar una app para el ABI específicas. Los lineamientos para varias ABI son los siguientes:
- Para el verificador del CTS y el CTS, hay versiones ARM y x86 para cada arquitectura. Cada uno de ellos admite el modo de 32 o 64 bits.
- Para las pruebas de CTS, si un dispositivo admite ARM y x86, debe ejecutarse y pasar las pruebas ARM y x86 del CTS, respectivamente.
Consulta el CDD 3.3.1. Interfaces binarias de la aplicación para los requisitos de CDD en ABI.
¿Es suficiente ejecutar una prueba solo en la ABI principal (por ejemplo, 64 bits) para reducir el tiempo de ejecución de la prueba?
No. Las apps para Android se ejecutan en sus propios entornos de ejecución de 32 o 64 bits. El código máquina real, la ruta del código y el estado son diferentes entre 32 y 64 años. Si omites un modo, solo cubres el 50% de la ABI del dispositivo.
¿Por qué hay tantos casos de prueba informados como sin ejecutar?
En su lugar, debes verificar el número de Module Done. de la cantidad de No ejecutadas.
En las versiones anteriores, los módulos de CTS también se informaban como Module Done. agresivamente antes de completarse. Por lo tanto, la cantidad de Módulos Listos se informó sin que se completara todo el caso de prueba, incluso cuando algunos dispositivos tuve problemas. El nuevo agente de prueba es más conservador e informa un una mayor cantidad de pruebas No ejecutadas cuando se produce un problema.
Un módulo ejecutado hasta la finalización de informes Módulo no finalizado en la invocación reciente (done="false") en el informe durante lo siguiente:
- Se interrumpió la ejecución de prueba del módulo debido a un problema de conexión del dispositivo.
- No se realizaron todas las ejecuciones de prueba esperadas para el módulo.
Se reintentó (con la opción
-r/--retry) con opciones de filtrado adicionales. por ejemplo:- --incluir-filtro
- --excluir-filtro
- -t/--test (Opción aún no compatible con reintentos)
- --reintento de tipo de error
- --subplan
Para obtener el estado de Module Done (done="true") para estos módulos, haz lo siguiente: vuelve a intentar lo siguiente para la invocación más reciente:
run retry --retry <session_id> for Android 9 and later versions
run cts --retry <session_id> for Android 8.1 and previous versions
Un módulo ejecutado sin ninguno de los problemas mencionados anteriormente (incluso con 0 pruebas restantes) se marca como Módulo Listo en el nuevo informe.
Excepciones
- CtsNNAPITestCases tiene un problema conocido debido a la limitación de argumentos de Linux/OS.
Se puede volver a ejecutar el módulo de forma aislada directamente a través de
run cts -m CtsNNAPITestCases.
¿Cómo puedo evitar errores en la preparación de la prueba detrás del firewall corporativo?
Todos los paquetes de pruebas automatizadas intentan descargar los archivos multimedia de CTS o la archivos de lógica empresarial durante el tiempo de ejecución. En muchos entornos corporativos, un firewall y proxy es habitual, lo que hace que la preparación de la prueba falle. Ejecución la siguiente línea o agregarla a .profile (en Ubuntu).
export JAVA_TOOL_OPTIONS='-Djava.net.useSystemProxies=true'
¿Necesito una tarjeta SIM para CTS para el Elemento seguro?
El hecho de que se necesite una tarjeta SIM para la prueba depende de la comprensión si la función es compatible con el dispositivo de prueba.
- Si tu dispositivo NO necesita admitir el acceso de las apps para Android
de elementos seguros, ya sea en la
UICC
(por ejemplo, una tarjeta SIM) distribuida por operadores de red móvil
(proveedores) o integrado en el dispositivo, puedes configurar el HIDL
manifiesto para no incluir la HAL de
android.hardware.secure_element. En este caso, el android.se.omapi.SEService.getReaders() La API informa una lista vacía y la prueba del CTS automáticamente pasa e informa un aprobado para el CTS. - Si tu dispositivo SÍ necesita admitir que las apps para Android accedan a cualquiera de las siguientes opciones: de elementos seguros, ya sea en la interfaz UICC (p.ej., una tarjeta SIM) distribuida por operadores de red móvil (proveedores) o incorporadas en el dispositivo, debes implementar el Elemento seguro correctamente y probarlo internamente. Prueba de CTS para el Elemento seguro describe cómo prepararse para ejecutar las pruebas del CTS que garanticen android.se.omapi El paquete de API que se agregó en Android 9 es funcional. También recomendamos realizar pruebas adicionales por su cuenta, ya que la cobertura de la prueba del CTS es mínimo.
¿Dónde puedo obtener las tarjetas SIM del CTS para el Elemento seguro?
Puedes comunicarte con tu proveedor de SIM preferido.
¿Por qué aparece la tarjeta SIM naranja en la pantalla de bloqueo durante la ejecución del CTS con fragmentación de tokens?
El caso de prueba no se inicia porque la prueba de la tarjeta SIM está bloqueada. Desactiva la opción Bloquear tarjeta SIM en **Configuración de bloqueo SIM antes la ejecución del CTS con fragmentación de tokens.