Начиная с 27 марта 2025 г. мы рекомендуем использовать android-latest-release вместо aosp-main для создания и участия в AOSP. Дополнительные сведения см. в разделе Изменения в AOSP .
Архитектура хост-контроллера
Оптимизируйте свои подборки
Сохраняйте и классифицируйте контент в соответствии со своими настройками.
Архитектура тестового фреймворка VTS интегрируется с его облачным сервисом обслуживания тестов. Хост-контроллер VTS работает на хост-машине и управляет экземпляром тестового оборудования (например, Tradefed), как показано ниже:
Рисунок 1. Архитектура хост-контроллера VTS.
Контроллер получает команды от кластерного командира, работающего как экземпляр Google App Engine (GAE), а затем передает команды и ответы между кластерным командиром и экземпляром тестовой среды.
Данная архитектура имеет следующие преимущества:
- Поскольку он отделен от любого экземпляра тестового оборудования , он может управлять различными типами тестовых оборудований и является более надежным. Альтернативный дизайн (внедрение логики управления хостом в тестовое оборудование) не блокирует распространение ошибок.
- Поскольку он использует модель командования и управления (C&C) на основе pull , он может работать с различными типами облачных кластерных командиров, а также с хостами, которые существуют за брандмауэром (для входящих подключений). Альтернативная конструкция (модель C&C на основе push) может не позволить облачному командиру получить доступ к экземплярам контроллера хоста, которые существуют на хост-компьютерах в частной сети.
Контент и образцы кода на этой странице предоставлены по лицензиям. Java и OpenJDK – это зарегистрированные товарные знаки корпорации Oracle и ее аффилированных лиц.
Последнее обновление: 2025-07-29 UTC.
[[["Прост для понимания","easyToUnderstand","thumb-up"],["Помог мне решить мою проблему","solvedMyProblem","thumb-up"],["Другое","otherUp","thumb-up"]],[["Отсутствует нужная мне информация","missingTheInformationINeed","thumb-down"],["Слишком сложен/слишком много шагов","tooComplicatedTooManySteps","thumb-down"],["Устарел","outOfDate","thumb-down"],["Проблема с переводом текста","translationIssue","thumb-down"],["Проблемы образцов/кода","samplesCodeIssue","thumb-down"],["Другое","otherDown","thumb-down"]],["Последнее обновление: 2025-07-29 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."]]
