Jedes neue Testmodul muss eine Konfigurationsdatei haben, um das Build-System mit Modulmetadaten, Compile-Time-Abhängigkeiten und Verpackungsanweisungen 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 der zu erstellenden Module enthalten. Dieses Format ersetzt das Make-basierte System, das in früheren Releases verwendet wurde. Ausführliche Informationen finden Sie in den Soong-Referenzdateien im Continuous Integration Dashboard.
Wenn Sie benutzerdefinierte Tests durchführen oder die Compatibility Test Suite (CTS) von Android verwenden möchten, folgen Sie stattdessen der Anleitung unter Komplexe Testkonfiguration.
Beispiel
Die Einträge unten stammen aus dieser Beispielkonfigurationsdatei für Blueprints: /platform_testing/tests/example/instrumentation/Android.bp
Hier ist ein Snapshot zur Veranschaulichung:
android_test {
name: "HelloWorldTests",
srcs: ["src/**/*.java"],
sdk_version: "current",
static_libs: ["androidx.test.runner"],
certificate: "platform",
test_suites: ["device-tests"],
}
Die android_test-Deklaration am Anfang weist darauf hin, dass es sich um einen Test handelt.
Wenn Sie android_app einfügen, wird angegeben, dass es sich stattdessen um ein Build-Paket handelt.
Einstellungen
Die folgenden Einstellungen sind erklärungsbedürftig:
name: "HelloWorldTests",
Die Einstellung name ist erforderlich, wenn der Modultyp android_test (am Anfang des Blocks) angegeben wird. Damit wird Ihrem Modul ein Name zugewiesen.Das resultierende APK hat denselben Namen und das Suffix .apk. In diesem Fall heißt das resultierende Test-APK also HelloWorldTests.apk. Außerdem wird dadurch ein Make-Zielname für Ihr Modul definiert, 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, die Inhalte der benannten Module in das resultierende APK des aktuellen Moduls aufzunehmen. Das bedeutet, dass jedes benannte Modul eine .jar-Datei erzeugen muss. Deren Inhalt wird zur Laufzeit zum Auflösen von Classpath-Verweisen verwendet und in die resultierende APK-Datei eingebunden.
Das Modul androidx.test.runner ist das vorgefertigte Modul für die AndroidX Test Runner Library, die den Test-Runner AndroidJUnitRunner enthält.
AndroidJUnitRunner unterstützt das JUnit4-Test-Framework und hat InstrumentationTestRunner in Android 10 ersetzt. Weitere Informationen zum Testen von Android-Apps
Wenn Sie ein neues Instrumentierungsmodul erstellen, sollten Sie immer mit der androidx.test.runner-Bibliothek als Testrunner beginnen. Der Plattform-Quellbaum enthält auch andere nützliche Testframeworks wie ub-uiautomator, mockito-target und easymock.
certificate: "platform",
Die Einstellung certificate weist das Build-System an, das APK mit demselben Zertifikat wie die Core-Plattform zu signieren. Dies ist erforderlich, wenn in Ihrem Test eine signaturgeschützte Berechtigung oder API verwendet wird. Diese Methode eignet sich für kontinuierliche Plattformtests, sollte aber nicht in CTS-Testmodulen verwendet werden. In diesem Beispiel wird diese Zertifikateinstellung nur zur Veranschaulichung verwendet. Der Testcode des Beispiels erfordert nicht, dass das Test-APK mit dem speziellen Plattformzertifikat signiert wird.
Wenn Sie eine Instrumentation für Ihre Komponente schreiben, die sich außerhalb des Systemservers befindet, d. h. mehr oder weniger wie ein reguläres App-APK verpackt ist, mit der Ausnahme, dass sie in das Systemimage integriert ist und möglicherweise eine privilegierte App ist, wird Ihre Instrumentation wahrscheinlich auf das App-Paket (siehe Abschnitt zum Manifest unten) Ihrer Komponente ausgerichtet sein. In diesem Fall hat das Makefile Ihrer Anwendung möglicherweise eine eigene certificate-Einstellung und Ihr Instrumentierungsmodul sollte dieselbe Einstellung beibehalten. Das liegt daran, dass Ihre Test-APK und Ihre App-APK mit demselben Zertifikat signiert sein müssen, damit Ihre Instrumentation auf die zu testende App ausgerichtet werden kann.
In anderen Fällen ist diese Einstellung gar nicht erforderlich: Das Build-System signiert sie einfach mit einem standardmäßigen integrierten Zertifikat, das auf der Build-Variante basiert und in der Regel als dev-keys bezeichnet wird.
test_suites: ["device-tests"],
Die Einstellung test_suites sorgt dafür, dass der Test vom Trade Federation-Test-Harness leicht gefunden werden kann. Hier können weitere Suiten wie CTS hinzugefügt werden, damit dieser Test freigegeben werden kann.
${ANDROID_PRODUCT_OUT}/testcases/HelloWorldTests/HelloWorldTests.apk
Optionale Einstellungen
Die folgenden optionalen Einstellungen müssen erläutert werden:
test_config: "path/to/hello_world_test.xml"
Die Einstellung test_config weist das Build-System an, dass für das Testziel eine bestimmte Konfiguration erforderlich ist. Standardmäßig ist eine AndroidTest.xml neben der 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. Wenn AndroidTest.xml nicht neben Android.bp vorhanden ist, muss dieses Attribut nicht explizit auf „true“ gesetzt werden.
require_root: true
Die Einstellung require_root weist das Build-System an, RootTargetPreparer der automatisch generierten Testkonfiguration hinzuzufügen. Dadurch wird sichergestellt, dass der Test mit Root-Berechtigungen ausgeführt wird.
test_min_api_level: 29
Die Einstellung test_min_api_level weist das Build-System an, MinApiLevelModuleController der automatisch generierten Testkonfiguration hinzuzufügen. Wenn Trade Federation die Testkonfiguration ausführt, wird der Test übersprungen, wenn die Geräte-Property ro.product.first_api_level < test_min_api_level ist.