Suite di prova
Affinché un test faccia parte di VTS, deve avere la seguente impostazione in Android.bp .
test_suites: ["vts"],
Inoltre, l'aggiunta del test alla suite general-tests gli consente di far parte di una suite di Test Mapping utilizzata nei controlli pre-invio.
Provare la configurazione
Nella maggior parte dei casi, la configurazione del test, ovvero un file XML utilizzato dalla Trade Federation per eseguire un test VTS, viene generata automaticamente durante la creazione. Tuttavia, è possibile personalizzare la configurazione del test.
Creare un file di configurazione del test personalizzato
Creare un nuovo file XML di test da zero può essere complicato, poiché implica comprendere come funziona il test cablaggio, nonché la differenza tra ciascun test runner. Il file di configurazione del test generato automaticamente è progettato per semplificare questo processo.
Se è necessario personalizzare il file XML di test, è possibile utilizzare il file generato automaticamente come punto di partenza.
Per individuare il file di configurazione di test generato automaticamente, esegui prima il comando make per creare 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 esserci più copie del file ed è possibile utilizzarne una qualsiasi. Copia il file .config nella directory in cui si trova il file Android.bp .
Se è presente un solo modulo di test nel file Android.bp , puoi rinominare il file XML in AndroidTest.xml e il sistema di compilazione lo utilizzerà automaticamente come file di configurazione del modulo di test. Altrimenti, aggiungi un attributo test_config al modulo, come mostrato nell'esempio seguente.
test_config: "VtsHalUsbV1_1TargetTest.xml",
Ora hai un file di configurazione di prova con cui lavorare e implementare la personalizzazione.
Forza l'esecuzione del test con adb root
La maggior parte dei test VTS richiedono i privilegi di root per essere eseguiti. Se il file di configurazione del test viene generato automaticamente, puoi aggiungere il seguente attributo ad Android.bp .
require_root: true,
Se il file di configurazione del test è personalizzato, aggiungere quanto segue al file XML del test.
<target_preparer class="com.android.tradefed.targetprep.RootTargetPreparer"/>
Arrestare il quadro durante il test
Molti test VTS non richiedono l'esecuzione del framework Android e l'esecuzione del test con il framework arrestato consente l'esecuzione stabile del test senza essere influenzato dai problemi del dispositivo. Se il file di configurazione del test viene generato automaticamente, puoi aggiungere il seguente attributo ad Android.bp .
disable_framework: true,
Se il file di configurazione del test è personalizzato, aggiungere quanto segue al file XML del test.
<target_preparer class="com.android.tradefed.targetprep.StopServicesSetup"/>
Aggiungi ulteriori argomenti di test
Alcuni test gtest potrebbero richiedere più tempo per essere eseguiti. In questi casi, è possibile aggiungere le opzioni del test runner nel file XML.
Ad esempio, l'impostazione native-test-timeout nella voce seguente consente l'esecuzione del test con un timeout di 3 minuti, invece del 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 un livello API minimo
Alcuni test VTS possono essere eseguiti solo su dispositivi con livello API minimo. Se il file di configurazione del test viene generato automaticamente, puoi aggiungere il seguente attributo ad Android.bp .
test_min_api_level: 29,
Se il file di configurazione del test è personalizzato, aggiungere il comando seguente al file XML del test.
<object type="module_controller" class="com.android.tradefed.testtype.suite.module.MinApiLevelModuleController">
<option name="min-api-level" value="29" />
</object>
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 i casi di test appropriati 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 .
ro.board.first_api_level
La proprietà ro.board.first_api_level è il livello API quando le immagini del fornitore per un SoC vengono rilasciate per la prima volta con questa proprietà. Questo 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 loro 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 dal processo init del fornitore.
ro.board.api_level
La proprietà ro.board.api_level è il livello API corrente delle immagini del fornitore per un SoC. Quando il livello API dell'immagine del fornitore che ha ro.board.first_api_level viene aggiornato, il dispositivo che utilizza il SoC deve definire la proprietà ro.board.api_level con il livello API corrente dell'immagine del fornitore invece di aggiornare ro.board.first_api_level . Se questa proprietà non è impostata, per impostazione predefinita verrà utilizzato ro.board.first_api_level .
Per impostare ro.board.api_level , definire BOARD_API_LEVEL nel file device.mk con il valore desiderato.
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. Questo viene impostato automaticamente sul minimo tra ro.board.api_level (o ro.board.first_api_level se ro.board.api_level non è definito) e ro.product.first_api_level . I test per l'implementazione del fornitore che richiedono l'aggiornamento dell'immagine del fornitore potrebbero essere esclusi dai requisiti del fornitore per il SoC facendo riferimento a questa proprietà.
Processo di sharding utilizzando VTS
Per Android versione 10 o successiva, puoi eseguire il processo di sharding su più dispositivi durante il 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 divide 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 divide il piano CTS-on-GSI in frammenti e li esegue su più dispositivi.