Ejecuta pruebas del verificador de CTS del host

En esta página, se incluyen instrucciones para configurar y ejecutar las pruebas de Android 16 QPR2 y Android 17 del verificador de CTS (CTS-V) del host. Hay dos tipos de pruebas del host: pruebas de varios dispositivos (introducidas antes de Android 17) y pruebas interactivas (novedad de Android 17):

  • Las pruebas en varios dispositivos son pruebas completamente automatizadas.
  • Las pruebas interactivas son pruebas semiautomatizadas que requieren que realices algunos pasos manuales en el dispositivo bajo prueba (DUT).

Además de las nuevas pruebas interactivas, convertimos las pruebas manuales de precisión de rango y de telecomunicaciones en pruebas multidispositivo del host, y ahora se requieren las pruebas de conexión Wi-Fi.

Cómo configurar pruebas del host

Sigue estos pasos para configurar pruebas del lado del host (las pruebas en varios dispositivos requieren una configuración adicional):

  1. Verifica que tu computadora de escritorio cumpla con los requisitos del sistema operativo para CTS.
  2. Sigue los pasos 2 y 5 de Instala software para computadoras para instalar y verificar que adb, AAPT2 y Python estén instalados correctamente en tu computadora.
    • La versión de Python debe ser 3.11 o posterior. Para determinar tu versión de Python, ejecuta python3 --version. Si la versión es anterior a la 3.11, instala la versión oficial más reciente de Python. Para obtener más información, consulta la sección de descargas de python.org.
    • Algunas pruebas requieren que el host tenga el módulo venv de Python. En los sistemas Debian y Ubuntu, es posible que este módulo no esté instalado de forma predeterminada. Para determinar si tu versión de Python tiene el módulo venv, ejecuta python3 -m venv venv. Si este comando falla, se mostrará un mensaje de error. Sigue las indicaciones para instalar el paquete python3.x-venv.

Si solo ejecutas las pruebas interactivas del host, continúa con Ejecuta pruebas del host. Sin embargo, si deseas ejecutar pruebas en varios dispositivos, continúa con Configura pruebas en varios dispositivos del lado del host.

Configura pruebas multidispositivo del host

Sigue estos pasos para configurar pruebas multidispositivo del host:

  1. Verifica que tu computadora de escritorio cumpla con los requisitos del sistema operativo para CTS.

  2. Sigue los pasos 2 y 5 de Instala software para computadoras para instalar y verificar que adb, AAPT2 y Python estén instalados correctamente en tu computadora.

    • La versión de Python debe ser 3.11 o posterior. Para determinar tu versión de Python, ejecuta python3 --version. Si la versión es anterior a la 3.11, instala la versión oficial más reciente de Python. Para obtener más información, consulta la sección de descargas de python.org.
    • Algunas pruebas requieren que el host tenga el módulo venv de Python. En los sistemas Debian y Ubuntu, es posible que este módulo no esté instalado de forma predeterminada. Para determinar si tu versión de Python tiene el módulo venv, ejecuta python3 -m venv venv. Si este comando falla, se mostrará un mensaje de error. Sigue las indicaciones para instalar el paquete python3.x-venv.

  3. Prepara dos DUTs coincidentes, cada uno con CTS-V configurado.

  4. Ve a la sección de configuración de tu tipo de prueba:

Si tu prueba no está en esta lista, continúa con Cómo configurar pruebas estándar con dos dispositivos.

Cómo configurar pruebas de NFC

Las pruebas de NFC usan un DUT y un chip NFC PN532.

Para configurar pruebas de NFC, haz lo siguiente:

  1. Compra un chip NFC PN532. Te recomendamos el All-In-One PN532.
  2. En el DUT, navega a la app de Configuración.
  3. Habilita NFC.

  4. Coloca el chip NFC de la siguiente manera:

    • En el caso de los teléfonos, coloca el lector NFC del DUT como se muestra en la figura 1:

      Posicionamiento del chip NFC

      Figura 1: Posicionamiento del chip NFC

    • En otros tipos de dispositivos, coloca el chip junto a la antena NFC del dispositivo.

  5. Conecta el chip NFC PN532 a tu estación de trabajo de prueba con un cable USB.

