Suite di test
Affinché un test sia incluso in VTS, deve avere la seguente impostazione
in Android.bp.
test_suites: ["vts"],
Inoltre, l'aggiunta del test alla suite general-tests consente di farne parte di una suite di mappatura dei test utilizzata nei controlli precedenti all'invio.
configurazione di test
Nella maggior parte dei casi, la configurazione del test, ovvero un file XML utilizzato da Trade Federation per eseguire un test VTS, viene generata automaticamente durante la compilazione. Tuttavia, puoi personalizzare la configurazione di test.
Creare un file di configurazione del test personalizzato
La creazione di un nuovo file XML di test da zero può essere complicata, in quanto richiede di comprendere il funzionamento del test harness e la differenza tra ogni programma di test. Il file di configurazione del test generato automaticamente è progettato per semplificare questo processo.
Se devi personalizzare il file XML di test, puoi utilizzare il file generato automaticamente come punto di partenza.
Per individuare il file di configurazione di test generato automaticamente, innanzitutto
esegui il comando make per compilare la configurazione, come mostrato di seguito.
$ m VtsHalUsbV1_1TargetTest
Nella directory di compilazione, puoi cercare il file di configurazione in base al nome del modulo, come mostrato di seguito.
$ find out/ -name VtsHalUsbV1_1TargetTest.config
Possono essere presenti più copie del file e puoi utilizzarne una qualsiasi.
Copia il file .config nella directory
dove si trova il file Android.bp.
Se nel file Android.bp è presente un solo modulo di test, puoi rinominare il file XML in AndroidTest.xml e il sistema di compilazione lo utilizzerà automaticamente come file di configurazione del modulo di test. In caso contrario,
aggiungi un attributo test_config al modulo, come mostrato nell'
esempio seguente.
test_config: "VtsHalUsbV1_1TargetTest.xml",
Ora hai un file di configurazione di test con cui lavorare e implementare la personalizzazione.
Forzare l'esecuzione del test con adb root
La maggior parte dei test VTS richiede i privilegi di root per essere eseguita. Se il file di configurazione di test viene generato automaticamente, puoi aggiungere il seguente attributo a Android.bp.
require_root: true,
Se il file di configurazione di test è personalizzato, aggiungi di seguito al file XML di test.
<target_preparer class="com.android.tradefed.targetprep.RootTargetPreparer"/>
Interrompere il framework durante il test
Molti test VTS non richiedono l'esecuzione del framework Android e l'esecuzione
del test con framework interrotto consente un'esecuzione stabile
senza essere influenzata da irregolarità dei dispositivi. Se il file di configurazione del test viene generato automaticamente, puoi aggiungere il seguente attributo a Android.bp.
disable_framework: true,
Se il file di configurazione del test è personalizzato, aggiungi quanto segue al file XML di test.
<target_preparer class="com.android.tradefed.targetprep.StopServicesSetup"/>
Aggiungi altri argomenti di test
L'esecuzione di alcuni test gtest potrebbe richiedere più tempo. In questi casi, puoi aggiungere opzioni di test runner nel file XML.
Ad esempio, l'impostazione native-test-timeout nella seguente entry consente di eseguire il test con un timeout di 3 minuti anziché il valore predefinito di 1 minuto.
<test class="com.android.tradefed.testtype.GTest" >
<option name="native-test-device-path" value="/data/local/tmp" />
<option name="module-name" value="VtsHalNfcV1_0TargetTest" />
<option name="native-test-timeout" value="180000"/>
</test>
Richiedi il livello API minimo
Alcuni test VTS possono essere eseguiti solo su dispositivi con un livello API minimo. Se il
file di configurazione del test viene generato automaticamente, puoi aggiungere il seguente
attributo a Android.bp.
min_shipping_api_level: 29,
oppure
vsr_min_shipping_api_level: 202404,
Se il file di configurazione del test è personalizzato, aggiungi il seguente comando al file XML del test.
<object type="module_controller" class="com.android.tradefed.testtype.suite.module.ShippingApiLevelModuleController">
<option name="min-api-level" value="29" />
</object>
oppure
<object type="module_controller" class="com.android.tradefed.testtype.suite.module.ShippingApiLevelModuleController">
<option name="vsr-min-api-level" value="202404" />
</object>
Proprietà dei livelli API
Android 12 definisce le proprietà ro.board.first_api_level e
ro.board.api_level per mostrare il livello API delle immagini del fornitore su
questi dispositivi. Combinando queste proprietà con ro.product.first_api_level,
le suite di test scelgono scenari di test adeguati per i dispositivi.
Android 13 definisce ro.vendor.api_level, che viene impostato automaticamente calcolando il livello API del fornitore richiesto utilizzando le proprietà ro.product.first_api_level, ro.board.first_api_level e ro.board.api_level.
Per maggiori dettagli, consulta la sezione Livello API del fornitore.
ro.board.first_api_level
La proprietà ro.board.first_api_level è il livello API quando le immagini del fornitore per un SoC idoneo per il blocco del fornitore vengono rilasciate per la prima volta con questa proprietà. Ciò non dipende dal livello API di avvio del dispositivo, ma dipende solo dal primo livello API del SoC che definisce questo valore. Il valore è permanente per tutta la durata del SoC.
Per impostare ro.board.first_api_level, i produttori di dispositivi possono definire BOARD_SHIPPING_API_LEVEL nel file device.mk, come mostrato nell'esempio seguente:
# BOARD_SHIPPING_API_LEVEL sets ro.product.first_api_level to indicate
# the first api level that the device has been commercially launched on.
BOARD_SHIPPING_API_LEVEL := 23
Definirà automaticamente la proprietà ro.board.first_api_level su
vendor/build.prop sul dispositivo. La proprietà viene impostata dalla procedura init
del fornitore.
ro.board.api_level
La proprietà ro.board.api_level è il livello corrente dell'API del fornitore delle immagini del fornitore che ha il formato YYYYMM in cui l'API del fornitore è stata bloccata. Viene impostato automaticamente dal sistema di compilazione.
ro.vendor.api_level
La proprietà ro.vendor.api_level è stata introdotta in
Android 13 per mostrare il livello API che le immagini del fornitore
devono supportare. Viene impostato automaticamente su ro.product.first_api_level o ro.board.api_level se è presente ro.board.first_api_level e ro.board.api_level su un livello API precedente rispetto a ro.product.first_api_level. La versione verrà sostituita con il livello API del fornitore corrispondente se è impostata sulla versione da ro.product.first_api_level maggiore o uguale a 35. I test per l'implementazione del fornitore che richiedono l'upgrade dell'immagine del fornitore potrebbero essere esclusi dai requisiti del fornitore per il SoC facendo riferimento a questa proprietà.
Procedura di sharding con VTS
Per Android versione 10 o successive, puoi eseguire la procedura di suddivisione su più dispositivi durante i test con i piani VTS e CTS su GSI seguendo le istruzioni riportate di seguito.
run vts --shard-count <number of devices> -s <device serial> ...
Questo comando suddivide il piano VTS in shard e li esegue su più dispositivi.
run cts-on-gsi --shard-count <number of devices> -s <device serial> -s ...
Questo comando suddivide il piano CTS su GSI in shard e li esegue su più dispositivi.