Preguntas frecuentes sobre CTS

El Programa de compatibilidad de Android es el principal impulsor para mantener los comentarios positivos sobre el ecosistema de Android. El CTS es la herramienta clave para garantizar la calidad de la compatibilidad a gran escala. El equipo de Android sigue mejorando la herramienta de CTS y la cobertura de pruebas. La incorporación periódica de casos de prueba mejora significativamente la calidad de los dispositivos compatibles.

Preguntas generales

En esta sección, se proporcionan preguntas frecuentes generales sobre las 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 correctamente. El CTS también comprueba otros comportamientos del sistema que no son de la API, 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 las 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?

El CTS Sharding y el TF Sharding son planes de pruebas totalmente diferentes que se ejecutan con diferentes bases de código de infraestructura de pruebas. Si bien el comando de ejecución es el mismo en las diferentes versiones, el resultado del fragmentado se comporta de manera diferente. La fragmentación del CTS asigna de forma estática casos de prueba a los dispositivos en prueba (DUT) de la siguiente manera:

La fragmentación de TF asigna de forma dinámica casos de prueba a los DUT disponibles de la siguiente manera:

¿Qué se espera de un dispositivo que admite varias ABIs?

El dispositivo debe aprobar todas las pruebas de CTS y CTS Verifier para cada modo de ABI que afirme admitir. Por lo tanto, es necesario ejecutar una app para las ABIs específicas. Los lineamientos para varias ABIs son los siguientes:

  • En el caso del CTS y el CTS Verifier, hay versiones para ARM y x86 para cada arquitectura. Cada uno de ellos puede admitir el modo de 32 o 64 bits.
  • En el caso de las pruebas de CTS, si un dispositivo admite ARM y x86, debe ejecutar y aprobar las pruebas de CTS de ARM y x86, respectivamente.

Consulta CDD 3.3.1. Interfaces binarias de la aplicación para los requisitos del CDD sobre la ABI

¿Es suficiente ejecutar una prueba solo en la ABI principal (por ejemplo, de 64 bits) para reducir el tiempo de ejecución de la prueba?

No. Una app para Android se ejecuta en sus propios tiempos de ejecución de 32 o 64 bits. El código de máquina, la ruta de código y el estado reales son diferentes entre 32 y 64. Si omites un modo, solo cubrirás el 50% de la ABI del dispositivo.

¿Por qué hay tantos casos de prueba marcados como No ejecutados?

En su lugar, debes verificar la cantidad de Módulos completados, no la de No ejecutados.

En las versiones anteriores, los módulos de CTS se marcaban como Module Done de forma demasiado agresiva antes de completarse. Por lo tanto, se informó un número de Módulos completados sin que se completaran todos los casos de prueba, incluso cuando algunos dispositivos tenían problemas. El nuevo arnés de prueba es más conservador y registra una mayor cantidad de pruebas con el estado Not Executed cuando ocurre un problema.

Una ejecución de módulo que se completa informa Module Not Done en la invocación más reciente (done="false") en el informe durante lo siguiente:

  • Una prueba de ejecución del módulo se interrumpió debido a un problema de conexión del dispositivo.
  • No se realizaron todas las ejecuciones de prueba esperadas para el módulo.

  • Se volvió a intentar (con la opción -r/--retry) con opciones de filtrado adicionales, como las siguientes:

    • --include-filter
    • --exclude-filter
    • -t/--test (opción que aún no se admite en los reintentos)
    • --retry-type falló
    • --subplan

Para obtener el estado Module Done (done="true") para estos módulos, 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

En el nuevo informe, un módulo ejecutado sin ninguno de los problemas mencionados anteriormente (incluso con 0 pruebas restantes) se marca como Módulo completado.

Excepciones

  • CtsNNAPITestCases tiene un problema conocido debido a la limitación de argumentos de Linux/SO. El módulo se puede volver a ejecutar de forma aislada directamente a través de run cts -m CtsNNAPITestCases.

¿Cómo puedo evitar que la preparación de la prueba falle detrás del firewall corporativo?

Todos los paquetes de pruebas automatizadas intentan descargar los archivos multimedia de CTS o los archivos de lógica empresarial durante el tiempo de ejecución. En muchos entornos corporativos, es habitual que haya un firewall y un proxy, lo que provoca que falle la preparación de la prueba. Ejecuta la siguiente línea o agrégala a .profile (en Ubuntu).

export JAVA_TOOL_OPTIONS='-Djava.net.useSystemProxies=true'

¿Necesito una tarjeta SIM para las CTS del elemento seguro?

Si se necesita una tarjeta SIM para la prueba, depende de si se comprende si la función es compatible con el dispositivo de prueba.

  • Si tu dispositivo NO necesita admitir las apps para Android que acceden a elementos seguros (ya sea en la UICC [p.ej., una tarjeta SIM] distribuida por los operadores de redes móviles [operadores] o integrada en el dispositivo), puedes configurar el manifiesto de HIDL para que no incluya el elemento HAL android.hardware.secure_element. En este caso, la API de android.se.omapi.SEService.getReaders() informa una lista vacía, y la prueba de CTS se aprueba automáticamente y se informa una aprobación para el CTS.
  • Si tu dispositivo SÍ necesita admitir el acceso de las apps para Android a elementos seguros (ya sea en la UICC [p.ej., una tarjeta SIM] distribuida por los operadores de redes móviles [operadores] o integrada en el dispositivo), debes implementar el elemento seguro correctamente y probarlo internamente. En CTS Test for Secure Element, se describe cómo prepararse para ejecutar las pruebas de CTS que garantizan que el paquete de la API android.se.omapi agregado en Android 9 funcione correctamente. También recomendamos que realices pruebas adicionales por tu cuenta, ya que la cobertura de las pruebas del CTS es mínima.

¿Dónde puedo obtener las tarjetas SIM para las CTS del elemento seguro?

Puedes comunicarte con tu proveedor de SIM preferido.

¿Por qué aparece la SIM de Orange en la pantalla de bloqueo durante la ejecución de CTS con fragmentación de tokens?

El caso de prueba no se inicia porque la prueba de la tarjeta SIM está bloqueada. Inhabilita la opción Bloquear tarjeta SIM en **Configuración de bloqueo de la tarjeta SIM antes de ejecutar la CTS con fragmentación de tokens.