Esegui i test lato host di CTS Verifier

Questa pagina contiene le istruzioni per configurare ed eseguire i test CTS Verifier (CTS-V) lato host Android 16 QPR2 e Android 17. Esistono due tipi di test lato host: test multi-dispositivo (introdotti prima di Android 17) e test interattivi (novità di Android 17):

  • I test su più dispositivi sono test completamente automatizzati.
  • I test interattivi sono test semiautomatici che richiedono l'esecuzione di alcuni passaggi manuali sul dispositivo in fase di test.

Oltre ai nuovi test interattivi, abbiamo convertito i test manuali di precisione della misurazione e di telecomunicazioni in test multidevice lato host e ora sono richiesti i test di connessione Wi-Fi.

Configura i test lato host

Segui questi passaggi per configurare i test lato host (i test su più dispositivi richiedono una configurazione aggiuntiva):

  1. Verifica che il computer desktop soddisfi i requisiti di sistema per CTS.
  2. Segui i passaggi 2 e 5 della sezione Installa software desktop per installare e verificare che adb, AAPT2 e Python siano installati correttamente sul tuo computer.
    • La versione di Python deve essere 3.11 o successive. Per determinare la versione di Python, esegui python3 --version. Se la versione è precedente alla 3.11, installa l'ultima release ufficiale di Python. Per ulteriori informazioni, consulta la sezione Download di python.org.
    • Alcuni test richiedono che l'host disponga del modulo Python venv. Sui sistemi Debian e Ubuntu, questo modulo potrebbe non essere installato per impostazione predefinita. Per determinare se la tua versione di Python ha il modulo venv, esegui python3 -m venv venv. Se questo comando non va a buon fine, viene visualizzato un messaggio di errore. Segui le istruzioni per installare il pacchetto python3.x-venv.

Se esegui solo i test interattivi lato host, vai a Esegui i test lato host. Tuttavia, se vuoi eseguire test su più dispositivi, vai a Configurare test su più dispositivi lato host.

Configurare i test multidevice lato host

Segui questi passaggi per configurare i test multidevice lato host:

  1. Verifica che il computer desktop soddisfi i requisiti di sistema per CTS.
  2. Segui i passaggi 2 e 5 della sezione Installa software desktop per installare e verificare che adb, AAPT2 e Python siano installati correttamente sul tuo computer.

    • La versione di Python deve essere 3.11 o successive. Per determinare la versione di Python, esegui python3 --version. Se la versione è precedente alla 3.11, installa l'ultima release ufficiale di Python. Per ulteriori informazioni, consulta la sezione Download di python.org.
    • Alcuni test richiedono che l'host disponga del modulo Python venv. Sui sistemi Debian e Ubuntu, questo modulo potrebbe non essere installato per impostazione predefinita. Per determinare se la tua versione di Python ha il modulo venv, esegui python3 -m venv venv. Se questo comando non va a buon fine, viene visualizzato un messaggio di errore. Segui le istruzioni per installare il pacchetto python3.x-venv.
  3. Prepara due DUT corrispondenti, ciascuno con CTS-V configurato.

  4. Vai alla sezione di configurazione per il tipo di test:

Se il test non è presente in questo elenco, vai a Configurare test standard su due dispositivi.

Configurare i test NFC

I test NFC utilizzano un DUT e un chip NFC PN532.

Per configurare i test NFC:

  1. Acquista un chip NFC PN532. Ti consigliamo All-In-One PN532.
  2. Sul DUT, vai all'app Impostazioni.
  3. Attiva NFC.
  4. Posiziona il chip NFC:

    • Per gli smartphone, posiziona il lettore NFC del DUT come mostrato nella Figura 1:

      Posizionamento del chip NFC

      Figura 1. Posizionamento del chip NFC.

    • Per altri tipi di dispositivi, posiziona il chip accanto all'antenna NFC del dispositivo.

  5. Collega il chip NFC PN532 alla workstation di test utilizzando un cavo USB.

Configurare i test di connessione AP Wi-Fi

I test di connessione del punto d'accesso Wi-Fi (AP) (CtsWifiConnectionTests) testano la connettività tra un DUT e un AP. Puoi configurare questi test nei seguenti due modi:

  • Opzione 1: utilizza una rete Wi-Fi esistente che hai configurato per CTS-V.
  • Opzione 2: configura un punto di accesso (AP) programmabile.

Per Android 17, consigliamo vivamente l'opzione 2, ma non è obbligatoria. Le due sezioni seguenti spiegano ciascuna opzione.

Opzione 1: utilizza una rete Wi-Fi esistente che hai configurato per CTS-V

L'opzione 1 richiede un DUT Android all'interno dell'area di copertura della rete Wi-Fi. Se il DUT si trova in una scatola schermata e non riesce a connettersi alla rete Wi-Fi, rimuovilo dalla scatola schermata.

