Configurazione build semplice

Ogni nuovo modulo di test deve avere un file di configurazione per indirizzare il sistema di compilazione con metadati dei moduli, dipendenze del tempo di compilazione e istruzioni di pacchettizzazione. Ora Android utilizza il sistema di compilazione Soong per configurazione di test.

prestog utilizza file Blueprint o .bp, che sono semplici dichiarazioni dichiarative di tipo JSON le descrizioni dei moduli da creare. Questo formato sostituisce il sistema basato su marca utilizzati nelle release precedenti. Per maggiori dettagli, consulta i file di riferimento di Soong nella dashboard di integrazione continua.

Per supportare i test personalizzati o utilizzare Android Compatibility Test Suite (CTS), segui Configurazione dei test complessi .

Esempio

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

Per praticità viene incluso qui un'istantanea:

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

Tieni presente che la dichiarazione android_test all'inizio indica che si tratta di un test. L'inclusione di android_app indica invece che si tratta di un pacchetto di compilazione.

Impostazioni

Le seguenti impostazioni ti spiegano:

    name: "HelloWorldTests",

L'impostazione name è obbligatoria quando viene specificato il tipo di modulo android_test (all'inizio del blocco). Assegna un nome al modulo e i risultati L'APK avrà lo stesso nome e avrà un suffisso .apk, ad esempio In questo caso, l'APK di test risultante è denominato HelloWorldTests.apk. Inoltre, definisce un nome di destinazione per il modulo, in modo che tu possa utilizzare make [options] <HelloWorldTests> per creare il modulo di test e tutte le sue dipendenze.

    static_libs: ["androidx.test.runner"],

L'impostazione static_libs indica al sistema di compilazione di incorporare i contenuti dei moduli denominati nell'APK risultante del modulo corrente. Ciò significa che ogni modulo denominato dovrebbe generare un file .jar e il suo contenuto utilizzato per risolvere i riferimenti di classpath durante la compilazione, nonché incorporato nell'APK risultante.

Il modulo androidx.test.runner è predefinito per AndroidX Test Runner Libreria che include l'esecutore del test AndroidJUnitRunner. AndroidJUnitRunner supporta il framework di test JUnit4 e ha sostituito InstrumentationTestRunner in Android 10. Scopri di più su come testare le app per Android nella pagina Testare le app su Android.

Se stai creando un nuovo modulo di strumentazione, dovresti sempre iniziare con la raccolta androidx.test.runner come runner del test. L'albero di origine della piattaforma include anche altri framework di test utili, come ub-uiautomator, mockito-target, easymock e altri.

    certificate: "platform",

L'impostazione certificate indica al sistema di compilazione di firmare l'APK con lo stesso come piattaforma di base. Questa autorizzazione è necessaria se il test utilizza una firma in un'API o in un'autorizzazione protetta. Tieni presente che questa funzionalità è adatta per i carichi di lavoro ma non devono essere utilizzati nei moduli di test CTS. Tieni presente che questo esempio utilizza questa impostazione del certificato a solo scopo illustrativo: il codice di test dell'esempio non è necessario che l'APK di prova sia firmato con certificato speciale della piattaforma.

Se stai scrivendo una strumentazione per il tuo componente che risiede al di fuori del server di sistema, ovvero è pacchettizzato più o meno come un normale APK di app, tranne che è integrata nell'immagine di sistema e potrebbe essere un'app con privilegi, è che la tua strumentazione avrà come target il pacchetto dell'app (vedi di seguito relativa al file manifest) del tuo componente. In questo caso, il file makefile dell'applicazione potrebbe avere una propria impostazione certificate e il modulo di misurazione dovrebbe mantenere la stessa impostazione. Ciò è dovuto al fatto che per scegliere come target strumentazione nell'app in fase di test, devi firmare l'APK di test e l'APK dell'app con lo stesso certificato.

In altri casi, questa impostazione non è necessaria: il sistema di compilazione la firma con un certificato predefinito integrato, basato sulla build ed è generalmente chiamata dev-keys.

    test_suites: ["device-tests"],

L'impostazione test_suites consente di trovare facilmente il test da parte del Imbracatura di test della federazione. Qui è possibile aggiungere altre suite, ad esempio CTS, in modo da condividere questo test.

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

Impostazioni facoltative

Le seguenti impostazioni facoltative richiedono una spiegazione:

    test_config: "path/to/hello_world_test.xml"

L'impostazione test_config indica al sistema di build che è necessario per il target di test una configurazione specifica. Per impostazione predefinita, un AndroidTest.xml accanto a Android.bp è associati alla configurazione.

    auto_gen_config: true

L'impostazione auto_gen_config indica se creare o meno la configurazione di test automaticamente. Se AndroidTest.xml non esiste accanto a Android.bp, questo attributo non deve essere impostato su true in modo esplicito.

    require_root: true

L'impostazione require_root indica al sistema di compilazione di aggiungere RootTargetPreparer alla configurazione di test generata automaticamente. Ciò garantisce che il test venga eseguito con root autorizzazioni aggiuntive.

    test_min_api_level: 29

L'impostazione test_min_api_level indica al sistema di compilazione di aggiungere MinApiLevelModuleController alla configurazione di test generata automaticamente. Quando viene negoziato La federazione esegue la configurazione di test; il test verrà ignorato se la proprietà del dispositivo di ro.product.first_api_level < test_min_api_level.