Preguntas frecuentes sobre CTS

El Programa de compatibilidad de Android es el factor clave para mantener los comentarios positivos del ecosistema de Android. CTS es la herramienta clave para garantizar la calidad de la compatibilidad a gran escala. El equipo de Android sigue mejorando la herramienta 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 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. Además, comprueba otros comportamientos del sistema que no son de la API, como el ciclo de vida y el rendimiento de la aplicación.

¿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 sobre las pruebas

En esta sección, se proporcionan preguntas frecuentes que ayudan a ejecutar las pruebas de CTS de manera más eficiente.

¿Cuál es la diferencia entre CTS Sharding y TF Sharding?

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

TF Sharding 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 del verificador de CTS para cada modo de ABI que afirme admitir. Por lo tanto, es necesario ejecutar una app para las ABIs particulares. Los lineamientos para varias ABIs son los siguientes:

  • Para CTS y el verificador de CTS, existen versiones de ARM y x86 para cada arquitectura. Cada una de ellas puede admitir el modo de 32 o 64 bits.
  • Para 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 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. Una app para Android se ejecuta en sus propios entornos de ejecución de 32 o 64 bits. El código máquina, las instrucciones 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 informados como No ejecutados?

Debes verificar el número de Módulo completado en lugar del número de No ejecutado.

En las versiones anteriores, los módulos de CTS se informaban como Módulo completado de forma demasiado agresiva antes de completarse. Por lo tanto, se informaba un número de Módulos completados sin que se completara el caso de prueba, incluso cuando algunos dispositivos tenían problemas. El nuevo agente de prueba es más conservador y muestra una mayor cantidad de pruebas No ejecutadas cuando ocurre un problema.

Un módulo que se ejecuta hasta completarse informa Módulo no completado en la invocación más reciente (done="false") en el informe durante lo siguiente:

  • Una prueba para el 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 reintentó (con la opción -r/--retry) con opciones de filtrado adicionales, como las siguientes:

    • --include-filter
    • --exclude-filter
    • -t/--test (aún no se admite la opción en el reintento)
    • --retry-type failed
    • --subplan

Para obtener un estado de Módulo completado (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

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

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 a través de run cts -m CtsNNAPITestCases directamente.

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

Todos los conjuntos 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 un firewall y un proxy, lo que hace 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 CTS para Secure Element?

Si se necesita una tarjeta SIM para la prueba, depende de si se admite la función en 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 muestra una aprobación para el CTS.
  • Si tu dispositivo NECESITA admitir 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, debes implementar el elemento seguro correctamente y probarlo internamente. En la prueba de CTS para Secure Element se describe cómo prepararse para ejecutar las pruebas de CTS que garantizan que el paquete de la API de android.se.omapi agregado en Android 9 sea funcional. También recomendamos realizar pruebas adicionales por tu cuenta, ya que la cobertura de pruebas de CTS es mínima.

¿Dónde puedo obtener las tarjetas SIM para CTS para Secure Element?

Puedes comunicarte con tu proveedor de SIM preferido.

¿Por qué aparece la tarjeta 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 tarjeta SIM** antes de ejecutar el CTS con fragmentación de tokens.

Ejecución de pruebas cuando las marcas de funciones están inhabilitadas en el dispositivo

Para todas las marcas en las compilaciones de lanzamiento, la anotación @RequiresFlagsEnabled o @RequiresFlagsDisabled usa los valores de las marcas de la configuración de lanzamiento binario de CTS, no de la configuración de lanzamiento del dispositivo. Inhabilitar las marcas en el dispositivo no inhabilita la prueba, ya que el conjunto de pruebas de CTS que se ejecutan para un lanzamiento determinado se fija en la configuración publicada de la plataforma AOSP.