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 del test
Nella maggior parte dei casi, il file di 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 il file di configurazione del test.
Crea un file di configurazione di test personalizzato
Creare un nuovo file XML del test da zero può essere complicato, in quanto richiede che si conosca 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 del test, puoi usare il file generato automaticamente come punto di partenza.
Per individuare il file di configurazione del test generato automaticamente, esegui prima il comando make per creare la configurazione, come mostrato di seguito.
$ m VtsHalUsbV1_1TargetTest
Nella directory "out" della build, 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 come 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 di seguito.
test_config: "VtsHalUsbV1_1TargetTest.xml",
Ora hai un file di configurazione del 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, interrompendo il framework, il test può essere eseguito in modo più stabile, senza essere influenzato da eventuali instabilità 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 ulteriori argomenti di test
L'esecuzione di alcuni test gtest potrebbe richiedere più tempo. In questi casi, puoi aggiungere delle 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>
Richiedere un 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. 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 ro.vendor.api_level che viene impostato automaticamente calcolando il livello API fornitore richiesto mediante l'uso delle 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à. Questo non dipende dal livello API con cui viene avviato il 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 dal processo init
del fornitore.
ro.board.api_level
La proprietà ro.board.api_level indica l'attuale livello API fornitore delle immagini del fornitore ed è espressa nel formato YYYYMM, corrispondente al periodo in cui l'API del fornitore è stata congelata. Viene impostata 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 rispetto a ro.product.first_api_level. La versione verrà sostituita con il corrispondente livello API fornitore se è impostata sul valore di ro.product.first_api_level ed è 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-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 shard ed esegue questi ultimi 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 ed esegue questi ultimi su più dispositivi.