Infrastruktur für automatisierte Tests

Android 9 enthält eine VTS-Infrastruktur (Vendor Test Suite) für automatisierte VTS-, CTS- oder andere Tests auf Partnergeräten mit dem generischen AOSP-System-Image (GSI). Bisher war die Durchführung dieser Tests sehr manuell. Die neue VTS-Testinfrastruktur wurde entwickelt, um automatisierte Tests mehrmals täglich auf mehreren Geräten zu unterstützen.

Architektur

Die automatisierte Testinfrastruktur von VTS verwendet die folgende Architektur:

Wenn ein Test ausgelöst wird, führt die automatisierte Testinfrastruktur von VTS die folgenden Aufgaben aus:

1. Er ruft Build-Artefakte und Testressourcen von verschiedenen Orten ab:
   • Partner Android Build (PAB) Für das GSI, das VTS-Framework und einige andere Builds.
   • Lokales Dateisystem, Google Cloud Storage oder anderes anbieterspezifisches Build-System Für Partner, die Builds nicht in der Google-Cloud speichern.
2. Flasht Build-Artefakte (vom Gerät) und die GSI (von AOSP) auf die verbundenen Geräte.
3. Führt VTS-Tests mit einer lokalen TradeFed oder einer TradeFed in der Cloud aus.
4. Testergebnisse an das VTS-Dashboard melden

Der Prozess wird vom VTS-Hostcontroller (HC) koordiniert, einem Computer im Labor, der das Verhalten aller verbundenen Testgeräte steuert. Der HC ist für das Abrufen der neuesten Builds, das Flashen auf Geräte und das Aufrufen von Tests (entweder lokal oder über den Commander) verantwortlich. Außerdem kommuniziert er mit einem Cloud-Scheduler und leitet Traffic zwischen dem Scheduler und der TradeFed-Instanz (oder einem anderen Harness) weiter, die auf dem HC ausgeführt wird. Weitere Informationen zum Hostcontroller finden Sie unter Hostcontroller-Architektur.

Ressourcenanbieter

Für automatisierte Tests sind Ressourcen wie System-Builds, Testdateien und VTS-Artefakte erforderlich. Es ist zwar möglich, diese aus der Quelle zu erstellen, aber es ist einfacher, sie regelmäßig vom Stamm des Verzeichnisbaums aus zu erstellen und die Artefakte dann zum Download anzubieten.

Partner können an den folgenden Stellen auf Automatisierungsressourcen zugreifen:

• Android-Build des Partners Programmatischer Zugriff, der pro Konto gewährt wird.
• Lokales Dateisystem (oder ähnlich). Für Partner, die die Android-Builds von Partnern nicht verwenden.

Für das spätere Flashen der Geräte enthalten die Ressourcen Buildanbieter für beide Optionen, die von einem einzelnen build_provider.py ausgehen, in dem die Builds in lokalen temporären Verzeichnissen gespeichert werden.

Android-Build des Partners

