A partir de 27 de março de 2025, recomendamos usar android-latest-release em vez de aosp-main para criar e contribuir com o AOSP. Para mais informações, consulte Mudanças no AOSP.
Arquitetura do controlador de host
Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
A arquitetura do framework de teste do VTS é integrada ao serviço de teste
baseado na nuvem. Um controlador de host do VTS é executado em uma máquina host e controla uma
instância de harness de teste (por exemplo, Tradefed), conforme mostrado abaixo:
Figura 1. Arquitetura do controlador de host do VTS.
O controlador extrai comandos de um comandante de cluster em execução como uma instância do Google App Engine (GAE) e, em seguida, transmite comandos e respostas entre o comandante do cluster e a instância do teste.
Essa arquitetura inclui as seguintes vantagens:
- Como ele é desvinculado de qualquer instância de conjunto de testes,
ele pode controlar diferentes tipos de conjuntos de testes e é mais robusto. O
design alternativo (incorporar a lógica de controle do host em um harness de teste) não
bloqueia a propagação de erros.
- Como ele usa um modelo de comando e controle (C&C)
baseado em pull, pode funcionar com diferentes tipos de comandantes de cluster
do lado da nuvem, bem como hosts que existem atrás de um firewall (para conexões
de entrada). O design alternativo (modelo de C&C baseado em push) pode não permitir
que um comandante da nuvem acesse instâncias de controlador de host que existem em computadores
host em uma rede privada.
O conteúdo e os exemplos de código nesta página estão sujeitos às licenças descritas na Licença de conteúdo. Java e OpenJDK são marcas registradas da Oracle e/ou suas afiliadas.
Última atualização 2025-07-27 UTC.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Não contém as informações de que eu preciso","missingTheInformationINeed","thumb-down"],["Muito complicado / etapas demais","tooComplicatedTooManySteps","thumb-down"],["Desatualizado","outOfDate","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Problema com as amostras / o código","samplesCodeIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 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."]]