Configura pruebas de conexión de AP Wi-Fi

Las pruebas de conexión del punto de acceso Wi-Fi (AP) (CtsWifiConnectionTests) prueban la conectividad entre un DUT y un AP. Puedes configurar estas pruebas de las siguientes dos maneras:

  • Opción 1: Usa una red Wi-Fi existente que configuraste para CTS-V.
  • Opción 2: Configura un punto de acceso (AP) programable.

Para Android 17, recomendamos la opción 2, pero no es obligatoria. En las siguientes dos secciones, se explica cada opción.

Opción 1: Usa una red Wi-Fi existente que configuraste para CTS-V

La opción 1 requiere un DUT de Android dentro del área de cobertura de la red Wi-Fi. Si el DUT está en una caja de aislamiento y no se puede conectar a la red Wi-Fi, quítalo de la caja.

Opción 2: Configura un AP programable

Para configurar un AP programable para las pruebas de conexión Wi-Fi, haz lo siguiente:

  1. Compra el AP de Banana Pi R3 y configúralo. Para obtener información sobre cómo comprar y configurar el AP de Banana Pi R3, consulta Cómo configurar el AP de Banana Pi BPI-R3.

  2. Opcional: Si no tienes una caja de protección, te recomendamos la caja de protección JTP-SR101. Compra esta caja con la siguiente información:

    Dong Guan Zheng Sheng Electronics Technology Co., LTD
    Bohui Industrial Park, Panlong Road, Liaobu Town, Dongguan City, Guangdong Province, China
    Contacto: Forest Pan
    Correo electrónico: forest.pan@jtpmak.cn
    Teléfono (China): +86 18676993556

  3. Conecta el DUT y el AP al host, y colócalos en una caja de protección contra RF. El DUT y el AP deben estar separados por al menos 10 cm. En la figura 2, se muestra esta configuración:

    DUT y AP en caja blindada

    Figura 2: DUT y AP en caja blindada.

  4. Usa SSH para verificar que se pueda acceder al AP desde el host.

Configura pruebas de precisión de rango

Para configurar pruebas de precisión de rango, haz lo siguiente:

  1. Coloca dos DUTs de Android coincidentes a 1 metro de distancia, a la misma altura, con línea de visión directa y con la parte posterior de cada dispositivo orientada hacia el otro. En la figura 3, se muestra esta orientación:

    Orientación del dispositivo

    Figura 3: Es la orientación del dispositivo.

  2. Conecta ambos dispositivos a la computadora de escritorio con cables USB.

Cómo configurar pruebas estándar con dos dispositivos

Para la configuración predeterminada de dos dispositivos, haz lo siguiente:

  1. Coloca dos DUTs de Android coincidentes a una distancia aproximada de 20 cm.

  2. Muy recomendable: Coloca ambos dispositivos en una caja de protección. La caja de protección mejora la estabilidad de las pruebas y facilita la depuración de las fallas.

  3. Para las pruebas de telecomunicaciones, cada DUT debe tener una tarjeta SIM y señal celular. Si los DUT se encuentran en una caja de aislamiento, la señal celular debe acoplarse a la caja. De lo contrario, saca los dispositivos de la caja de aislamiento.

  4. Opcional: Configura un analizador de OTA para la depuración de Wi-Fi.

Configura pruebas de CDM

El caso de prueba test_permissions_sync() tiene un comportamiento diferente según el tipo de compilación de los dispositivos en los que se ejecuta la prueba. Es fundamental que los OEM prueben ambas compilaciones, tanto las depurables (userdebug o eng) como las no depurables (user), y que las pruebas se aprueben para ambas.

Exención

La cláusula de CDD para la implementación de la API de sincronización de permisos solo requiere que pueda transferir datos correctamente entre dispositivos a través de un canal seguro. Dado que la implementación del canal seguro no es un requisito de cumplimiento del CDD, esta prueba se puede omitir en las compilaciones no depurables (del usuario), pero solo si deseas inhabilitar la compatibilidad con la función de sincronización de permisos del CDM.

