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 impacchettamento. Android ora utilizza il sistema di compilazione Soong per una configurazione di test più semplice.
Soong utilizza file Blueprint o .bp , che sono semplici descrizioni dichiarative simili a JSON dei moduli da creare. Questo formato sostituisce il sistema basato su Make utilizzato nelle versioni precedenti. Consulta i file di riferimento di Soong nel dashboard di integrazione continua per i dettagli completi.
Per eseguire test personalizzati o utilizzare Android Compatibility Test Suite (CTS), segui invece Complex Test Configuration .
Esempio
Le voci seguenti provengono da questo esempio di file di configurazione Blueprint: /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: ["androidx.test.runner"],
certificate: "platform",
test_suites: ["device-tests"],
}
Nota che la dichiarazione android_test all'inizio indica che si tratta di un test. L'inclusione di android_app indicherebbe al contrario che si tratta invece di un pacchetto di compilazione.
Impostazioni
Le seguenti impostazioni ottengono una spiegazione:
name: "HelloWorldTests",
L'impostazione name è richiesta quando viene specificato il tipo di modulo android_test (all'inizio del blocco). Assegna un nome al tuo modulo e l'APK risultante avrà lo stesso nome e con un suffisso .apk , ad esempio in questo caso, l'apk di test risultante è denominato HelloWorldTests.apk . Inoltre, questo definisce anche un nome target make per il tuo modulo, in modo che tu possa usare make [options] <HelloWorldTests> per costruire il tuo modulo di test e tutte le sue dipendenze.
static_libs: ["androidx.test.runner"],
L'impostazione static_libs indica al sistema di compilazione di incorporare il contenuto dei moduli denominati nell'apk risultante del modulo corrente. Ciò significa che ogni modulo denominato dovrebbe produrre un file .jar e il suo contenuto verrà utilizzato per risolvere i riferimenti del percorso di classe durante la fase di compilazione, nonché incorporato nell'apk risultante.
Il modulo androidx.test.runner è precompilato per la libreria AndroidX Test Runner, che include il test runner AndroidJUnitRunner . AndroidJUnitRunner supporta il framework di test JUnit4 e ha sostituito InstrumentationTestRunner in Android 10. Leggi ulteriori informazioni sul test delle app Android in Test delle app su Android .
Se stai costruendo un nuovo modulo di strumentazione, dovresti sempre iniziare con la libreria androidx.test.runner come test runner. L'albero dei sorgenti della piattaforma include anche altri utili framework di test 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 certificato della piattaforma principale. Questo è necessario se il test utilizza un'autorizzazione o un'API protetta da firma. Si noti che questo è adatto per il test continuo della piattaforma, ma non deve essere utilizzato nei moduli di test CTS. Tieni presente che questo esempio utilizza questa impostazione del certificato solo a scopo illustrativo: il codice di test dell'esempio non richiede effettivamente che l'apk di test sia firmato con il certificato della piattaforma speciale.
Se stai scrivendo una strumentazione per il tuo componente che risiede al di fuori del server di sistema, ovvero è impacchettata più o meno come un normale apk dell'app, tranne per il fatto che è integrata nell'immagine di sistema e potrebbe essere un'app privilegiata, è probabile che la tua strumentazione lo farà bersagliare il pacchetto dell'app (vedi sotto la sezione sul manifest) del tuo componente. In questo caso, il makefile dell'applicazione potrebbe avere la propria impostazione certificate e il modulo di strumentazione dovrebbe mantenere la stessa impostazione. Questo perché per indirizzare la tua strumentazione sull'app sottoposta a test, l'apk di test e l'apk dell'app devono essere firmati con lo stesso certificato.
In altri casi, non è necessario disporre di questa impostazione: il sistema di compilazione la firmerà semplicemente con un certificato integrato predefinito, basato sulla variante di compilazione, ed è in genere chiamato dev-keys .
test_suites: ["device-tests"],
L'impostazione test_suites rende il test facilmente rilevabile dal cablaggio di test della 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"
L'impostazione test_config indica al sistema di compilazione che la destinazione del test necessita di una configurazione specifica. Per impostazione predefinita, un AndroidTest.xml accanto a Android.bp è associato al file config.
auto_gen_config: true
L'impostazione auto_gen_config indica se creare o meno automaticamente la configurazione di test. Se AndroidTest.xml non esiste accanto a Android.bp , questo attributo non deve essere impostato esplicitamente su true.
require_root: true
L'impostazione require_root indica al sistema di compilazione di aggiungere RootTargetPreparer alla configurazione di test generata automaticamente. Ciò garantisce l'esecuzione del test con i permessi di root.
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 Trade Federation esegue la configurazione del test, il test verrà saltato se la proprietà del dispositivo di ro.product.first_api_level < test_min_api_level .
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 impacchettamento. Android ora utilizza il sistema di compilazione Soong per una configurazione di test più semplice.
Soong utilizza file Blueprint o .bp , che sono semplici descrizioni dichiarative simili a JSON dei moduli da creare. Questo formato sostituisce il sistema basato su Make utilizzato nelle versioni precedenti. Consulta i file di riferimento di Soong nel dashboard di integrazione continua per i dettagli completi.
Per eseguire test personalizzati o utilizzare Android Compatibility Test Suite (CTS), segui invece Complex Test Configuration .
Esempio
Le voci seguenti provengono da questo esempio di file di configurazione Blueprint: /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: ["androidx.test.runner"],
certificate: "platform",
test_suites: ["device-tests"],
}
Nota che la dichiarazione android_test all'inizio indica che si tratta di un test. L'inclusione di android_app indicherebbe al contrario che si tratta invece di un pacchetto di compilazione.
Impostazioni
Le seguenti impostazioni ottengono una spiegazione:
name: "HelloWorldTests",
L'impostazione name è richiesta quando viene specificato il tipo di modulo android_test (all'inizio del blocco). Assegna un nome al tuo modulo e l'APK risultante avrà lo stesso nome e con un suffisso .apk , ad esempio in questo caso, l'apk di test risultante è denominato HelloWorldTests.apk . Inoltre, questo definisce anche un nome target make per il tuo modulo, in modo che tu possa usare make [options] <HelloWorldTests> per costruire il tuo modulo di test e tutte le sue dipendenze.
static_libs: ["androidx.test.runner"],
L'impostazione static_libs indica al sistema di compilazione di incorporare il contenuto dei moduli denominati nell'apk risultante del modulo corrente. Ciò significa che ogni modulo denominato dovrebbe produrre un file .jar e il suo contenuto verrà utilizzato per risolvere i riferimenti del percorso di classe durante la fase di compilazione, nonché incorporato nell'apk risultante.
Il modulo androidx.test.runner è precompilato per la libreria AndroidX Test Runner, che include il test runner AndroidJUnitRunner . AndroidJUnitRunner supporta il framework di test JUnit4 e ha sostituito InstrumentationTestRunner in Android 10. Leggi ulteriori informazioni sul test delle app Android in Test delle app su Android .
Se stai costruendo un nuovo modulo di strumentazione, dovresti sempre iniziare con la libreria androidx.test.runner come test runner. L'albero dei sorgenti della piattaforma include anche altri utili framework di test 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 certificato della piattaforma principale. Questo è necessario se il test utilizza un'autorizzazione o un'API protetta da firma. Si noti che questo è adatto per il test continuo della piattaforma, ma non deve essere utilizzato nei moduli di test CTS. Tieni presente che questo esempio utilizza questa impostazione del certificato solo a scopo illustrativo: il codice di test dell'esempio non richiede effettivamente che l'apk di test sia firmato con il certificato della piattaforma speciale.
Se stai scrivendo una strumentazione per il tuo componente che risiede al di fuori del server di sistema, ovvero è impacchettata più o meno come un normale apk dell'app, tranne per il fatto che è integrata nell'immagine di sistema e potrebbe essere un'app privilegiata, è probabile che la tua strumentazione lo farà bersagliare il pacchetto dell'app (vedi sotto la sezione sul manifest) del tuo componente. In questo caso, il makefile dell'applicazione potrebbe avere la propria impostazione certificate e il modulo di strumentazione dovrebbe mantenere la stessa impostazione. Questo perché per indirizzare la tua strumentazione sull'app sottoposta a test, l'apk di test e l'apk dell'app devono essere firmati con lo stesso certificato.
In altri casi, non è necessario disporre di questa impostazione: il sistema di compilazione la firmerà semplicemente con un certificato integrato predefinito, basato sulla variante di compilazione, ed è in genere chiamato dev-keys .
test_suites: ["device-tests"],
L'impostazione test_suites rende il test facilmente rilevabile dal cablaggio di test della 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"
L'impostazione test_config indica al sistema di compilazione che la destinazione del test necessita di una configurazione specifica. Per impostazione predefinita, un AndroidTest.xml accanto a Android.bp è associato al file config.
auto_gen_config: true
L'impostazione auto_gen_config indica se creare o meno automaticamente la configurazione di test. Se AndroidTest.xml non esiste accanto a Android.bp , questo attributo non deve essere impostato esplicitamente su true.
require_root: true
L'impostazione require_root indica al sistema di compilazione di aggiungere RootTargetPreparer alla configurazione di test generata automaticamente. Ciò garantisce l'esecuzione del test con i permessi di root.
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 Trade Federation esegue la configurazione del test, il test verrà saltato se la proprietà del dispositivo di ro.product.first_api_level < test_min_api_level .
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 impacchettamento. Android ora utilizza il sistema di compilazione Soong per una configurazione di test più semplice.
Soong utilizza file Blueprint o .bp , che sono semplici descrizioni dichiarative simili a JSON dei moduli da creare. Questo formato sostituisce il sistema basato su Make utilizzato nelle versioni precedenti. Consulta i file di riferimento di Soong nel dashboard di integrazione continua per i dettagli completi.
Per eseguire test personalizzati o utilizzare Android Compatibility Test Suite (CTS), segui invece Complex Test Configuration .
Esempio
Le voci seguenti provengono da questo esempio di file di configurazione Blueprint: /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: ["androidx.test.runner"],
certificate: "platform",
test_suites: ["device-tests"],
}
Nota che la dichiarazione android_test all'inizio indica che si tratta di un test. L'inclusione di android_app indicherebbe al contrario che si tratta invece di un pacchetto di compilazione.
Impostazioni
Le seguenti impostazioni ottengono una spiegazione:
name: "HelloWorldTests",
L'impostazione name è richiesta quando viene specificato il tipo di modulo android_test (all'inizio del blocco). Assegna un nome al tuo modulo e l'APK risultante avrà lo stesso nome e con un suffisso .apk , ad esempio in questo caso, l'apk di test risultante è denominato HelloWorldTests.apk . Inoltre, questo definisce anche un nome target make per il tuo modulo, in modo che tu possa usare make [options] <HelloWorldTests> per costruire il tuo modulo di test e tutte le sue dipendenze.
static_libs: ["androidx.test.runner"],
L'impostazione static_libs indica al sistema di compilazione di incorporare il contenuto dei moduli denominati nell'apk risultante del modulo corrente. Ciò significa che ogni modulo denominato dovrebbe produrre un file .jar e il suo contenuto verrà utilizzato per risolvere i riferimenti del percorso di classe durante la fase di compilazione, nonché incorporato nell'apk risultante.
Il modulo androidx.test.runner è precompilato per la libreria AndroidX Test Runner, che include il test runner AndroidJUnitRunner . AndroidJUnitRunner supporta il framework di test JUnit4 e ha sostituito InstrumentationTestRunner in Android 10. Leggi ulteriori informazioni sul test delle app Android in Test delle app su Android .
Se stai costruendo un nuovo modulo di strumentazione, dovresti sempre iniziare con la libreria androidx.test.runner come test runner. L'albero dei sorgenti della piattaforma include anche altri utili framework di test 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 certificato della piattaforma principale. Questo è necessario se il test utilizza un'autorizzazione o un'API protetta da firma. Si noti che questo è adatto per il test continuo della piattaforma, ma non deve essere utilizzato nei moduli di test CTS. Tieni presente che questo esempio utilizza questa impostazione del certificato solo a scopo illustrativo: il codice di test dell'esempio non richiede effettivamente che l'apk di test sia firmato con il certificato della piattaforma speciale.
Se stai scrivendo una strumentazione per il tuo componente che risiede al di fuori del server di sistema, ovvero è impacchettata più o meno come un normale apk dell'app, tranne per il fatto che è integrata nell'immagine di sistema e potrebbe essere un'app privilegiata, è probabile che la tua strumentazione lo farà bersagliare il pacchetto dell'app (vedi sotto la sezione sul manifest) del tuo componente. In questo caso, il makefile dell'applicazione potrebbe avere la propria impostazione certificate e il modulo di strumentazione dovrebbe mantenere la stessa impostazione. Questo perché per indirizzare la tua strumentazione sull'app sottoposta a test, l'apk di test e l'apk dell'app devono essere firmati con lo stesso certificato.
In altri casi, non è necessario disporre di questa impostazione: il sistema di compilazione la firmerà semplicemente con un certificato integrato predefinito, basato sulla variante di compilazione, ed è in genere chiamato dev-keys .
test_suites: ["device-tests"],
L'impostazione test_suites rende il test facilmente rilevabile dal cablaggio di test della 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"
L'impostazione test_config indica al sistema di compilazione che la destinazione del test necessita di una configurazione specifica. Per impostazione predefinita, un AndroidTest.xml accanto a Android.bp è associato al file config.
auto_gen_config: true
L'impostazione auto_gen_config indica se creare o meno automaticamente la configurazione di test. Se AndroidTest.xml non esiste accanto a Android.bp , questo attributo non deve essere impostato esplicitamente su true.
require_root: true
L'impostazione require_root indica al sistema di compilazione di aggiungere RootTargetPreparer alla configurazione di test generata automaticamente. Ciò garantisce l'esecuzione del test con i permessi di root.
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 Trade Federation esegue la configurazione del test, il test verrà saltato se la proprietà del dispositivo di ro.product.first_api_level < test_min_api_level .