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):
- Verifica che il computer desktop soddisfi i requisiti di sistema per CTS.
- 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 dipython.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 modulovenv, eseguipython3 -m venv venv. Se questo comando non va a buon fine, viene visualizzato un messaggio di errore. Segui le istruzioni per installare il pacchettopython3.x-venv.
- La versione di Python deve essere 3.11 o successive. Per determinare la versione di Python, esegui
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:
- Verifica che il computer desktop soddisfi i requisiti di sistema per CTS.
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 dipython.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 modulovenv, eseguipython3 -m venv venv. Se questo comando non va a buon fine, viene visualizzato un messaggio di errore. Segui le istruzioni per installare il pacchettopython3.x-venv.
- La versione di Python deve essere 3.11 o successive. Per determinare la versione di Python, esegui
Prepara due DUT corrispondenti, ciascuno con CTS-V configurato.
- Per informazioni sulla configurazione di un DUT, vedi Configurare il DUT.
- Per istruzioni sulla configurazione di CTS-V, consulta Configurazione.
Vai alla sezione di configurazione per il tipo di test:
- Per i test NFC, vai a Configurare i test NFC.
- Per i test di connessione AP Wi-Fi, vai a Configurare i test di connessione AP Wi-Fi.
- Per i test di precisione della misurazione della distanza, vai a Configurare i test di precisione della misurazione della distanza.
- Per testare il modulo CDM, vai a Configurare test standard su due dispositivi e poi a Configurare test CDM.
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:
- Acquista un chip NFC PN532. Ti consigliamo All-In-One PN532.
- Sul DUT, vai all'app Impostazioni.
- Attiva NFC.
Posiziona il chip NFC:
Per gli smartphone, posiziona il lettore NFC del DUT come mostrato nella Figura 1:

Figura 1. Posizionamento del chip NFC.
Per altri tipi di dispositivi, posiziona il chip accanto all'antenna NFC del dispositivo.
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:
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.
(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 18676993556Collega 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:

Figura 2. DUT e AP nella scatola schermata.
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:
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:

Figura 3. Orientamento del dispositivo.
Collega entrambi i dispositivi al computer tramite cavi USB.
Configurare test standard su due dispositivi
Per la configurazione predefinita con due dispositivi:
- Posiziona due DUT Android corrispondenti a circa 20 cm di distanza.
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.
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.
(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.
Sulla workstation di test, avvia la console
cts-v-hostdalla directory in cui è stato decompresso il pacchetto zip CTS-V:./android-cts-verifier/android-cts-v-host/tools/cts-v-host-tradefedAll'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:
Figura 4. Test lato host nell'app CTS-V.
Viene visualizzato un elenco di moduli di test multidevice lato host.
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-defaultI 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:
Figura 5. Il test multidevice lato host genera l'app CTS-V.
Nella console host CTS-V, utilizza il seguente comando per eseguire i test interattivi:
run cts-v-host-interactiveI 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.
Per ogni test che richiedeva una configurazione aggiuntiva, esegui il test separatamente utilizzando il seguente comando:
run cts-v-host -m test_module_nameAd esempio, per eseguire i test NFC, utilizza questo comando:
run cts-v-host -m CtsNfcHceMultiDeviceTestCasesI 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:
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.yamlModifica il valore dei campi
wifi_ssidewifi_passwordcon 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-PASSWORDNella 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:
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.yamlModifica il valore di
hostnamecon 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'impostazionehostname:TestBeds: - Name: WifiConnectionTestbed Controllers: AndroidDevice: '*' # Specify settings for the AP. OpenWrtDevice: - hostname: AP-IP skip_init_reboot: True TestParams: use_programmable_ap: TrueNella 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.
Collega il DUT utilizzando
adbtramite Wi-Fi. Per i dettagli della configurazione, vedi Connettersi a un dispositivo tramite Wi-Fi.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.
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:
Figura 6. Test USB lato host nell'app CTS-V.
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:
Verifica che su ogni DUT sia installata una scheda SIM.
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 telefono555-0000) e il DUT 2 (serialeR3CN90YNAR, numero di telefono555-1111), aggiungi i seguenti argomenti al comandorun 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.