Unter Android 8.1 und niedriger mussten Android-Partner die Website „Partner Android Build“ (https://partner.android.com/build) aufrufen, zu ihrem Konto wechseln und die neuesten Systembilder über die Benutzeroberfläche abrufen. Um Partnern diesen langsamen und mühsamen Prozess zu ersparen, unterstützt Android 9 das automatische Herunterladen dieser Ressourcen aus der PAB, wenn die entsprechenden Anmeldedaten angegeben werden.

Zugriff einrichten

Beim programmatischen Zugriff wird OAuth2 für Google APIs verwendet, um auf die erforderlichen RPCs zuzugreifen. Der Partner muss mit dem Standardansatz zum Generieren von OAuth2-Anmeldedaten ein Client-ID/Secret-Paar bei Google einrichten. Wenn die PartnerAndroidBuildClient zum ersten Mal auf dieses Geheimnis verweist, wird ein Browserfenster geöffnet, in dem sich der Nutzer in seinem Google-Konto anmelden kann. Dadurch werden die für den weiteren Ablauf erforderlichen OAuth2-Anmeldedaten generiert. Die Anmeldedaten (Zugriffstoken und Aktualisierungstoken) werden lokal gespeichert. Das bedeutet, dass sich Partner nur einmal anmelden müssen.

POST-Anfrage für URL

Wenn du auf einen Ressourcenlink in PAB klickst, wird eine POST-Anfrage mit den erforderlichen Daten für diese Ressource gesendet. Dazu gehören:

• build id, build target
• Ressourcenname
• branch
• Name des Release-Kandidaten und ob es sich um einen internen Build handelt

Die POST-Anfrage wird von der downloadBuildArtifact-Methode des buildsvc-RPC empfangen, die eine URL zurückgibt, mit der auf die Ressource zugegriffen werden kann.

• Bei Clockwork Companion-APK-Ressourcen ist die URL eine lesbare URL, die auf der PAB gehostet wird. Sie ist authentifiziert und kann mit den entsprechenden OAuth2-Anmeldedaten aufgerufen werden.
• Bei anderen Ressourcen ist die URL eine lange, nicht geschützte URL aus der internen Android Build API, die nach fünf Minuten abläuft.

URL abrufen

Um Cross-Site-Request-Forgery zu vermeiden, muss für die buildsvc-RPC ein XSRF-Token mit den anderen Parametern gesendet werden. Dieses Token erhöht zwar die Sicherheit, erschwert aber auch den programmatischen Zugriff, da das Token (das nur im JavaScript der PAB-Seite verfügbar ist) jetzt auch für den Zugriff erforderlich ist.

Um dieses Problem zu vermeiden, wurde in Android 9 das URL-Benennungsschema für alle Dateien (nicht nur APKs) neu gestaltet, sodass für den Zugriff auf Artefaktlisten und Artefakt-URLs vorhersehbare URL-Namen verwendet werden. Die PAB verwendet jetzt ein praktisches URL-Format, mit dem Partner Ressourcen herunterladen können. HC-Scripts können diese APKs ganz einfach herunterladen, da das URL-Format bekannt ist. HC kann die XSRF-/Cookie-Probleme umgehen, da es die buildsvc RPC nicht benötigt.

Lokales Dateisystem

Wenn ein Verzeichnis mit einer Liste (oder ZIP-Datei) von Artefakten angegeben ist, legt der Buildanbieter die relevanten Bilder anhand des Inhalts des Verzeichnisses fest. Mit dem Tool gsutil können Sie Dateien aus Google Cloud Storage in ein lokales Verzeichnis kopieren.

Flash-Builds

Nachdem die neuesten Geräte-Images auf den Host heruntergeladen wurden, müssen diese Images auf die Geräte geflasht werden. Dazu werden die Standardbefehle adb und fastboot sowie Python-Unterprozesse verwendet, die auf den von den Build-Anbietern gespeicherten temporären Dateipfaden basieren.

Unterstützte Aktionen:

• Nur GSI flashen
• Überspielen einzelner Images vom Hauptsystem (z.B. fastboot flash boot boot.img)
• Alle Images werden über das Hauptsystem geflasht. Beispiel:
  • fastboot flashall (mit dem integrierten Dienstprogramm flashall)
  • fastboot flash (einen nach dem anderen)

Tests ausführen

Unter Android 9 unterstützt die VTS-Infrastruktur für automatisierte Tests nur den TradeFed-Test-Harness. Sie kann jedoch in Zukunft um die Unterstützung anderer Harnesses erweitert werden.

Nachdem die Geräte vorbereitet sind, können Sie mit einer der folgenden Optionen Tests ausführen:

• Wenn Sie TradeFed lokal verwenden, verwenden Sie den Befehl test auf dem Hostcontroller. Dieser nimmt den Namen eines VTS-Testplans (z. B. vts-selftest) an und führt den Test aus.
• Wenn Sie einen TradeFed-Cluster verwenden, der optional mit MTT verbunden ist, verwenden Sie den Befehl lease in der Hostcontroller-Konsole. Dieser sucht nach nicht abgeschlossenen Tests.

Wenn Sie TradeFedCluster verwenden, wird TradeFed lokal als Remote-Manager ausgeführt. Andernfalls werden die Tests über Python-Unterprozesse aufgerufen.

Ergebnisse melden

Testergebnisse werden von VtsMultiDeviceTest automatisch an einige VTS-Dashboard-Projekte gesendet.