Opzione 2: configura un AP programmabile

Per configurare un AP programmabile per i test di connessione Wi-Fi:

  1. Acquista e configura il Banana Pi R3 AP. Per informazioni sull'acquisto e sulla configurazione dell'access point Banana Pi R3, vedi Configura l'access point Banana Pi BPI-R3.

  2. (Facoltativo) Se non hai una scatola schermata, ti consigliamo la scatola schermata JTP-SR101. Acquista questa scatola utilizzando le seguenti informazioni:

    Dong Guan Zheng Sheng Electronics Technology Co., LTD
    Bohui Industrial Park, Panlong Road, Liaobu Town, Dongguan City, Guangdong Province, China
    Contatto: Forest Pan
    Email: forest.pan@jtpmak.cn
    Telefono (Cina): +86 18676993556

  3. Collega il DUT e l'AP all'host e inseriscili in una scatola schermata RF. Il DUT e l'AP devono essere distanti almeno 10 cm. La Figura 2 mostra questa configurazione:

    DUT e AP nella scatola schermata

    Figura 2. DUT e AP nella scatola schermata.

  4. Utilizza SSH per verificare che l'AP sia accessibile dall'host.

Configurare i test di precisione della misurazione

Per configurare i test di precisione della distanza:

  1. Posiziona due DUT Android corrispondenti a 1 metro di distanza, alla stessa altezza, con linea di visuale diretta e con il retro di ciascun dispositivo rivolto l'uno verso l'altro. La Figura 3 mostra questo orientamento:

    Orientamento del dispositivo

    Figura 3. Orientamento del dispositivo.

  2. Collega entrambi i dispositivi al computer tramite cavi USB.

Configurare test standard su due dispositivi

Per la configurazione predefinita con due dispositivi:

  1. Posiziona due DUT Android corrispondenti a circa 20 cm di distanza.
  2. Vivamente consigliato: inserisci entrambi i dispositivi in una scatola schermata. La scatola di protezione migliora la stabilità dei test e semplifica il debug degli errori.

  3. Per i test di telecomunicazioni, ogni DUT deve avere una scheda SIM e un segnale cellulare. Se i DUT si trovano in una scatola schermata, il segnale cellulare deve essere accoppiato alla scatola. In caso contrario, sposta i dispositivi fuori dalla scatola schermata.

  4. (Facoltativo) Configura uno sniffer OTA per il debug del Wi-Fi.

Configura i test CDM

Lo scenario di test test_permissions_sync() ha un comportamento diverso a seconda del tipo di compilazione dei dispositivi su cui viene eseguito il test. È fondamentale che entrambe le build di cui è possibile eseguire il debug (userdebug o eng) e non di cui è possibile eseguire il debug (user) vengano testate dagli OEM e che i test vengano superati per entrambe.

Esenzione

La clausola CDD per l'implementazione dell'API di sincronizzazione delle autorizzazioni richiede solo che sia in grado di trasferire correttamente i dati tra i dispositivi su un canale sicuro. Poiché l'implementazione del canale sicuro non è un requisito di conformità CDD, questo test può essere ignorato nelle build non eseguibili in modalità di debug (utente), ma solo se vuoi disattivare il supporto della funzionalità di sincronizzazione delle autorizzazioni CDM.

I test devono essere superati nelle build sottoponibili a debug senza eccezioni.

Prerequisiti per i test sulle build non eseguibili in modalità di debug

Se non sei esente, verifica di soddisfare i seguenti prerequisiti.

Il canale sicuro utilizza AVF (AttestationVerificationFramework) per verificare l'affidabilità dell'hardware. Le attestazioni generate da entrambe le parti contengono diverse informazioni su se stesse per verificare che non siano state apportate alterazioni non autorizzate nel loro sistema. Durante la procedura di verifica, AVF controlla i seguenti stati:

  • Il dispositivo ha accesso a internet
  • Il dispositivo utilizza l'avvio verificato e la build deve essere firmata con una chiave di rilascio, non con una chiave di sviluppo
  • Il bootloader del dispositivo è bloccato. Per istruzioni dettagliate, consulta Blocco del bootloader.
  • I livelli di patch di sistema operativo, avvio della chiave e fornitore della chiave sono entro 12 mesi. Non utilizzare una build precedente a un anno
  • L'attestazione del dispositivo è supportata da uno dei certificati root approvati dal fornitore. Specifica i certificati radice attendibili nell'overlay delle risorse vendor_required_attestation_certificates.xml.

Esegui i test lato host

