Od 27 marca 2025 r. zalecamy używanie android-latest-release zamiast aosp-main do kompilowania i wspołtworzenia AOSP. Więcej informacji znajdziesz w artykule o zmianach w AOSP.
Architektura kontrolera gospodarza
Zadbaj o dobrą organizację dzięki kolekcji
Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.
Architektura platformy testowej VTS integruje się z usługą obsługu testów działającą w chmurze. Kontroler hosta VTS działa na maszynie hosta i steruje instancją testowej platformy (np. Tradefed), jak pokazano poniżej:
Rysunek 1. Architektura kontrolera hosta VTS
Kontroler pobiera polecenia z sterownika klastra działającego jako instancja Google App Engine (GAE), a potem przekazuje polecenia i odpowiedzi między sterownikiem klastra a instancją testowego zestawu narzędzi.
Ta architektura ma następujące zalety:
- Ponieważ jest odłączony od dowolnej instancji testowej, może kontrolować różne typy testów i jest bardziej niezawodny. Alternatywna konstrukcja (osadzanie logiki sterowania hostem w ramach testowych) nie blokuje rozprzestrzeniania się błędów.
- Korzysta on z modelu poleceń i sterowania opartych na protokole pull, dzięki czemu może współpracować z różnymi typami dowódców klastrów w chmurze, a także z hostami znajdującymi się za zaporą sieciową (w przypadku połączeń przychodzących). Alternatywny projekt (model C&C oparty na push) może uniemożliwić dowódcy w chmurze dostęp do instancji kontrolera hosta, które znajdują się na komputerach hosta w sieci prywatnej.
Treść strony i umieszczone na niej fragmenty kodu podlegają licencjom opisanym w Licencji na treści. Java i OpenJDK są znakami towarowymi lub zastrzeżonymi znakami towarowymi należącymi do firmy Oracle lub jej podmiotów stowarzyszonych.
Ostatnia aktualizacja: 2025-07-27 UTC.
[[["Łatwo zrozumieć","easyToUnderstand","thumb-up"],["Rozwiązało to mój problem","solvedMyProblem","thumb-up"],["Inne","otherUp","thumb-up"]],[["Brak potrzebnych mi informacji","missingTheInformationINeed","thumb-down"],["Zbyt skomplikowane / zbyt wiele czynności do wykonania","tooComplicatedTooManySteps","thumb-down"],["Nieaktualne treści","outOfDate","thumb-down"],["Problem z tłumaczeniem","translationIssue","thumb-down"],["Problem z przykładami/kodem","samplesCodeIssue","thumb-down"],["Inne","otherDown","thumb-down"]],["Ostatnia aktualizacja: 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."]]
