A partire dal 27 marzo 2025, ti consigliamo di utilizzare android-latest-release anziché aosp-main per compilare e contribuire ad AOSP. Per ulteriori informazioni, vedi Modifiche ad AOSP.

Questa pagina è stata tradotta dall'API Cloud Translation.

Console di comando CTS v2

Utilizzare la console CTS v2

Per Android 7.0 o versioni successive, utilizza CTS v2.

Seleziona i piani

I piani di test disponibili includono:

cts: esegue CTS da un'installazione CTS esistente.
cts-camera: esegue CTS-camera da un'installazione CTS esistente.
cts-java: esegue i test Java di base da un'installazione CTS esistente.
cts-pdk: esegue test utili per convalidare una compilazione di fusione PDK.
everything: configurazione comune per le suite di compatibilità.

Le altre configurazioni disponibili includono:

basic-reporters: configurazione con report CTS di base.
collect-tests-only: esegue CTS da un'installazione CTS esistente.
common-compatibility-config: configurazione comune per le suite di compatibilità.
cts-filtered-sample: configurazione comune per le suite di compatibilità.
cts-known-failures: configurazione con errori CTS noti.
cts-preconditions: configurazioni dei prerequisiti CTS.
host: esegue un singolo test basato sull'host su un dispositivo esistente.
instrument: esegue un singolo test di strumentazione Android su un dispositivo esistente.
native-benchmark: esegue un test di stress nativo su un dispositivo esistente.
native-stress: esegue un test di stress nativo su un dispositivo esistente.
ricarica: un test falso che attende i dispositivi quasi scarichi e li blocca per la ricarica.
testdef: esegue i test contenuti nei file test_def.xml su un dispositivo esistente.
util/wifi: configurazione di utilità per configurare il Wi-Fi sul dispositivo.
util/wipe: cancella i dati utente sul dispositivo.

Tutti questi piani e configurazioni possono essere eseguiti con il comando run cts.

Riferimento ai comandi della console CTS v2

Questa tabella riassume i comandi della console CTS v2 per vari utilizzi.

