A partir del 27 de marzo de 2025, te recomendamos que uses android-latest-release en lugar de aosp-main para compilar y contribuir a AOSP. Para obtener más información, consulta Cambios en AOSP.

Se usó la API de Cloud Translation para traducir esta página.

Consola de comandos de CTS v2
Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

Usa la consola de CTS v2

Para Android 7.0 o versiones posteriores, usa CTS v2.

Selecciona planes

Entre los planes de prueba disponibles, se incluyen los siguientes:

cts: Ejecuta CTS desde una instalación de CTS preexistente.
cts-camera: Ejecuta CTS-camera desde una instalación de CTS preexistente.
cts-java: Ejecuta pruebas de Java principales desde una instalación de CTS preexistente.
cts-pdk: Ejecuta pruebas útiles para validar una compilación de fusión de PDK.
everything: Configuración común para los paquetes de compatibilidad.

Otras configuraciones disponibles incluyen las siguientes:

basic-reporters: Configuración con generadores de informes CTS básicos.
collect-tests-only: Ejecuta CTS desde una instalación de CTS preexistente.
common-compatibility-config: Es la configuración común para los paquetes de compatibilidad.
cts-filtered-sample: Configuración común para los paquetes de compatibilidad.
cts-known-failures: Configuración con fallas conocidas de CTS.
cts-preconditions: Configuraciones de condiciones previas de CTS.
host: Ejecuta una sola prueba basada en host en un dispositivo existente.
instrument: Ejecuta una sola prueba de instrumentación de Android en un dispositivo existente.
native-benchmark: Ejecuta una prueba de esfuerzo nativa en un dispositivo existente.
native-stress: Ejecuta una prueba de esfuerzo nativa en un dispositivo existente.
recharge: Es una prueba falsa que espera a que los dispositivos estén casi descargados y los mantiene para cargarlos.
testdef: Ejecuta las pruebas contenidas en los archivos test_def.xml en un dispositivo existente.
util/wifi: Es la configuración de utilidad para configurar Wi-Fi en el dispositivo.
util/wipe: Limpia los datos del usuario en el dispositivo.

Todos estos planes y parámetros de configuración se pueden ejecutar con el comando run cts.

Referencia de comandos de la consola de CTS v2

En esta tabla, se resumen los comandos de la consola de CTS v2 para varios usos.

