Jedes neue Testmodul muss über eine Konfigurationsdatei verfügen, um das Build-System mit Modulmetadaten, Abhängigkeiten zur Kompilierzeit und Paketierungsanweisungen zu steuern. Android verwendet jetzt das Soong-Build-System für eine einfachere Testkonfiguration.
Soong verwendet Blueprint- oder .bp Dateien, die JSON-ähnliche einfache deklarative Beschreibungen von zu erstellenden Modulen sind. Dieses Format ersetzt das Make-basierte System, das in früheren Versionen verwendet wurde. Ausführliche Informationen finden Sie in den Soong-Referenzdateien im Continuous Integration Dashboard .
Um benutzerdefinierte Tests durchzuführen oder die Android Compatibility Test Suite (CTS) zu verwenden, befolgen Sie stattdessen die komplexe Testkonfiguration .
Beispiel
Die folgenden Einträge stammen aus dieser beispielhaften Blueprint-Konfigurationsdatei: /platform_testing/tests/example/instrumentation/Android.bp
Der Einfachheit halber ist hier ein Schnappschuss enthalten:
android_test {
name: "HelloWorldTests",
srcs: ["src/**/*.java"],
sdk_version: "current",
static_libs: ["androidx.test.runner"],
certificate: "platform",
test_suites: ["device-tests"],
}
Beachten Sie, dass die android_test Deklaration am Anfang darauf hinweist, dass es sich um einen Test handelt. Das Einschließen von android_app würde umgekehrt anzeigen, dass es sich stattdessen um ein Build-Paket handelt.
Einstellungen
Die folgenden Einstellungen werden erklärt:
name: "HelloWorldTests",
Die name ist erforderlich, wenn der Modultyp android_test angegeben wird (am Anfang des Blocks). Es gibt Ihrem Modul einen Namen, und die resultierende APK wird genauso benannt und mit einem .apk Suffix versehen, z. B. in diesem Fall wird die resultierende Test-APK als HelloWorldTests.apk bezeichnet. Darüber hinaus definiert dies auch einen Make-Zielnamen für Ihr Modul, sodass Sie make [options] <HelloWorldTests> verwenden können, um Ihr Testmodul und alle seine Abhängigkeiten zu erstellen.
static_libs: ["androidx.test.runner"],
Die Einstellung static_libs weist das Build-System an, den Inhalt der benannten Module in die resultierende apk des aktuellen Moduls zu integrieren. Das bedeutet, dass von jedem benannten Modul erwartet wird, dass es eine .jar Datei erzeugt, und sein Inhalt wird zum Auflösen von Klassenpfadreferenzen während der Kompilierzeit verwendet und in die resultierende apk integriert.
Das Modul androidx.test.runner ist das vorgefertigte Modul für die AndroidX Test Runner Library, die den Testrunner AndroidJUnitRunner enthält. AndroidJUnitRunner unterstützt das JUnit4-Testframework und ersetzt InstrumentationTestRunner in Android 10. Weitere Informationen zum Testen von Android-Apps finden Sie unter Apps auf Android testen .
Wenn Sie ein neues Instrumentierungsmodul erstellen, sollten Sie immer mit der Bibliothek androidx.test.runner als Testrunner beginnen. Der Plattform-Quellbaum enthält auch andere nützliche Test-Frameworks wie ub-uiautomator , mockito-target , easymock und mehr.
certificate: "platform",
Die certificate weist das Build-System an, die APK mit demselben Zertifikat wie die Kernplattform zu signieren. Dies ist erforderlich, wenn Ihr Test eine signaturgeschützte Berechtigung oder API verwendet. Beachten Sie, dass dies für kontinuierliche Plattformtests geeignet ist, aber nicht in CTS-Testmodulen verwendet werden sollte. Beachten Sie, dass dieses Beispiel diese Zertifikatseinstellung nur zur Veranschaulichung verwendet: Der Testcode des Beispiels muss eigentlich nicht mit dem speziellen Plattformzertifikat signiert werden.
Wenn Sie eine Instrumentierung für Ihre Komponente schreiben, die sich außerhalb des Systemservers befindet, d. h. sie ist mehr oder weniger wie eine normale App-APK gepackt, außer dass sie in das System-Image integriert ist und möglicherweise eine privilegierte App ist, besteht die Möglichkeit, dass Ihre Instrumentierung dies tut auf das App-Paket (siehe unten Abschnitt über Manifest) Ihrer Komponente abzielen. In diesem Fall verfügt Ihr Anwendungs-Makefile möglicherweise über eine eigene certificate , und Ihr Instrumentierungsmodul sollte dieselbe Einstellung beibehalten. Dies liegt daran, dass Ihre Test-APK und Ihre App-APK mit demselben Zertifikat signiert sein müssen, um Ihre Instrumentierung auf die zu testende App auszurichten.
In anderen Fällen benötigen Sie diese Einstellung überhaupt nicht: Das Build-System signiert es einfach mit einem standardmäßig integrierten Zertifikat, das auf der Build-Variante basiert und normalerweise als dev-keys bezeichnet wird.
test_suites: ["device-tests"],
Die Einstellung test_suites macht den Test für die Trade Federation-Testumgebung leicht auffindbar. Andere Suiten wie CTS können hier hinzugefügt werden, damit dieser Test geteilt werden kann.
${ANDROID_PRODUCT_OUT}/testcases/HelloWorldTests/HelloWorldTests.apk
Optionale Einstellungen
Die folgenden optionalen Einstellungen werden erklärt:
test_config: "path/to/hello_world_test.xml"
Die Einstellung test_config weist das Build-System an, dass Ihr Testziel eine bestimmte Konfiguration benötigt. Standardmäßig ist eine AndroidTest.xml neben Android.bp mit der Konfiguration verknüpft.
auto_gen_config: true
Die Einstellung auto_gen_config gibt an, ob die Testkonfiguration automatisch erstellt werden soll oder nicht. Wenn neben Android.bp keine AndroidTest.xml vorhanden ist, muss dieses Attribut nicht explizit auf true gesetzt werden.
require_root: true
Die Einstellung require_root weist das Build-System an, RootTargetPreparer zur automatisch generierten Testkonfiguration hinzuzufügen. Dadurch wird garantiert, dass der Test mit Root-Berechtigungen ausgeführt wird.
test_min_api_level: 29
Die Einstellung test_min_api_level weist das Buildsystem an, MinApiLevelModuleController zur automatisch generierten Testkonfiguration hinzuzufügen. Wenn Trade Federation die Testkonfiguration ausführt, wird der Test übersprungen, wenn die Geräteeigenschaft von ro.product.first_api_level < test_min_api_level .
Jedes neue Testmodul muss über eine Konfigurationsdatei verfügen, um das Build-System mit Modulmetadaten, Abhängigkeiten zur Kompilierzeit und Paketierungsanweisungen zu steuern. Android verwendet jetzt das Soong-Build-System für eine einfachere Testkonfiguration.
Soong verwendet Blueprint- oder .bp Dateien, die JSON-ähnliche einfache deklarative Beschreibungen von zu erstellenden Modulen sind. Dieses Format ersetzt das Make-basierte System, das in früheren Versionen verwendet wurde. Ausführliche Informationen finden Sie in den Soong-Referenzdateien im Continuous Integration Dashboard .
Um benutzerdefinierte Tests durchzuführen oder die Android Compatibility Test Suite (CTS) zu verwenden, befolgen Sie stattdessen die komplexe Testkonfiguration .
Beispiel
Die folgenden Einträge stammen aus dieser beispielhaften Blueprint-Konfigurationsdatei: /platform_testing/tests/example/instrumentation/Android.bp
Der Einfachheit halber ist hier ein Schnappschuss enthalten:
android_test {
name: "HelloWorldTests",
srcs: ["src/**/*.java"],
sdk_version: "current",
static_libs: ["androidx.test.runner"],
certificate: "platform",
test_suites: ["device-tests"],
}
Beachten Sie, dass die android_test Deklaration am Anfang darauf hinweist, dass es sich um einen Test handelt. Das Einschließen von android_app würde umgekehrt anzeigen, dass es sich stattdessen um ein Build-Paket handelt.
Einstellungen
Die folgenden Einstellungen werden erklärt:
name: "HelloWorldTests",
Die name ist erforderlich, wenn der Modultyp android_test angegeben wird (am Anfang des Blocks). Es gibt Ihrem Modul einen Namen, und die resultierende APK wird genauso benannt und mit einem .apk Suffix versehen, z. B. in diesem Fall wird die resultierende Test-APK als HelloWorldTests.apk bezeichnet. Darüber hinaus definiert dies auch einen Make-Zielnamen für Ihr Modul, sodass Sie make [options] <HelloWorldTests> verwenden können, um Ihr Testmodul und alle seine Abhängigkeiten zu erstellen.
static_libs: ["androidx.test.runner"],
Die Einstellung static_libs weist das Build-System an, den Inhalt der benannten Module in die resultierende apk des aktuellen Moduls zu integrieren. Das bedeutet, dass von jedem benannten Modul erwartet wird, dass es eine .jar Datei erzeugt, und sein Inhalt wird zum Auflösen von Klassenpfadreferenzen während der Kompilierzeit verwendet und in die resultierende apk integriert.
Das Modul androidx.test.runner ist das vorgefertigte Modul für die AndroidX Test Runner Library, die den Testrunner AndroidJUnitRunner enthält. AndroidJUnitRunner unterstützt das JUnit4-Testframework und ersetzt InstrumentationTestRunner in Android 10. Weitere Informationen zum Testen von Android-Apps finden Sie unter Apps auf Android testen .
Wenn Sie ein neues Instrumentierungsmodul erstellen, sollten Sie immer mit der Bibliothek androidx.test.runner als Testrunner beginnen. Der Plattform-Quellbaum enthält auch andere nützliche Test-Frameworks wie ub-uiautomator , mockito-target , easymock und mehr.
certificate: "platform",
Die certificate weist das Build-System an, die APK mit demselben Zertifikat wie die Kernplattform zu signieren. Dies ist erforderlich, wenn Ihr Test eine signaturgeschützte Berechtigung oder API verwendet. Beachten Sie, dass dies für kontinuierliche Plattformtests geeignet ist, aber nicht in CTS-Testmodulen verwendet werden sollte. Beachten Sie, dass dieses Beispiel diese Zertifikatseinstellung nur zur Veranschaulichung verwendet: Der Testcode des Beispiels muss eigentlich nicht mit dem speziellen Plattformzertifikat signiert werden.
Wenn Sie eine Instrumentierung für Ihre Komponente schreiben, die sich außerhalb des Systemservers befindet, d. h. sie ist mehr oder weniger wie eine normale App-APK gepackt, außer dass sie in das System-Image integriert ist und möglicherweise eine privilegierte App ist, besteht die Möglichkeit, dass Ihre Instrumentierung dies tut auf das App-Paket (siehe unten Abschnitt über Manifest) Ihrer Komponente abzielen. In diesem Fall verfügt Ihr Anwendungs-Makefile möglicherweise über eine eigene certificate , und Ihr Instrumentierungsmodul sollte dieselbe Einstellung beibehalten. Dies liegt daran, dass Ihre Test-APK und Ihre App-APK mit demselben Zertifikat signiert sein müssen, um Ihre Instrumentierung auf die zu testende App auszurichten.
In anderen Fällen benötigen Sie diese Einstellung überhaupt nicht: Das Build-System signiert es einfach mit einem standardmäßig integrierten Zertifikat, das auf der Build-Variante basiert und normalerweise als dev-keys bezeichnet wird.
test_suites: ["device-tests"],
Die Einstellung test_suites macht den Test für die Trade Federation-Testumgebung leicht auffindbar. Andere Suiten wie CTS können hier hinzugefügt werden, damit dieser Test geteilt werden kann.
${ANDROID_PRODUCT_OUT}/testcases/HelloWorldTests/HelloWorldTests.apk
Optionale Einstellungen
Die folgenden optionalen Einstellungen werden erklärt:
test_config: "path/to/hello_world_test.xml"
Die Einstellung test_config weist das Build-System an, dass Ihr Testziel eine bestimmte Konfiguration benötigt. Standardmäßig ist eine AndroidTest.xml neben Android.bp mit der Konfiguration verknüpft.
auto_gen_config: true
Die Einstellung auto_gen_config gibt an, ob die Testkonfiguration automatisch erstellt werden soll oder nicht. Wenn neben Android.bp keine AndroidTest.xml vorhanden ist, muss dieses Attribut nicht explizit auf true gesetzt werden.
require_root: true
Die Einstellung require_root weist das Build-System an, RootTargetPreparer zur automatisch generierten Testkonfiguration hinzuzufügen. Dadurch wird garantiert, dass der Test mit Root-Berechtigungen ausgeführt wird.
test_min_api_level: 29
Die Einstellung test_min_api_level weist das Buildsystem an, MinApiLevelModuleController zur automatisch generierten Testkonfiguration hinzuzufügen. Wenn Trade Federation die Testkonfiguration ausführt, wird der Test übersprungen, wenn die Geräteeigenschaft von ro.product.first_api_level < test_min_api_level .
Jedes neue Testmodul muss über eine Konfigurationsdatei verfügen, um das Build-System mit Modulmetadaten, Abhängigkeiten zur Kompilierzeit und Paketierungsanweisungen zu steuern. Android verwendet jetzt das Soong-Build-System für eine einfachere Testkonfiguration.
Soong verwendet Blueprint- oder .bp Dateien, die JSON-ähnliche einfache deklarative Beschreibungen von zu erstellenden Modulen sind. Dieses Format ersetzt das Make-basierte System, das in früheren Versionen verwendet wurde. Ausführliche Informationen finden Sie in den Soong-Referenzdateien im Continuous Integration Dashboard .
Um benutzerdefinierte Tests durchzuführen oder die Android Compatibility Test Suite (CTS) zu verwenden, befolgen Sie stattdessen die komplexe Testkonfiguration .
Beispiel
Die folgenden Einträge stammen aus dieser beispielhaften Blueprint-Konfigurationsdatei: /platform_testing/tests/example/instrumentation/Android.bp
Der Einfachheit halber ist hier ein Schnappschuss enthalten:
android_test {
name: "HelloWorldTests",
srcs: ["src/**/*.java"],
sdk_version: "current",
static_libs: ["androidx.test.runner"],
certificate: "platform",
test_suites: ["device-tests"],
}
Beachten Sie, dass die android_test Deklaration am Anfang darauf hinweist, dass es sich um einen Test handelt. Das Einschließen von android_app würde umgekehrt anzeigen, dass es sich stattdessen um ein Build-Paket handelt.
Einstellungen
Die folgenden Einstellungen werden erklärt:
name: "HelloWorldTests",
Die name ist erforderlich, wenn der Modultyp android_test angegeben wird (am Anfang des Blocks). Es gibt Ihrem Modul einen Namen, und die resultierende APK wird genauso benannt und mit einem .apk Suffix versehen, z. B. in diesem Fall wird die resultierende Test-APK als HelloWorldTests.apk bezeichnet. Darüber hinaus definiert dies auch einen Make-Zielnamen für Ihr Modul, sodass Sie make [options] <HelloWorldTests> verwenden können, um Ihr Testmodul und alle seine Abhängigkeiten zu erstellen.
static_libs: ["androidx.test.runner"],
Die Einstellung static_libs weist das Build-System an, den Inhalt der benannten Module in die resultierende apk des aktuellen Moduls zu integrieren. Das bedeutet, dass von jedem benannten Modul erwartet wird, dass es eine .jar Datei erzeugt, und sein Inhalt wird zum Auflösen von Klassenpfadreferenzen während der Kompilierzeit verwendet und in die resultierende apk integriert.
Das Modul androidx.test.runner ist das vorgefertigte Modul für die AndroidX Test Runner Library, die den Testrunner AndroidJUnitRunner enthält. AndroidJUnitRunner unterstützt das JUnit4-Testframework und ersetzt InstrumentationTestRunner in Android 10. Weitere Informationen zum Testen von Android-Apps finden Sie unter Apps auf Android testen .
Wenn Sie ein neues Instrumentierungsmodul erstellen, sollten Sie immer mit der Bibliothek androidx.test.runner als Testrunner beginnen. Der Plattform-Quellbaum enthält auch andere nützliche Test-Frameworks wie ub-uiautomator , mockito-target , easymock und mehr.
certificate: "platform",
Die certificate weist das Build-System an, die APK mit demselben Zertifikat wie die Kernplattform zu signieren. Dies ist erforderlich, wenn Ihr Test eine signaturgeschützte Berechtigung oder API verwendet. Beachten Sie, dass dies für kontinuierliche Plattformtests geeignet ist, aber nicht in CTS-Testmodulen verwendet werden sollte. Beachten Sie, dass dieses Beispiel diese Zertifikatseinstellung nur zur Veranschaulichung verwendet: Der Testcode des Beispiels muss eigentlich nicht mit dem speziellen Plattformzertifikat signiert werden.
Wenn Sie eine Instrumentierung für Ihre Komponente schreiben, die sich außerhalb des Systemservers befindet, d. h. sie ist mehr oder weniger wie eine normale App-APK gepackt, außer dass sie in das System-Image integriert ist und möglicherweise eine privilegierte App ist, besteht die Möglichkeit, dass Ihre Instrumentierung dies tut auf das App-Paket (siehe unten Abschnitt über Manifest) Ihrer Komponente abzielen. In diesem Fall verfügt Ihr Anwendungs-Makefile möglicherweise über eine eigene certificate , und Ihr Instrumentierungsmodul sollte dieselbe Einstellung beibehalten. Dies liegt daran, dass Ihre Test-APK und Ihre App-APK mit demselben Zertifikat signiert sein müssen, um Ihre Instrumentierung auf die zu testende App auszurichten.
In anderen Fällen benötigen Sie diese Einstellung überhaupt nicht: Das Build-System signiert es einfach mit einem standardmäßig integrierten Zertifikat, das auf der Build-Variante basiert und normalerweise als dev-keys bezeichnet wird.
test_suites: ["device-tests"],
Die Einstellung test_suites macht den Test für die Trade Federation-Testumgebung leicht auffindbar. Andere Suiten wie CTS können hier hinzugefügt werden, damit dieser Test geteilt werden kann.
${ANDROID_PRODUCT_OUT}/testcases/HelloWorldTests/HelloWorldTests.apk
Optionale Einstellungen
Die folgenden optionalen Einstellungen werden erklärt:
test_config: "path/to/hello_world_test.xml"
Die Einstellung test_config weist das Build-System an, dass Ihr Testziel eine bestimmte Konfiguration benötigt. Standardmäßig ist eine AndroidTest.xml neben Android.bp mit der Konfiguration verknüpft.
auto_gen_config: true
Die Einstellung auto_gen_config gibt an, ob die Testkonfiguration automatisch erstellt werden soll oder nicht. Wenn neben Android.bp keine AndroidTest.xml vorhanden ist, muss dieses Attribut nicht explizit auf true gesetzt werden.
require_root: true
Die Einstellung require_root weist das Build-System an, RootTargetPreparer zur automatisch generierten Testkonfiguration hinzuzufügen. Dadurch wird garantiert, dass der Test mit Root-Berechtigungen ausgeführt wird.
test_min_api_level: 29
Die Einstellung test_min_api_level weist das Buildsystem an, MinApiLevelModuleController zur automatisch generierten Testkonfiguration hinzuzufügen. Wenn Trade Federation die Testkonfiguration ausführt, wird der Test übersprungen, wenn die Geräteeigenschaft von ro.product.first_api_level < test_min_api_level .