Alcuni test su più dispositivi, come i test NFC, richiedono una configurazione aggiuntiva. Per i test che richiedono una configurazione aggiuntiva, ogni test viene eseguito separatamente. Per i test che non richiedono una configurazione aggiuntiva, puoi eseguirli in un gruppo.

  1. Sulla workstation di test, avvia la console cts-v-host dalla directory in cui è stato decompresso il pacchetto zip CTS-V:

    ./android-cts-verifier/android-cts-v-host/tools/cts-v-host-tradefed
    
  2. All'interno dell'app CTS-V sul DUT, fai clic su Test lato host. La Figura 4 mostra i test lato host nell'app CTS-V:

    Test lato host nell'app CTS-V

    Figura 4. Test lato host nell'app CTS-V.

    Viene visualizzato un elenco di moduli di test multidevice lato host.

  3. Nella console host CTS-V, utilizza il comando seguente per eseguire test multidevice che utilizzano una configurazione standard a due dispositivi:

    run cts-v-host-multidevice-default
    

    I risultati vengono visualizzati in ogni modulo di test nell'app CTS-V sul DUT. I test contrassegnati in verde sono stati superati, quelli contrassegnati in rosso non sono riusciti.

    La Figura 5 mostra i risultati di esempio per i test CtsCompanionDeviceManager:

    I risultati dei test multidevice lato host vengono visualizzati nell'app CTS-V

    Figura 5. Il test multidevice lato host genera l'app CTS-V.

  4. Nella console host CTS-V, utilizza il seguente comando per eseguire i test interattivi:

    run cts-v-host-interactive
    

    I risultati vengono visualizzati in ogni modulo di test nell'app CTS-V sul DUT. I test contrassegnati in verde sono stati superati, quelli contrassegnati in rosso non sono riusciti.

  5. Per ogni test che richiedeva una configurazione aggiuntiva, esegui il test separatamente utilizzando il seguente comando:

    run cts-v-host -m test_module_name
    

    Ad esempio, per eseguire i test NFC, utilizza questo comando:

    run cts-v-host -m CtsNfcHceMultiDeviceTestCases
    

    I risultati vengono visualizzati in ogni modulo di test nell'app CTS-V sul DUT. I test contrassegnati in verde sono stati superati, quelli contrassegnati in rosso non sono riusciti.

Esegui test di connessione al punto di accesso Wi-Fi

Puoi eseguire i test di connessione al punto di accesso Wi-Fi in due modi:

  • Opzione 1: utilizza una rete Wi-Fi esistente che hai configurato per CTS-V.
  • Opzione 2: configura un AP programmabile.

Opzione 1: utilizza una rete Wi-Fi esistente che hai configurato per CTS-V

Per eseguire i test di connessione al punto di accesso Wi-Fi su una rete Wi-Fi esistente:

  1. Modifica il file di configurazione del testbed (WifiConnectionTestbed.yaml). Questo file si trova nella directory in cui è stato decompresso CTS-Verifier. Ad esempio:

    ./android-cts-verifier/android-cts-v-host/testcases/CtsWifiConnectionTests/x86_64/connection/WifiConnectionTestbed.yaml
    
  2. Modifica il valore dei campi wifi_ssid e wifi_password con l'SSID e la password della rete Wi-Fi. Il seguente esempio mostra la posizione di queste impostazioni:

    TestBeds:
    - Name: WifiConnectionTestbed
    Controllers:
      AndroidDevice: '*'
    TestParams:
      use_programmable_ap: False
      wifi_ssid: WIFI-SSID
      wifi_password: WIFI-PASSWORD
    
  3. Nella console host CTS-V, esegui questo comando:

    run cts-v-host -m CtsWifiConnectionTests
    

Opzione 2: esegui con un AP programmabile

Per eseguire i test di connessione AP Wi-Fi su un AP programmabile:

  1. Modifica il file di configurazione del testbed (WifiConnectionTestbed.yaml). Questo file si trova nella directory in cui è stato decompresso CTS-Verifier. Ad esempio:

    ./android-cts-verifier/android-cts-v-host/testcases/CtsWifiConnectionTests/x86_64/connection/WifiConnectionTestbed.yaml
    
  2. Modifica il valore di hostname con l'indirizzo IP del punto di accesso, in base alle tue impostazioni SSH locali. Per identificare l'indirizzo IP, consulta Trovare l'indirizzo IP del punto di accesso. L'esempio seguente mostra la posizione dell'impostazione 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. Nella console host CTS-V, esegui questo comando:

    run cts-v-host -m CtsWifiConnectionTests
    

Esegui test lato host USB

Android 17 include test lato host CTS-V USB che richiedono l'esecuzione di adb tramite Wi-Fi.

Alcuni test USB richiedono l'utilizzo dell'host CTS-V per accedere alle API di sistema che dispongono di autorizzazioni a cui la normale app CTS-V non può accedere. Questi test sono indipendenti e richiedono l'utilizzo di adb tramite Wi-Fi.