Las pruebas deben aprobarse en compilaciones depurables sin excepciones.

Requisitos previos para realizar pruebas en compilaciones no depurables

Si no estás exento, verifica que cumplas con los siguientes requisitos previos.

El canal seguro usa AVF (AttestationVerificationFramework) para verificar la confiabilidad del hardware. Las certificaciones generadas por ambas partes contienen varios elementos de información sobre sí mismas para verificar que no se haya producido ninguna alteración no autorizada en su sistema. Durante el proceso de verificación, AVF comprueba los siguientes estados:

  • El dispositivo tiene acceso a Internet
  • El dispositivo usa el inicio verificado y la compilación debe firmarse con una clave de lanzamiento, no con una clave de desarrollo.
  • El dispositivo tiene el bootloader bloqueado. Para obtener instrucciones detalladas, consulta Cómo bloquear el bootloader.
  • Los niveles de parche del SO, el arranque de la llave y el proveedor de la llave deben estar dentro de los 12 meses. No uses una compilación de más de un año.
  • La certificación del dispositivo se basa en uno de los certificados raíz aprobados por el proveedor. Especifica tus certificados raíz de confianza en la superposición de recursos vendor_required_attestation_certificates.xml.

Ejecuta pruebas del lado del host

Algunas pruebas multidispositivo, como las pruebas de NFC, requieren configuración adicional. En el caso de las pruebas que requieren configuración adicional, cada prueba se ejecuta por separado. En el caso de las pruebas que no requieren configuración adicional, puedes ejecutarlas en un grupo.

  1. En tu estación de trabajo de prueba, inicia la consola de cts-v-host desde el directorio en el que se descomprimió el paquete zip de CTS-V:

    ./android-cts-verifier/android-cts-v-host/tools/cts-v-host-tradefed

  2. En la app de CTS-V del DUT, haz clic en Host-side Tests. En la figura 4, se muestran las pruebas del lado del host en la app de CTS-V:

    Pruebas del host en la app de CTS-V

    Figura 4: Pruebas del host en la app de CTS-V.

    Se muestra una lista de los módulos de prueba multidispositivo del host de prueba.

  3. En la consola del host de CTS-V, usa el siguiente comando para ejecutar pruebas en varios dispositivos que usen una configuración estándar de dos dispositivos:

    run cts-v-host-multidevice-default

    Los resultados aparecen debajo de cada módulo de prueba en la app del CTS-V en el DUT. Las pruebas marcadas en verde se aprobaron, mientras que las marcadas en rojo fallaron.

    En la figura 5, se muestran ejemplos de los resultados de las pruebas de CtsCompanionDeviceManager:

    Resultados de pruebas multidispositivo del host en la app de CTS-V

    Figura 5: Resultados de pruebas multidispositivo del host en la app de CTS-V.

  4. En la consola del host de CTS-V, usa el siguiente comando para ejecutar las pruebas interactivas:

    run cts-v-host-interactive

    Los resultados aparecen debajo de cada módulo de prueba en la app del CTS-V en el DUT. Las pruebas marcadas en verde se aprobaron, mientras que las marcadas en rojo fallaron.

  5. Para cada prueba que requirió una configuración adicional, ejecuta la prueba por separado con el siguiente comando:

    run cts-v-host -m test_module_name

    Por ejemplo, para ejecutar las pruebas de NFC, usa este comando:

    run cts-v-host -m CtsNfcHceMultiDeviceTestCases

    Los resultados aparecen debajo de cada módulo de prueba en la app del CTS-V en el DUT. Las pruebas marcadas en verde se aprobaron, mientras que las marcadas en rojo fallaron.

Ejecuta pruebas de conexión de AP de Wi-Fi

Puedes ejecutar las pruebas de conexión de AP de Wi-Fi de las siguientes dos maneras:

  • Opción 1: Usa una red Wi-Fi existente que configuraste para CTS-V.
  • Opción 2: Configura un AP programable.

Opción 1: Usa una red Wi-Fi existente que configuraste para CTS-V

