Android-Plattformtests

Das Android Open Source Project (AOSP) bietet mehrere Tools und Testsuites zum Testen verschiedener Teile Ihrer Implementierung. Bevor Sie die Seiten in diesem Abschnitt verwenden, sollten Sie mit den folgenden Begriffen vertraut sein:

Android-kompatibles Gerät
Ein Gerät, auf dem alle Drittanbieter-Apps ausgeführt werden können, die von Drittanbietern mit dem Android SDK und dem NDK entwickelt wurden. Android-kompatible Geräte müssen den Anforderungen des Compatibility Definition Document (CDD) entsprechen und die Compatibility Test Suite (CTS) bestehen. Mit Android kompatible Geräte können Teil des Android-Ökosystems werden. Dazu gehören die potenzielle Lizenzierung von Google Play, die potenzielle Lizenzierung der App- und APIs-Suite der Google Mobile-Dienste sowie die Verwendung der Marke Android. Jeder kann den Android-Quellcode verwenden. Damit ein Gerät als Teil des Android-Ökosystems betrachtet wird, muss es jedoch mit Android kompatibel sein.
Artefakt
Ein Build-bezogenes Protokoll, das eine lokale Fehlerbehebung ermöglicht.
Compatibility Definition Document (CDD)
Ein Dokument, in dem die Software- und Hardwareanforderungen für ein Android-kompatibles Gerät aufgeführt sind.
Kompatibilitätstest-Suite (Compatibility Test Suite, CTS)

Eine kostenlose Testsuite für kommerzielle Zwecke, die als Binärdatei oder als Quelle in AOSP zum Download zur Verfügung steht. Die CTS besteht aus einer Reihe von Unit-Tests, die in Ihren täglichen Workflow integriert werden können. CTS soll Inkompatibilitäten aufdecken und dafür sorgen, dass die Software während des gesamten Entwicklungsprozesses kompatibel bleibt.

CTS- und Plattformtests schließen sich nicht gegenseitig aus. Hier sind einige allgemeine Richtlinien:

  • Wenn ein Test die Korrektheit von Framework-API-Funktionen oder -Verhaltenen bestätigt und der Test für alle OEM-Partner erzwungen werden soll, sollte er im CTS enthalten sein.
  • Wenn ein Test dazu dient, Regressionen während der Plattformentwicklung zu erkennen, für die Ausführung eine Berechtigung erforderlich ist und er von Implementierungsdetails abhängen kann (wie im AOSP veröffentlicht), sollte es sich um einen Plattformtest handeln.
Google Mobile-Dienste (GMD)

Eine Sammlung von Google-Apps und -APIs, die auf Geräten vorinstalliert werden können.

GoogleTest (GTest)

Ein C++-Framework zum Testen und Mocking. GTest-Binärdateien greifen in der Regel auf Abstraktionsschichten niedrigerer Ebene zu oder führen einen Roh-IPC mit verschiedenen Systemdiensten aus. Der Testansatz für GTest ist in der Regel eng mit dem zu testenden Dienst verknüpft. CTS enthält das GTest-Framework.

Instrumentierungstest

Eine spezielle Testausführungsumgebung, die über den Befehl am instrument gestartet wird. Dabei wird der betreffende App-Prozess neu gestartet und mit dem grundlegenden App-Kontext initialisiert. Außerdem wird ein Instrumentierungs-Thread innerhalb der virtuellen Maschine des App-Prozesses gestartet. CTS enthält Instrumentierungstests.

Logcat

Ein Befehlszeilentool, das ein Log von Systemmeldungen erstellt, einschließlich Stacktraces von Fehlern und Meldungen, die Sie mit der Klasse Log aus Ihrer Anwendung geschrieben haben.

Logging

Mit einem Protokoll werden Computersystemereignisse wie Fehler erfasst. Die Protokollierung unter Android ist aufgrund der verschiedenen Standards, die im Logcat-Tool kombiniert werden, komplex.

postsubmit test

Android-Test, der durchgeführt wird, wenn ein neuer Patch an einen gemeinsamen Kernel-Branch übergeben wird. Wenn Sie aosp_kernel als partiellen Zweignamen eingeben, können Sie eine Liste der Kernel-Zweige mit verfügbaren Ergebnissen aufrufen. Ergebnisse für android-mainline finden Sie beispielsweise unter https://ci.android.com/builds/branches/aosp_kernel-common-android-mainline/grid.

presubmit-Test

Ein Test, mit dem verhindert wird, dass Fehler in die gemeinsamen Kernel eindringen.

Handelsverband

Auch Tradefed genannt, ein Framework für kontinuierliche Tests, das für die Ausführung von Tests auf Android-Geräten entwickelt wurde. „Tradefed“ wird beispielsweise zum Ausführen von Tests der Kompatibilitätstest-Suite und der Vendor Test Suite verwendet.

Vendor Test Suite (VTS)

Eine Reihe umfangreicher Funktionen für Android-Tests, die einen testgetriebenen Entwicklungsprozess fördern und die Tests der Hardwareabstraktionsschicht (HAL) und des Betriebssystemkernels automatisieren.

Plattformtesttypen

Ein Plattformtest interagiert in der Regel mit einem oder mehreren Android-Systemdiensten oder HAL-Ebenen, testet die Funktionen des Testobjekts und prüft die Richtigkeit des Testergebnisses. Ein Plattformtest kann Folgendes umfassen:

  • (Typ 1) Framework-APIs mit dem Android-Framework üben Beispiele für APIs, die genutzt werden:
    • Öffentliche APIs für Drittanbieter-Apps
    • Ausgeblendete APIs für privilegierte Apps, nämlich System-APIs oder private APIs (@hide, protected oder package private)
  • (Typ 2) Android-Systemdienste direkt über Rohbinder oder IPC-Proxys aufrufen.
  • (Typ 3) Interagieren Sie über Low-Level-APIs oder IPC-Schnittstellen direkt mit HALs.

Tests vom Typ 1 und 2 sind in der Regel Instrumentierungstests, während Tests vom Typ 3 in der Regel GTests sind.

Wie geht es weiter?

Hier finden Sie eine Liste mit Dokumenten, in denen Sie weitere Informationen finden: