Automatisierte Testinfrastruktur

Android 9 umfasst eine Vendor Test Suite (VTS)-Infrastruktur zum automatisierten Testen von VTS, CTS oder anderen Tests auf Partnergeräten, auf denen das AOSP Generic System Image (GSI) ausgeführt wird. Bisher war die Durchführung dieser Tests ein äußerst manueller Vorgang. Die neue VTS-Testinfrastruktur ist darauf ausgelegt, automatisierte Tests mehrmals täglich auf mehreren Geräten zu unterstützen.

Die Architektur

Die automatisierte Testinfrastruktur von VTS verwendet die folgende Architektur:

Automated test architecture

Abbildung 1. VTS-Architektur der automatisierten Testinfrastruktur

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

  1. Ruft Build-Artefakte und Testressourcen von verschiedenen Standorten ab:
    • Partner Android Build (PAB) . Für das GSI, das VTS-Framework und einige andere Builds.
    • Lokales Dateisystem, Google Cloud Storage oder ein anderes herstellerspezifisches Build-System . Für Partner, die Builds nicht in der Cloud von Google speichern.
  2. Flasht Build-Artefakte (vom Gerät) und den GSI (vom AOSP) auf das/die angeschlossene(n) Gerät(e).
  3. Führt VTS-Tests mit lokalem TradeFed oder einem TradeFed in der Cloud durch.
  4. Meldet Testergebnisse an das VTS-Dashboard

Der Prozess wird vom VTS Host Controller (HC) koordiniert, einer Maschine im Labor, die das Verhalten aller angeschlossenen Testgeräte steuert. Der HC ist dafür verantwortlich, die neuesten Builds abzurufen, sie auf Geräte zu flashen und Tests aufzurufen (entweder lokal oder über den Commander). Es kommuniziert auch mit einem Cloud-Scheduler und leitet den Datenverkehr zwischen dem Scheduler und der TradeFed-Instanz (oder einem anderen Harness), die auf dem HC läuft. Einzelheiten zum Host-Controller finden Sie unter Host-Controller-Architektur .

Ressourcenanbieter

Für automatisierte Tests sind Ressourcen wie Systembuilds, Testdateien und VTS-Artefakte erforderlich. Es ist zwar möglich, diese aus dem Quellcode zu erstellen, es ist jedoch einfacher, sie regelmäßig von „tip-of-tree“ aus zu erstellen, als die Artefakte zum Download bereitzustellen.

Partner können über die folgenden Standorte auf Automatisierungsressourcen zugreifen:

  • Partner Android Build . Programmgesteuerter Zugriff wird pro Konto gewährt.
  • Lokales Dateisystem (oder ähnlich). Für Partner, die den Partner Android Build nicht verwenden.

Zur Verwendung beim späteren Flashen der Geräte umfassen die Ressourcen Build-Anbieter für beide Optionen, die von einer einzigen build_provider.py ausgehen, die die Builds in lokalen temporären Verzeichnissen speichert.

Partner Android Build

In Android 8.1 und niedrigeren Versionen mussten Android-Partner die Partner Android Build-Website ( https://partner.android.com/build ) besuchen, zu ihrem Konto navigieren und die neuesten Systemabbilder über die Benutzeroberfläche abrufen. Um Partnern dabei zu helfen, diesen langsamen und arbeitsintensiven Prozess zu vermeiden, bietet Android 9 Unterstützung für das automatische Herunterladen dieser Ressourcen von PAB, wenn die entsprechenden Anmeldeinformationen bereitgestellt werden.

Zugang herstellen

Der programmgesteuerte Zugriff verwendet OAuth2 auf Google APIs, um auf die erforderlichen RPCs zuzugreifen. Bei Verwendung des Standardansatzes zum Generieren von OAuth2-Anmeldeinformationen muss der Partner ein Client-ID/Geheimnis-Paar bei Google einrichten. Wenn der PartnerAndroidBuildClient zum ersten Mal auf dieses Geheimnis verwiesen wird, öffnet er ein Browserfenster, in dem sich der Benutzer bei seinem Google-Konto anmelden kann, wodurch die OAuth2-Anmeldeinformationen generiert werden, die zum Fortfahren erforderlich sind. Die Anmeldeinformationen (Zugriffstoken und Aktualisierungstoken) werden lokal gespeichert, sodass sich Partner nur einmal anmelden müssen.

POST-Anfrage für URL

Durch Klicken auf einen Ressourcenlink in PAB wird eine POST-Anfrage gesendet, die die erforderlichen Daten für diese Ressource enthält, einschließlich:

  • Build-ID, Build-Ziel
  • Ressourcenname
  • Zweig
  • Name des Release-Kandidaten und ob es sich bei dem Kandidaten um einen internen Build handelt oder nicht

Die POST-Anfrage wird von der downloadBuildArtifact Methode des buildsvc RPC empfangen, die eine URL zurückgibt, die für den Zugriff auf die Ressource verwendet werden kann.

  • Für Clockwork Companion APK-Ressourcen ist die URL eine lesbare URL, die auf PAB gehostet wird (die authentifiziert ist und mit den entsprechenden OAuth2-Anmeldeinformationen zugänglich ist).
  • Für andere Ressourcen ist die URL eine lange, nicht geschützte URL der internen Android Build API (die nach fünf Minuten abläuft).

Holen Sie sich die URL

Um eine standortübergreifende Anforderungsfälschung zu vermeiden, erfordert der buildsvc RPC, dass ein XSRF-Token mit den anderen Parametern POSTed wird. Dieses Token macht den Prozess zwar sicherer, erschwert aber auch den programmgesteuerten Zugriff erheblich, 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, gestaltet Android 9 das URL-Benennungsschema für alle Dateien (nicht nur APKs) neu, um vorhersehbare URL-Namen für den Zugriff auf Artefaktlisten und Artefakt-URLs zu verwenden. Das PAB verwendet jetzt ein praktisches URL-Format, das es Partnern ermöglicht, Ressourcen herunterzuladen; HC-Skripte können diese APKs problemlos herunterladen, da das URL-Format bekannt ist, und HC kann die XSRF-/Cookie-Probleme umgehen, da es den buildsvc RPC nicht benötigt.

Lokales Dateisystem

Bei einem Verzeichnis mit einer Liste (oder ZIP-Datei) von Artefakten legt der Build-Anbieter die relevanten Bilder basierend auf dem Inhalt des Verzeichnisses fest. Mit dem gsutil- Tool können Sie Dateien aus Google Cloud Storage in ein lokales Verzeichnis kopieren.

Flash-Builds

Nachdem die neuesten Gerätebilder auf den Host heruntergeladen wurden, müssen diese Bilder auf die Geräte geflasht werden. Dies erfolgt mithilfe der Standardbefehle adb und fastboot sowie Python-Unterprozessen, basierend auf den temporären Dateipfaden, die von den Build-Anbietern gespeichert werden.

Unterstützte Aktionen:

  • Es blinkt nur die GSI
  • Einzelne Images vom Hauptsystem flashen (z. B. fastboot flash boot boot.img )
  • Flashen aller Bilder vom Hauptsystem. Beispiel:
    • fastboot flashall (mit dem integrierten flashall Dienstprogramm)
    • fastboot flash (einzeln)

Führen Sie Tests durch

In Android 9 unterstützt die automatisierte VTS-Testinfrastruktur nur die TradeFed-Testumgebung, könnte aber in Zukunft erweitert werden, um auch andere Umgebungen zu unterstützen.

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

  • Wenn Sie TradeFed lokal verwenden, verwenden Sie den test im Host-Controller, der den Namen eines VTS-Testplans (z. B. vts-selftest ) annimmt und den Test ausführt.
  • Wenn Sie einen TradeFed-Cluster (optional mit MTT verbunden) verwenden, verwenden Sie den lease Befehl in der Host-Controller-Konsole, der nach nicht erfüllten Testläufen sucht.

Bei Verwendung von TradeFedCluster wird TradeFed lokal als Remote-Manager ausgeführt. Wenn nicht, werden die Tests mithilfe von Python-Unterprozessen aufgerufen.

Ergebnisse melden

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