Para ejecutar las pruebas de conexión de AP de Wi-Fi en una red Wi-Fi existente, haz lo siguiente:

  1. Edita el archivo de configuración del banco de pruebas (WifiConnectionTestbed.yaml). Este archivo se encuentra en el directorio en el que se descomprimió CTS-Verifier. Por ejemplo:

    ./android-cts-verifier/android-cts-v-host/testcases/CtsWifiConnectionTests/x86_64/connection/WifiConnectionTestbed.yaml

  2. Cambia los valores de los campos wifi_ssid y wifi_password por el SSID y la contraseña de la red Wi-Fi. En el siguiente ejemplo, se muestra la ubicación de estos parámetros de configuración:

    TestBeds:
- Name: WifiConnectionTestbed
Controllers:
  AndroidDevice: '*'
TestParams:
  use_programmable_ap: False
  wifi_ssid: WIFI-SSID
  wifi_password: WIFI-PASSWORD

  3. En la consola del host de CTS-V, ejecuta el siguiente comando:

    run cts-v-host -m CtsWifiConnectionTests

Opción 2: Ejecuta la prueba con un AP programable

Para ejecutar las pruebas de conexión de AP Wi-Fi en un AP programable, haz lo siguiente:

  1. Edita el archivo de configuración del banco de pruebas (WifiConnectionTestbed.yaml). Este archivo se encuentra en el directorio en el que se descomprimió CTS-Verifier. Por ejemplo:

    ./android-cts-verifier/android-cts-v-host/testcases/CtsWifiConnectionTests/x86_64/connection/WifiConnectionTestbed.yaml

  2. Cambia el valor de hostname a la dirección IP del AP, según tu configuración local de SSH. Para identificar la dirección IP, consulta Cómo encontrar la dirección IP del AP. En el siguiente ejemplo, se muestra la ubicación del parámetro de configuración hostname:

    TestBeds:
- Name: WifiConnectionTestbed
  Controllers:
    AndroidDevice: '*'
    # Specify settings for the AP.
    OpenWrtDevice:
    - hostname: AP-IP
      skip_init_reboot: True
  TestParams:
    use_programmable_ap: True

  3. En la consola del host de CTS-V, ejecuta el siguiente comando:

    run cts-v-host -m CtsWifiConnectionTests

Ejecuta pruebas del lado del host por USB

Android 17 incluye pruebas del CTS-V basadas en USB que requieren adb a través de Wi-Fi para ejecutarse.

Algunas pruebas de USB requieren el uso del host de CTS-V para acceder a SystemAPIs que tienen permisos a los que la app normal de CTS-V no puede acceder. Estas pruebas no están vinculadas y requieren el uso de adb a través de Wi-Fi.

Se requieren los siguientes accesorios tipo C si el DUT admite informar el tipo BC 1.2 del socio del puerto o los perfiles de alimentación USB en UsbPort.java:

  • Un cargador USB Type-C con carga rápida (PD)
  • Un puerto de bajada estándar (SDP) de carga de batería USB 1.2 (BC 1.2). Estos puertos se limitan a proporcionar 500 mA o 900 mA al DUT y suelen encontrarse en los puertos USB de los concentradores externos.
  • Un puerto de carga de bajada (CDP) USB BC 1.2 Estos puertos pueden proporcionar 1.5 A de corriente al DUT y a los datos. Es probable que un puerto tipo C en una laptop o computadora sea un CDP.
  • Un puerto de carga dedicado (DCP) USB BC 1.2 Estos puertos pueden proporcionar 1.5 A de corriente al DUT sin datos. Es probable que el cargador USB Type-C PD de esta lista sea un DCP.

  1. Conecta el DUT con adb a través de Wi-Fi. Para obtener detalles sobre la configuración, consulta Cómo conectarse a un dispositivo a través de Wi-Fi.

  2. Desconecta físicamente el dispositivo de todas las conexiones USB. La prueba falla si el dispositivo está conectado a cualquier host o accesorio USB cuando se ejecuta el comando de prueba.

  3. Ejecuta el siguiente comando de prueba:

    run cts-v-host -m CtsUsbTypecTestCases

