Jedes neue Testmodul muss eine Konfigurationsdatei haben, um das Build-System mit Modulmetadaten, Abhängigkeiten zur Kompilierungszeit und Anweisungen für die Paketerstellung 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 markenbasierte 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 berücksichtigen oder die Android-Kompatibilitätstest-Suite (Compatibility Test Suite, CTS) verwenden möchten, folgen Sie stattdessen der komplexen Testkonfiguration.
Verwendungsbeispiele
Die folgenden Einträge stammen aus dieser Beispiel-Blueprint-Konfigurationsdatei: /platform_testing/tests/example/instrumentation/Android.bp
Hier ist ein Snapshot für Sie:
android_test {
name: "HelloWorldTests",
srcs: ["src/**/*.java"],
sdk_version: "current",
static_libs: ["androidx.test.runner"],
certificate: "platform",
test_suites: ["device-tests"],
}
Die Deklaration android_test am Anfang gibt an, dass es sich um einen Test handelt.
Wenn Sie android_app einfügen, wird umgekehrt angezeigt, dass es sich stattdessen um ein Build-Paket handelt.
Einstellungen
Die folgenden Einstellungen erfordern eine Erklärung:
name: "HelloWorldTests",
Die Einstellung name ist erforderlich, wenn der Modultyp android_test angegeben wird (am Anfang des Blocks). Es gibt dem Modul einen Namen und das resultierende APK hat denselben Namen und das Suffix .apk. In diesem Fall heißt das resultierende Test-APK beispielsweise 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 zugehörigen Abhängigkeiten zu erstellen.
static_libs: ["androidx.test.runner"],
Die Einstellung static_libs weist das Build-System an, den Inhalt der genannten Module in die resultierende APK des aktuellen Moduls einzubinden. Das bedeutet, dass für jedes benannte Modul eine .jar-Datei erstellt wird. Der Inhalt dieser Datei wird zur Auflösung von Klassenpfadreferenzen während der Kompilierung verwendet und in die resultierende APK eingefügt.
Das Modul androidx.test.runner ist das vorgefertigte Modul für die AndroidX-Test-Runner-Bibliothek, 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 Test-Runner beginnen. Der Quellbaum der Plattform enthält auch andere nützliche Testframeworks wie ub-uiautomator, mockito-target und easymock.
certificate: "platform",
Die Einstellung certificate weist das Build-System an, die APK-Datei mit demselben Zertifikat wie die Kernplattform 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. Hinweis: In diesem Beispiel wird diese Zertifikatseinstellung nur zu Veranschaulichungszwecken verwendet. Für den Testcode des Beispiels ist es nicht erforderlich, dass die Test-APK mit dem speziellen Plattformzertifikat signiert ist.
Wenn Sie eine Instrumentierung für Ihre Komponente schreiben, die nicht auf dem Systemserver ausgeführt wird, d. h., sie ist mehr oder weniger wie eine normale App-APK verpackt, mit der Ausnahme, dass sie in das Systemimage eingebunden ist und möglicherweise eine privilegierte App ist, wird Ihre Instrumentierung wahrscheinlich auf das App-Paket (siehe Abschnitt zum Manifest unten) Ihrer Komponente ausgerichtet. In diesem Fall kann das Makefile Ihrer Anwendung eine eigene certificate-Einstellung haben und Ihr Instrumentierungsmodul sollte diese Einstellung beibehalten. Das liegt daran, dass die Test-APK und die App-APK mit demselben Zertifikat signiert sein müssen, damit die Instrumentierung auf die zu testende App ausgerichtet werden kann.
In anderen Fällen müssen Sie diese Einstellung gar nicht haben: Das Build-System signiert sie einfach mit einem integrierten Standardzertifikat, das auf der Build-Variante basiert und in der Regel als dev-keys bezeichnet wird.
test_suites: ["device-tests"],
Durch die Einstellung test_suites kann der Test für das Test-Harnisch der Trade Federation leicht gefunden werden. Hier können weitere Suiten wie CTS hinzugefügt werden, damit dieser Test geteilt werden kann.
${ANDROID_PRODUCT_OUT}/testcases/HelloWorldTests/HelloWorldTests.apk
Optionale Einstellungen
Die folgenden optionalen Einstellungen werden erläutert:
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 der Konfiguration neben der Android.bp eine AndroidTest.xml zugeordnet.
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 „wahr“ festgelegt werden.
require_root: true
Die Einstellung require_root weist das Build-System an, der automatisch generierten Testkonfiguration RootTargetPreparer hinzuzufügen. So 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, der automatisch generierten Testkonfiguration MinApiLevelModuleController hinzuzufügen. Wenn Trade Federation die Testkonfiguration ausführt, wird der Test übersprungen, wenn der Wert der Geräteeigenschaft ro.product.first_api_level < test_min_api_level ist.