Suite di test
Affinché un test faccia parte di VTS, deve avere la seguente impostazione
nel seguente paese: Android.bp.
test_suites: ["vts"],
Inoltre, l'aggiunta del test alla suite general-tests consente di
parte di una suite di test Mapping utilizzata nei controlli prima dell'invio.
configurazione di test
Nella maggior parte dei casi, verifica la configurazione, ovvero un file XML utilizzato da Trade La federazione per eseguire un test VTS viene automaticamente generati durante la creazione. Tuttavia, puoi personalizzare la configurazione di test.
Creare un file di configurazione di 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 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 build-out, puoi cercare il file config in base al nome del modulo, come mostrato di seguito.
$ find out/ -name VtsHalUsbV1_1TargetTest.config
Possono esistere più copie del file e puoi utilizzare una qualsiasi di queste.
Copia il file .config nella directory
dove si trova il file Android.bp.
Se il file Android.bp contiene un solo modulo di test, puoi:
rinomina il file XML in AndroidTest.xml e il sistema di compilazione
lo utilizza come file di configurazione del modulo di test. Altrimenti,
aggiungi un attributo test_config al modulo, come mostrato in
di esempio qui sotto.
test_config: "VtsHalUsbV1_1TargetTest.xml",
Ora hai a disposizione un file di configurazione di test da utilizzare e implementare. la personalizzazione.
Forzare l'esecuzione del test con adb root
La maggior parte dei test VTS richiede il privilegio principale per essere eseguita. Se la configurazione di test
file viene generato automaticamente, puoi aggiungere il seguente attributo a Android.bp.
require_root: true,
Se il file di configurazione del test è personalizzato, aggiungi quanto segue 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 il framework interrotto consente di eseguire il test in modo stabile senza essere influenzato dai problemi del dispositivo. 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"/>
Aggiungere altri argomenti di test
L'esecuzione di alcuni test gtest potrebbe richiedere più tempo. In questi casi, puoi aggiungere le opzioni dell'esecutore di test 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 livello API minimo
Alcuni test VTS possono essere eseguiti solo su dispositivi con un livello API minimo. Se
di test del file di configurazione di test viene generato automaticamente, puoi aggiungere
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à del livello 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 gli scenari di test appropriati per i dispositivi.
Android 13 definisce il ro.vendor.api_level, ovvero
vengono impostati automaticamente calcolando il livello API del fornitore richiesto utilizzando
ro.product.first_api_level, ro.board.first_api_level e
ro.board.api_level proprietà.
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à. Questo non dipende dal livello API di lancio del dispositivo, ma solo dal primo livello API del SoC che definisce questo valore. La
è 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 suo file device.mk, come mostrato di seguito
esempio:
# 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
La proprietà ro.board.first_api_level verrà definita automaticamente 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 con formato YYYYMM in cui l'API del fornitore è stata bloccata. È
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
ro.product.first_api_level o ro.board.api_level se
ro.board.first_api_level è presente e ro.board.api_level è impostato su un
livello API precedente rispetto a ro.product.first_api_level. La versione sarà
sostituirlo con il livello API del fornitore corrispondente se impostato sulla versione
da ro.product.first_api_level che è maggiore o uguale a 35. Test
per le implementazioni del fornitore che richiedono l'upgrade delle immagini
potrebbero essere escluse
dai requisiti del fornitore per il SoC facendo riferimento a questa proprietà.
Processo di suddivisione in parti utilizzando 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-on-GSI seguendo le istruzioni riportate di seguito.
run vts --shard-count <number of devices> -s <device serial> ...
Questo comando suddivide il piano VTS in frammenti 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.