Se il DUT supporta la generazione di report sul tipo BC 1.2 della porta partner o sui profili di alimentazione USB in UsbPort.java, sono necessari i seguenti accessori Type-C:

  • Un caricabatterie USB Type-C Power Delivery (PD)
  • Una porta downstream standard (SDP) di ricarica della batteria USB 1.2 (BC 1.2). Queste porte sono limitate a fornire 500 mA o 900 mA al DUT e si trovano comunemente sulle porte USB degli hub esterni.
  • Una porta di ricarica downstream USB BC 1.2 (CDP). Queste porte possono fornire 1,5 A di corrente al DUT e ai dati. Una porta di tipo C su un laptop o un computer è probabilmente una CDP.
  • Una porta di ricarica dedicata USB BC 1.2 (DCP). Queste porte possono fornire 1,5 A di corrente al DUT senza dati. Il caricabatterie USB Type-C PD in questo elenco è probabilmente un DCP.
  1. Collega il DUT utilizzando adb tramite Wi-Fi. Per i dettagli della configurazione, vedi Connettersi a un dispositivo tramite Wi-Fi.

  2. Scollega fisicamente il dispositivo da tutte le connessioni USB. Il test non riesce se il dispositivo è collegato a un host USB o a un accessorio quando viene eseguito il comando di test.

  3. Esegui questo comando di test:

    run cts-v-host -m CtsUsbTypecTestCases
    

Dopo i test, i risultati vengono visualizzati all'interno dell'app CTS-V in Test lato host, come mostrato nelle figure seguenti:

Test USB lato host nell'app CTS-V

Figura 6. Test USB lato host nell'app CTS-V.

Suite CtsUsbTypecTestCases nell'app USB CTS-V lato host

Figura 7. Suite CtsUsbTypecTestCases nell'app CTS-V USB lato host.

Risolvere i problemi relativi ai test su più dispositivi

Questa sezione ti aiuta a risolvere i problemi più comuni.

Impossibile ottenere il numero di telefono durante CtsTelecomTest

Se ricevi il messaggio di errore Failed to get phone number for <serial>, segui questi passaggi:

  1. Verifica che su ogni DUT sia installata una scheda SIM.

  2. Se l'errore persiste, le schede SIM potrebbero non supportare il recupero automatico dei numeri, nel qual caso devi fornire esplicitamente i numeri di telefono nel comando.

    Ad esempio, per il DUT 1 (seriale 17011FDEE0002N, numero di telefono 555-0000) e il DUT 2 (seriale R3CN90YNAR, numero di telefono 555-1111), aggiungi i seguenti argomenti 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
    

Nessuna risposta dal server durante CtsMultiDeviceGenericRangingAccuracyTests

Se ricevi il seguente messaggio di errore, l'app di test può essere bloccata o chiusa dalla gestione dei processi in background specifica dell'OEM su alcuni dispositivi:

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

Per risolvere il problema, disattiva le limitazioni per l'esecuzione in background o inserisci nella lista consentita i seguenti pacchetti:

Pacchetto Nome visualizzato
com.google.snippet.uwb CtsUwbSnippetApp
com.google.snippet.ranging CtsRangingSnippetApp
com.google.snippet.bluetooth CtsBluetoothMultiDeviceSnippetApp
com.google.android.mobly.snippet.bundled androidx.multidex.MultDexApplication

Correzione di Nessuna risposta per GetFirmwareVersion durante i test NFC

Se durante l'esecuzione dei test su più dispositivi ricevi il messaggio verify_firmware_version RuntimeError: No response for GetFirmwareVersion, i test non possono accedere alla scheda NFC PN532.

Per risolvere il problema, identifica il percorso seriale utilizzato dalla scheda NFC PN532 sull'host, ad esempio dev/ttyUSB1, quindi specificalo manualmente utilizzando l'argomento --module-arg nella console:

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

Correggere il messaggio di errore Transazione non riuscita durante i test NFC

Se ricevi il messaggio Transaction failed, check device logs for more information. per tutti gli scenari di test NFC, è probabile che il chip NFC del DUT non riesca a rilevare il PN532.

Se hai più dispositivi connessi all'host e alcuni non hanno un PN532 posizionato sopra, potrebbe essere stato selezionato il DUT sbagliato. Per ulteriori informazioni, vedi Configurare i test NFC.

Per risolvere il problema, esegui una delle seguenti operazioni:

  • Imposta il numero di serie corretto del DUT nel comando di test lato host utilizzando il flag -s.

  • Scollega tutti i dispositivi non DUT dall'host.

Lo scenario di test CDM test_permissions_sync viene ignorato

Se il test viene eseguito su dispositivi non eseguibili in modalità di debug, verifica se sei esente. In caso contrario, verifica che entrambi i dispositivi soddisfino i prerequisiti.