Ab dem 27. März 2025 empfehlen wir, android-latest-release anstelle von aosp-main zu verwenden, um AOSP zu erstellen und Beiträge dazu zu leisten. Weitere Informationen finden Sie unter Änderungen am AOSP.
Hostcontroller-Architektur
Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Die Architektur des VTS-Test-Frameworks ist in den cloudbasierten Testbereitstellungsdienst eingebunden. Ein VTS-Hostcontroller wird auf einem Hostcomputer ausgeführt und steuert eine Test-Harness-Instanz (z. B. Tradefed), wie unten dargestellt:
Abbildung 1: VTS-Hostcontrollerarchitektur
Der Controller ruft Befehle von einem Cluster-Commander ab, der als Google App Engine-Instanz (GAE) ausgeführt wird, und leitet Befehle und Antworten zwischen dem Cluster-Commander und der Test-Harness-Instanz weiter.
Diese Architektur bietet folgende Vorteile:
- Da es von jeder Test-Harness-Instanz entkoppelt ist, kann es verschiedene Arten von Test-Harnesses steuern und ist robuster. Das alternative Design (Einbetten der Hoststeuerungslogik in einen Test-Harness) verhindert nicht, dass Fehler weitergegeben werden.
- Da er ein pullbasiertes C&C-Modell (Command-and-Control) verwendet, kann er mit verschiedenen Arten von cloudbasierten Cluster-Commandern sowie Hosts hinter einer Firewall (für Ingress-Verbindungen) verwendet werden. Das alternative Design (pushbasiertes C&C-Modell) ermöglicht es einem Cloud-Commander möglicherweise nicht, auf Hostcontroller-Instanzen zuzugreifen, die auf Hostcomputern in einem privaten Netzwerk vorhanden sind.
Alle Inhalte und Codebeispiele auf dieser Seite unterliegen den Lizenzen wie im Abschnitt Inhaltslizenz beschrieben. Java und OpenJDK sind Marken oder eingetragene Marken von Oracle und/oder seinen Tochtergesellschaften.
Zuletzt aktualisiert: 2025-07-27 (UTC).
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Benötigte Informationen nicht gefunden","missingTheInformationINeed","thumb-down"],["Zu umständlich/zu viele Schritte","tooComplicatedTooManySteps","thumb-down"],["Nicht mehr aktuell","outOfDate","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Problem mit Beispielen/Code","samplesCodeIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-07-27 (UTC)."],[],[],null,["# Host controller architecture\n\nThe architecture of VTS test framework integrates with its cloud-based test\nserving service. A VTS host controller runs on a host machine and controls a\ntest harness (for example, Tradefed) instance as shown below:\n\n\n**Figure 1.** VTS host controller architecture.\n\n\nThe controller pulls commands from a cluster commander running as a Google App\nEngine (GAE) instance, then relays commands and responses between its cluster\ncommander and the test harness instance.\n\nThis architecture includes the following advantages:\n\n- Because it's **decoupled from any test harness instance**, it can control different types of test harnesses and is more robust. The alternative design (embedding the host control logic in a test harness) does not block errors from propagating.\n- Because it uses a **pull-based command-and-control (C\\&C)\n model**, it can work with different types of cloud-side cluster commanders as well as hosts that exist behind a firewall (for ingress connections). The alternative design (push-based C\\&C model) might not allow a cloud commander to access host controller instances that exist on host computers in a private network."]]