Después de las pruebas, los resultados aparecen en la app del CTS-V en Pruebas del host, como se muestra en las siguientes figuras:

Pruebas de USB del host en la app de CTS-V

Figura 6: Pruebas de USB del host en la app de CTS-V.

Paquete de pruebas CtsUsbTypecTestCases en la app de CTS-V para USB del host

Figura 7: Paquete CtsUsbTypecTestCases en la app de CTS-V para USB del host.

Soluciona problemas de pruebas multidispositivo

En esta sección, encontrarás ayuda para solucionar problemas frecuentes.

No se pudo obtener el número de teléfono durante CtsTelecomTest

Si recibes el mensaje de error Failed to get phone number for <serial>, sigue estos pasos:

  1. Verifica que cada DUT tenga una tarjeta SIM instalada.

  2. Si el error persiste, es posible que las tarjetas SIM no admitan la recuperación automática de números, en cuyo caso debes proporcionar explícitamente los números de teléfono en el comando.

    Por ejemplo, para el DUT 1 (número de serie 17011FDEE0002N, número de teléfono 555-0000) y el DUT 2 (número de serie R3CN90YNAR, número de teléfono 555-1111), agrega los siguientes argumentos al comando run cts-v-host:

    --module-arg CtsTelecomTest:dut_serial:17011FDEE0002N \
--module-arg CtsTelecomTest:dut_phone_number:555-0000 \
--module-arg CtsTelecomTest:ref_phone_number:555-1111

No hay respuesta del servidor durante CtsMultiDeviceGenericRangingAccuracyTests

Si recibes el siguiente mensaje de error, es posible que la app de prueba se bloquee o se cierre debido a la administración de procesos en segundo plano específicos del OEM en ciertos dispositivos:

mobly.snippet.errors.ProtocolError: <AndroidDevice|Initiator> No response from server. Check the device logcat for crashes.

Para resolver este problema, inhabilita las restricciones en segundo plano o incluye en la lista de entidades permitidas los siguientes paquetes:

Paquete Nombre visible
com.google.snippet.uwb CtsUwbSnippetApp
com.google.snippet.ranging CtsRangingSnippetApp
com.google.snippet.bluetooth CtsBluetoothMultiDeviceSnippetApp
com.google.android.mobly.snippet.bundled androidx.multidex.MultDexApplication

Se corrigió el problema de falta de respuesta para GetFirmwareVersion durante las pruebas de NFC.

Si recibes el mensaje verify_firmware_version RuntimeError: No response for GetFirmwareVersion mientras ejecutas las pruebas multidispositivo, significa que las pruebas no pueden acceder a la placa NFC PN532.

Para solucionar este problema, identifica la ruta de acceso serial que usa la placa NFC PN532 en tu host, como dev/ttyUSB1, y, luego, especifícala de forma manual con el argumento --module-arg en la consola:

run cts-v-host -m CtsNfcHceMultiDeviceTestCases --module-arg CtsNfcHceMultiDeviceTestCases:pn532_serial_path:/dev/ttyUSB1

Se corrigió el mensaje de error de falla en la transacción durante las pruebas de NFC

Si recibes el mensaje Transaction failed, check device logs for more information. para todos los casos de prueba de NFC, es probable que el chip NFC del DUT no pueda detectar el PN532.

Si tienes varios dispositivos conectados al host y algunos de ellos no tienen un PN532 colocado en la parte superior, es posible que se haya seleccionado el DUT incorrecto. Para obtener más información, consulta Cómo configurar pruebas de NFC.

Para solucionar este problema, realiza una de las siguientes acciones:

  • Configura el número de serie correcto del DUT en el comando de prueba del host con la marca -s.

  • Desconecta todos los dispositivos que no sean DUT del host.

Se ignora el caso de prueba test_permissions_sync del CDM

Si la prueba se ejecuta en dispositivos que no se pueden depurar, consulta si estás exento. De lo contrario, verifica que ambos dispositivos cumplan con los requisitos.