Host	Descripción
`help`	Muestra un resumen de los comandos más utilizados
`help all`	Muestra la lista completa de los comandos disponibles
`version`	Muestra la versión.
`exit`	Sal de la consola de CTS de forma correcta. La consola se cierra cuando terminan todas las pruebas que se están ejecutando.
`extdir`	El archivo de descargas comprimido se descomprime en `extdir`. Si quieres deshacerte del resultado aumentado, usa la opción `-q`: `unzip -q android-cts-9.0_r15-linux_x86-arm.zip -d extdir` Si quieres descomprimir en el directorio actual, no uses la opción `-d`, simplemente ejecuta lo siguiente: `unzip -q android-cts-9.0_r15-linux_x86-arm.zip`
Ejecutar	Descripción
`run cts`	En Android 10, ejecuta el plan de CTS predeterminado y CTS-Instant juntos (es decir, la invocación de CTS completa). En Android 9 o versiones anteriores, ejecuta solo el plan de CTS predeterminado. Usa esta opción integral (incluidas las condiciones previas) para la validación de dispositivos. Consulta cts.xml para ver las inclusiones. La consola de CTS puede aceptar otros comandos mientras se realizan las pruebas. Si no hay ningún dispositivo conectado, la máquina de escritorio (o host) de CTS esperará a que se conecte un dispositivo antes de iniciar las pruebas. Si hay más de un dispositivo conectado, el host de CTS elegirá uno automáticamente.
`run cts-instant`	Para Android 9, ejecuta el plan predeterminado de CTS-Instant.
`run cts --module-parameter INSTANT_APP`	En Android 10, ejecuta el plan predeterminado de CTS-Instant.
`run cts --module-parameter INSTANT_APP --module/-m test_module_name`	En Android 10, ejecuta los módulos de prueba de CTS-Instant especificados.
`run retry`	Solo para Android 9 o versiones posteriores. Vuelve a ejecutar todas las pruebas que fallaron o que no se ejecutaron en las sesiones anteriores. Por ejemplo, `run retry --retry -s` o `run retry --retry --shard-count` con el particionado de TF. No se permite `run cts --retry` en Android 9 o versiones posteriores.
`run cts-sim`	Para Android 11 o versiones posteriores. Ejecuta el subconjunto de pruebas en un dispositivo con tarjeta SIM.
`--device-token`	Para Android 8.1 o versiones anteriores. Especifica que un dispositivo determinado tiene el token determinado. Por ejemplo, `--device-token 1a2b3c4d:sim-card`.
`--enable-token-sharding`	Solo para Android 10 o versiones posteriores. Coincide automáticamente con la prueba que requiere el tipo de SIM correspondiente. No es necesario proporcionar un número de serie del dispositivo para ejecutar casos de prueba relacionados con la SIM. SIM compatibles: `SIM_CARD`, `UICC_SIM_CARD` y `SECURE_ELEMENT_SIM_CARD`.
`run cts-dev`	Ejecuta el plan de CTS predeterminado (es decir, la invocación de CTS completa), peroomite las condiciones previas para ahorrar tiempo de ejecución para el desarrollo iterativo de una prueba nueva. Esto evita la verificación y configuración del dispositivo, como enviar archivos multimedia o verificar la conexión Wi-Fi, como se hace cuando se usa la opción `--skip-preconditions`. Este comando también omite la recopilación de información del dispositivo y todos los verificadores de estado del sistema. También ejecuta las pruebas en una sola ABI. Para la validación de dispositivos, evita esta optimización y incluye todas las condiciones previas y verificaciones. Consulta cts-dev.xml para ver las exclusiones. La consola de CTS puede aceptar otros comandos mientras se realizan las pruebas. Si no hay ningún dispositivo conectado, la máquina de escritorio (o host) de CTS esperará a que se conecte un dispositivo antes de iniciar las pruebas. Si hay más de un dispositivo conectado, el host de CTS elegirá uno automáticamente.
`--subplan subplan_name`	Ejecuta el subplan especificado.
`--module/-m test_module_name --test/-t test_name`	Ejecuta el módulo y la prueba especificados. Por ejemplo, `run cts -m Gesture --test android.gesture.cts.GestureTest#testGetStrokes` ejecuta el paquete, la clase o la prueba específicos. Precaución: No uses esta opción cuando uses la opción `--include-filter`.
`--retry`	Vuelve a ejecutar todas las pruebas que fallaron o que no se ejecutaron en las sesiones anteriores. Usa `list results` para obtener el ID de sesión.
`--retry-type NOT_EXECUTED`	Vuelve a intentar solo las pruebas que no se ejecutaron en las sesiones anteriores. Usa `list results` para obtener el ID de sesión.
`--shards number_of_shards`	Para Android 8.1 y versiones anteriores. Fragmenta una ejecución de CTS en una cantidad determinada de partes independientes para ejecutarlas en varios dispositivos en paralelo.
`--shard-count number_of_shards`	Para Android 9. Fragmenta una ejecución de CTS en una cantidad determinada de fragmentos independientes para ejecutarlas en varios dispositivos en paralelo.
`--serial/-s deviceID`	Ejecuta CTS en el dispositivo específico.
`--include-filter "test_module_name test_name"`	Ejecuta con los módulos especificados, o bien prueba paquetes, clases y casos. Por ejemplo, `run cts --include-filter "CtsCalendarcommon2TestCases android.calendarcommon2.cts.Calendarcommon2Test#testStaticLinking"` incluye el módulo especificado. Esta opción de comando no se admite cuando se ejecuta la acción de reintento. Precaución: No uses esta opción cuando uses la opción `--module/-m`.
`--exclude-filter "test_module_name test_name"`	Excluye de la ejecución los módulos especificados, o bien los paquetes, las clases y los casos de prueba. Por ejemplo, `run cts --exclude-filter "CtsCalendarcommon2Test android.calendarcommon2.cts.Calendarcommon2Test#testStaticLinking"` excluye el módulo especificado.
`--log-level-display/-l log_level`	Ejecuta con el nivel de registro mínimo especificado que se muestra en `STDOUT`. Valores válidos: [`VERBOSE`, `DEBUG`, `INFO`, `WARN`, `ERROR`, `ASSERT`].
`--abi abi_name`	Fuerza la prueba para que se ejecute en la ABI determinada, 32 o 64. De forma predeterminada, CTS ejecuta una prueba una vez por cada ABI que admite el dispositivo.
`--logcat-on-failure`, `--bugreport-on-failure`, `--screenshoot-on-failure`	Proporcionan más visibilidad de las fallas y pueden ayudar con los diagnósticos.
`--device-token`	Especifica que un dispositivo determinado tiene el token determinado, como `--device-token 1a2b3c4d:sim-card`.
`--skip-device-info`	Omite la recopilación de información sobre el dispositivo. Precaución: No uses esta opción cuando ejecutes CTS para su aprobación.
`--skip-preconditions`	Omitir las condiciones previas para ahorrar tiempo de ejecución en el desarrollo iterativo de una prueba nueva Esto evita la verificación y configuración del dispositivo, como enviar archivos multimedia o verificar la conexión Wi-Fi.
Lista	Descripción
`list modules`	Enumera todos los módulos de prueba disponibles en el repositorio.
`list plans` o `list configs`	Enumera todos los planes de prueba (parámetros de configuración) disponibles en el repositorio.
`list subplans`	Enumera todos los subplanes disponibles en el repositorio.
`list invocations`	Muestra una lista de los comandos run que se están ejecutando actualmente en los dispositivos.
`list commands`	Muestra una lista de todos los comandos run que se encuentran en la cola esperando a que se les asigne un dispositivo.
`list results`	Muestra una lista de los resultados de CTS que se almacenan actualmente en el repositorio.
`list devices`	Muestra una lista de los dispositivos conectados actualmente y su estado. Los dispositivos disponibles son dispositivos inactivos que funcionan y están disponibles para ejecutar pruebas. Los dispositivos no disponibles son dispositivos visibles a través de adb, pero no responden a los comandos de adb y no se asignarán para las pruebas. Los dispositivos asignados son dispositivos que ejecutan pruebas actualmente.
Volcado	Descripción
`dump logs`	Vacía los registros de tradefed para todas las invocaciones en ejecución.
Agregar	Descripción
`add subplan --name/-n subplan_name --result-type [passed \| failed \| not_executed] [--session session_id]`	Crear un subplan derivado de la sesión anterior: Esta opción genera un subplan que se puede usar para ejecutar un subconjunto de pruebas. La única opción obligatoria es `--session`. Otros son opcionales, pero, cuando se incluyen, deben ir seguidos de un valor. La opción `--result-type` se puede repetir. Por ejemplo, `add subplan --session 0 --result-type passed --result-type failed` es válido.