Host	Descrizione
`help`	Visualizza un riepilogo dei comandi più utilizzati
`help all`	Visualizzare l'elenco completo dei comandi disponibili
`version`	Mostra la versione.
`exit`	Esci correttamente dalla console CTS. La console si chiude al termine di tutti i test attualmente in esecuzione.
`extdir`	Il file ZIP dei download viene decompreso in `extdir`. Se vuoi eliminare l'output gonfiato, utilizza l'opzione `-q`: `unzip -q android-cts-9.0_r15-linux_x86-arm.zip -d extdir` Se vuoi decomprimere nella directory corrente, non utilizzare l'opzione `-d`, ma esegui semplicemente: `unzip -q android-cts-9.0_r15-linux_x86-arm.zip`
Esegui	Descrizione
`run cts`	In Android 10, esegui contemporaneamente il piano CTS predefinito e CTS-Instant (ovvero l'invocazione completa del CTS). Per Android 9 o versioni precedenti, esegui solo il piano CTS predefinito. Utilizza questa opzione completa (inclusi i prerequisiti) per la convalida del dispositivo. Per le inclusioni, consulta cts.xml. La console CTS può accettare altri comandi mentre i test sono in corso. Se non sono collegati dispositivi, il computer (o l'host) CTS attenderà che un dispositivo venga collegato prima di avviare i test. Se sono collegati più di un dispositivo, l'host CTS ne sceglierà uno automaticamente.
`run cts-instant`	Per Android 9, esegui il piano CTS-Instant predefinito.
`run cts --module-parameter INSTANT_APP`	In Android 10, esegui il piano CTS-Instant predefinito.
`run cts --module-parameter INSTANT_APP --module/-m test_module_name`	In Android 10, esegui il modulo o i moduli di test CTS-Instant specificati.
`run retry`	Solo per Android 9 o versioni successive. Riprova tutti i test non riusciti o non eseguiti dalle sessioni precedenti. Ad esempio, `run retry --retry -s` o `run retry --retry --shard-count` con lo sharding di TF. Per Android 12 o versioni successive, questo comando supporta i filtri utilizzando le opzioni `--module/-m` e `--exclude-filter`. I test non inclusi nella sessione di ripetizione vengono memorizzati nella cache dalla sessione precedente. `run cts --retry` non è consentito per Android 9 o versioni successive.
`run cts-sim`	Per Android 11 o versioni successive. Esegue il sottoinsieme di test su un dispositivo con scheda SIM.
`--device-token`	Per Android 8.1 o versioni precedenti. Specifica che un determinato dispositivo ha il token specificato. Ad esempio, `--device-token 1a2b3c4d:sim-card`.
`--enable-token-sharding`	Solo per Android 10 o versioni successive. Abbina automaticamente il test che richiede il rispettivo tipo di SIM. Non è necessario fornire un numero di serie del dispositivo per eseguire i casi di test relativi alla SIM. SIM supportate: `SIM_CARD`, `UICC_SIM_CARD` e `SECURE_ELEMENT_SIM_CARD`.
`run cts-dev`	Esegui il piano CTS predefinito (ovvero l'invocazione completa del CTS), ma salta i prerequisiti per risparmiare tempo di esecuzione per lo sviluppo iterativo di un nuovo test. In questo modo, viene ignorata la verifica e la configurazione della configurazione del dispositivo, ad esempio il trasferimento di file multimediali o la verifica della connessione Wi-Fi, come avviene quando viene utilizzata l'opzione `--skip-preconditions`. Questo comando salta anche la raccolta delle informazioni del dispositivo e tutti i controlli dello stato del sistema. Inoltre, esegue i test su un'unica ABI. Per la convalida del dispositivo, evita questa ottimizzazione e includi tutti i prerequisiti e i controlli. Per le esclusioni, consulta cts-dev.xml. La console CTS può accettare altri comandi mentre i test sono in corso. Se non sono collegati dispositivi, il computer (o l'host) CTS attenderà che un dispositivo venga collegato prima di avviare i test. Se sono collegati più di un dispositivo, l'host CTS ne sceglierà uno automaticamente.
`--subplan subplan_name`	Esegui il sottopiano specificato.
`--module/-m test_module_name --test/-t test_name`	Esegui il modulo e il test specificati. Ad esempio, `run cts -m Gesture --test android.gesture.cts.GestureTest#testGetStrokes` esegue il pacchetto, il corso o il test specifico. Attenzione: non utilizzare questa opzione se utilizzi l'opzione `--include-filter`.
`--retry`	Riprova tutti i test non riusciti o non eseguiti nelle sessioni precedenti. Utilizza `list results` per ottenere l'ID sessione.
`--retry-type NOT_EXECUTED`	Riprova solo i test che non sono stati eseguiti nelle sessioni precedenti. Utilizza `list results` per ottenere l'ID sessione.
`--shards number_of_shards`	Per Android 8.1 o versioni precedenti. Suddividi un CTS in un determinato numero di chunk indipendenti, da eseguire su più dispositivi in parallelo.
`--shard-count number_of_shards`	Per Android 9. Suddividi un'esecuzione CTS in un determinato numero di chunk indipendenti, da eseguire in parallelo su più dispositivi.
`--serial/-s deviceID`	Esegui CTS sul dispositivo specifico.
`--include-filter "test_module_name test_name"`	Esegui con i moduli specificati o testa pacchetti, classi e casi. Ad esempio, `run cts --include-filter "CtsCalendarcommon2TestCases android.calendarcommon2.cts.Calendarcommon2Test#testStaticLinking"` include il modulo specificato. Questa opzione di comando non è supportata quando viene eseguito il riavvio. Attenzione: non utilizzare questa opzione se utilizzi l'opzione `--module/-m`.
`--exclude-filter "test_module_name test_name"`	Escludi dalla corsa i moduli specificati o i pacchetti, le classi e gli scenari di test. Ad esempio, `run cts --exclude-filter "CtsCalendarcommon2Test android.calendarcommon2.cts.Calendarcommon2Test#testStaticLinking"` esclude il modulo specificato.
`--log-level-display/-l log_level`	Esegui con il livello di log minimo specificato visualizzato su `STDOUT`. Valori validi: [`VERBOSE`, `DEBUG`, `INFO`, `WARN`, `ERROR`, `ASSERT`].
`--abi abi_name`	Forza l'esecuzione del test sull'ABI specificato, 32 o 64. Per impostazione predefinita, CTS esegue un test una volta per ogni ABI supportato dal dispositivo.
`--logcat-on-failure`, `--bugreport-on-failure`, `--screenshoot-on-failure`	Offre una maggiore visibilità sugli errori e può essere utile per la diagnostica.
`--device-token`	Specifica che un determinato dispositivo ha il token specificato, ad esempio `--device-token 1a2b3c4d:sim-card`.
`--skip-device-info`	Salta la raccolta delle informazioni sul dispositivo. Attenzione: non utilizzare questa opzione quando esegui il CTS per l'approvazione.
`--skip-preconditions`	Salta i prerequisiti per risparmiare tempo di esecuzione per lo sviluppo iterativo di un nuovo test. In questo modo vengono ignorate la verifica e la configurazione del dispositivo, ad esempio il trasferimento di file multimediali o la verifica della connessione Wi-Fi.
Elenco	Descrizione
`list modules`	Elenca tutti i moduli di test disponibili nel repository.
`list plans` o `list configs`	Elenca tutti i piani di test (configurazioni) disponibili nel repository.
`list subplans`	Elenca tutti i sottopiani disponibili nel repository.
`list invocations`	Elenca i comandi run attualmente in esecuzione sui dispositivi.
`list commands`	Elenca tutti i comandi run attualmente in coda in attesa di essere assegnati ai dispositivi.
`list results`	Elenca i risultati CTS attualmente archiviati nel repository.
`list devices`	Elenca i dispositivi attualmente connessi e il relativo stato. I dispositivi disponibili sono dispositivi inutilizzati e funzionanti, disponibili per l'esecuzione di test. I dispositivi non disponibili sono dispositivi visibili tramite adb, ma non rispondono ai comandi adb e non verranno allocati per i test. I dispositivi allocati sono quelli su cui sono attualmente in esecuzione i test.
Dump	Descrizione
`dump logs`	Esegui il dump dei log di TradeFed per tutte le invocazioni in esecuzione.
Aggiungi	Descrizione
`add subplan --name/-n subplan_name --result-type [passed \| failed \| not_executed] [--session session_id]`	Crea un sottopiano derivato dalla sessione precedente. Questa opzione genera un sottopiano che può essere utilizzato per eseguire un sottoinsieme di test. L'unica opzione obbligatoria è `--session`. Altri sono facoltativi, ma se inclusi devono essere seguiti da un valore. L'opzione `--result-type` è ripetibile; ad esempio, `add subplan --session 0 --result-type passed --result-type failed` è valido.