Preguntas frecuentes sobre CTS

El Programa de compatibilidad de Android es el factor clave para mantener los comentarios positivos en el ecosistema de Android. CTS es la herramienta clave para garantizar la calidad de la compatibilidad en la escala. El equipo de Android sigue mejorando la herramienta de CTS y la cobertura de pruebas. La adició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 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 correctamente. El CTS también prueba 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 pruebas del CTS de manera más eficiente.

¿Cuál es la diferencia entre el fragmentación de CTS y el fragmentación de TF?

La fragmentación de CTS y la fragmentación de TF son planes de prueba totalmente diferentes con la tecnología de una base de código de infraestructura de prueba diferente. Si bien el comando de ejecución es el mismo en diferentes versiones, el resultado de la fragmentación se comporta de manera diferente. La fragmentación de 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 ABI?

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 en particular. Los lineamientos para varias ABIs son los siguientes:

  • En el caso del CTS y el verificador del CTS, hay versiones para ARM y x86 para cada arquitectura. Cada uno de ellos puede admitir el modo de 32 o 64 bits.
  • Para las pruebas de CTS, si un dispositivo admite ARM y x86, debe ejecutar 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, la ruta de acceso del código y el estado reales difieren entre 32 y 64. Si omites un modo, solo cubres el 50% de la ABI del dispositivo.

¿Por qué hay tantos casos de prueba que se informan como No ejecutados?

Debes verificar el número Module Done en lugar del número Not Executed.

En las versiones anteriores, los módulos de CTS se informaban como Module Done de manera demasiado agresiva antes de completarse. Por lo tanto, se informó un número de Modules Done sin que se completara todo el caso de prueba, incluso cuando algunos dispositivos tuvieron problemas. El nuevo conjunto de pruebas es más conservador y informa una mayor cantidad de pruebas Not Executed cuando se produce un problema.

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

  • Un problema de conexión del dispositivo interrumpió una ejecución de prueba del módulo.
  • 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 (la opción aún no es compatible con la reintento)
    • Falló el parámetro --retry-type
    • --subplan

Si quieres obtener un estado de 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

Un módulo que se ejecutó sin ninguno de los problemas mencionados anteriormente (incluso con 0 pruebas restantes) se marca como Module Done en el informe nuevo.

Excepciones

  • CtsNNAPITestCases tiene un problema conocido debido a la limitación de los argumentos de Linux/SO. 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 automatizados intentan descargar los archivos multimedia de CTS o los archivos de lógica empresarial durante el tiempo de ejecución. En muchos entornos empresariales, el uso de un firewall y un proxy es común, lo que hace que la preparación de la prueba falle. 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 el Elemento seguro?

La necesidad de una tarjeta SIM para la prueba depende de 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) que distribuyen los operadores de red móvil (operadores) o que están incorporados 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 un pase para el CTS.
  • Si tu dispositivo NECESITA admitir apps para Android que accedan a elementos seguros, ya sea en la UICC (p.ej., una tarjeta SIM) que distribuyen los operadores de red móvil (operadores) o incorporados en el dispositivo, debes implementar el elemento seguro correctamente y probarlo de forma interna. En Prueba de CTS para elementos seguros, se describe cómo prepararse para ejecutar las pruebas de CTS que garantizan que el paquete de API android.se.omapi agregado en Android 9 sea funcional. También te recomendamos que realices 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 el Elemento seguro?

Puedes comunicarte con tu proveedor de SIM preferido.

¿Por qué la SIM de Orange aparece 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 tarjeta SIM está bloqueada. Inhabilita la opción Bloquear tarjeta SIM en la configuración de bloqueo de la tarjeta SIM antes de ejecutar el CTS con fragmentación de tokens.