Suite di test
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 consente di includerlo in una suite di mappatura dei test utilizzata nei controlli pre-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 build. Tuttavia, puoi personalizzare la configurazione del test.
Crea un file di configurazione di test personalizzato
Creare un nuovo file XML di test da zero può essere complicato, in quanto comporta comprendere il funzionamento del test harness, nonché la differenza tra ogni test runner. 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, esegui prima il comando make per creare la configurazione, come mostrato di seguito.
$ m VtsHalUsbV1_1TargetTest
Nella directory di creazione, 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
in cui 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 il privilegio di root per essere eseguiti. Se il file di configurazione del test 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 del 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 arrestato consente al test di essere eseguito in modo stabile
senza essere influenzato da 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 del test.
<target_preparer class="com.android.tradefed.targetprep.StopServicesSetup"/>
Aggiungere argomenti di test aggiuntivi
L'esecuzione di alcuni test gtest potrebbe richiedere più tempo. In questi casi, puoi aggiungere opzioni di esecuzione dei test nel file XML.
Ad esempio, l'impostazione native-test-timeout nella seguente voce 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 il file di configurazione del test viene generato automaticamente, puoi aggiungere il seguente attributo a Android.bp.
min_shipping_api_level: 29,
o
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>
o
<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. La combinazione di queste proprietà con ro.product.first_api_level,
le suite di test scelgono gli scenari di test appropriati per i dispositivi.
Android 13 definisce ro.vendor.api_level che viene
impostato automaticamente calcolando il livello API fornitore richiesto utilizzando le proprietà
ro.product.first_api_level, ro.board.first_api_level e
ro.board.api_level.
Per ulteriori dettagli, consulta Livello API fornitore.
ro.board.first_api_level
La proprietà ro.board.first_api_level è il livello API quando le immagini del fornitore
per un SoC qualificato 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 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 attuale dell'API fornitore delle immagini del fornitore
che ha il formato YYYYMM in cui è stata bloccata l'API fornitore. Viene
impostato automaticamente dal sistema di build.
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 valore viene impostato automaticamente su
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 a ro.product.first_api_level. La versione verrà
sostituita con il livello API del fornitore corrispondente se è impostata sulla versione
di ro.product.first_api_level, che è 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à.
Processo di sharding utilizzando VTS
Per Android 10 o versioni successive, puoi eseguire il processo di sharding su più dispositivi durante il 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-on-GSI in shard e li esegue su più dispositivi.