Configurazione di build semplice

Ogni nuovo modulo di test deve avere un file di configurazione per dirigere il sistema di compilazione con i metadati del modulo, le dipendenze in fase di compilazione e le istruzioni di confezionamento. Android utilizza ora il sistema di generazione Soong per la configurazione di prova più semplice.

Soong utilizza Blueprint o .bp file, che sono JSON-come semplici descrizioni dichiarativi dei moduli per costruire. Questo formato sostituisce il sistema basato su Make utilizzato nelle versioni precedenti. Vedere i file di riferimento Soong sul Continuous Integration Dashboard per tutti i dettagli.

Per ospitare il test personalizzato o utilizzare l'Android Compatibility Test Suite (CTS), seguire Configurazione di prova Complex , invece.

Esempio

Le voci di seguito provengono da questo file di configurazione Blueprint esempio: /platform_testing/tests/example/instrumentation/Android.bp

Un'istantanea è inclusa qui per comodità:

android_test {
    name: "HelloWorldTests",
    srcs: ["src/**/*.java"],
    sdk_version: "current",
    static_libs: ["android-support-test"],
    certificate: "platform",
    test_suites: ["device-tests"],
}

Si noti la android_test dichiarazione all'inizio indica questa è una prova. Compreso android_app sarebbe contrario indicare questo è invece un pacchetto di build.

Impostazioni

Le seguenti impostazioni ottengono una spiegazione:

    name: "HelloWorldTests",

Il name impostazione è necessaria quando il android_test è specificato tipo di modulo (all'inizio del blocco). Si dà un nome al modulo, e la conseguente APK si chiamerà la stessa e con un .apk il suffisso, ad esempio, in questo caso, con conseguente apk prova è chiamato come HelloWorldTests.apk . Inoltre, questo definisce anche un nome di destinazione fare per il vostro modulo, in modo che è possibile utilizzare make [options] <HelloWorldTests> per costruire il vostro modulo di prova e tutte le sue dipendenze.

    static_libs: ["android-support-test"],

I static_libs impostazione indica il sistema di generazione di incorporare il contenuto dei moduli denominati nel apk risultante modulo corrente. Questo significa che ogni modulo denominato dovrebbe produrre un .jar di file, e il suo contenuto saranno utilizzati per risolvere i riferimenti percorso di classe durante la fase di compilazione, così come incorporato nella apk risultante.

In questo esempio, cose che potrebbero essere generalmente utili per i test:

Il android-support-test è la precompilati per il supporto di prova Biblioteca Android, che include il nuovo test corridore AndroidJUnitRunner : un sostituto per l'ormai deprecato incorporato InstrumentationTestRunner , con il supporto per JUnit4 framework di test. Per saperne di più in applicazioni di analisi su Android .

Se si crea un nuovo modulo strumentazione, si dovrebbe sempre iniziare con il android-support-test biblioteca come test runner. L'albero fonte piattaforma include anche altri framework di test utili quali ub-uiautomator , mockito-target , easymock e più.

    certificate: "platform",

Il certificate impostazione istruisce il sistema di generazione di firmare l'apk con lo stesso certificato come piattaforma centrale. Ciò è necessario se il test utilizza un'autorizzazione o un'API protetta da firma. Si noti che ciò è adatto per la piattaforma test continuo, ma non deve essere utilizzato in moduli di test CTS. Si noti che questo esempio utilizza questa impostazione del certificato solo a scopo illustrativo: il codice di test dell'esempio non ha effettivamente bisogno che l'apk di test sia firmato con lo speciale certificato della piattaforma.

Se stai scrivendo una strumentazione per il tuo componente che vive al di fuori del server di sistema, cioè è impacchettata più o meno come un normale apk di app, tranne per il fatto che è integrata nell'immagine del sistema e potrebbe essere un'app privilegiata, è probabile che la tua strumentazione mirare al pacchetto dell'app (vedi sotto la sezione relativa al manifest) del tuo componente. In questo caso, makefile applicazione potrebbe avere il proprio certificate impostazione, e il modulo di strumentazione dovrebbe mantenere la stessa impostazione. Questo perché per indirizzare la tua strumentazione sull'app in prova, l'apk di prova e l'apk dell'app devono essere firmati con lo stesso certificato.

In altri casi, non c'è bisogno di avere questa impostazione a tutti: il sistema di compilazione si limiterà a firmare con un default built-in certificati, in base alla variante di accumulo, e è in genere chiamato i dev-keys .

    test_suites: ["device-tests"],

Il test_suites impostazione rende il test facilmente rilevabile dal test harness Federazione dei Mercanti. Altre suite possono essere aggiunte qui come CTS in modo che questo test possa essere condiviso.

${ANDROID_PRODUCT_OUT}/testcases/HelloWorldTests/HelloWorldTests.apk

Impostazioni opzionali

Le seguenti impostazioni opzionali ottengono una spiegazione:

    test_config: "path/to/hello_world_test.xml"

Il test_config impostazione istruisce il sistema di compilazione il vostro target di test ha bisogno di una specifica configurazione. Per impostazione predefinita, un AndroidTest.xml accanto al Android.bp è associato con il config.

    auto_gen_config: true

auto_gen_config impostazione indica se creare o meno la configurazione di prova automaticamente. Se AndroidTest.xml non esiste accanto al Android.bp , questo attributo non ha bisogno di essere impostata su true in modo esplicito.

    require_root: true

Il require_root impostazione indica al sistema di compilazione per aggiungere RootTargetPreparer alla generato automaticamente configurazione di prova. Ciò garantisce l'esecuzione del test con i permessi di root.

    test_min_api_level: 29

Il test_min_api_level impostazione indica al sistema di compilazione per aggiungere MinApiLevelModuleController alla generato automaticamente configurazione di prova. Quando Federazione dei Mercanti gestisce la configurazione di test, il test sarà saltato se la proprietà dispositivo di ro.product.first_api_level < test_min_api_level .