A partir del 27 de marzo de 2025, te recomendamos que uses android-latest-release en lugar de aosp-main para compilar y contribuir a AOSP. Para obtener más información, consulta Cambios en AOSP.
Arquitectura del controlador de host
Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
La arquitectura del framework de prueba de VTS se integra con su servicio de pruebas basado en la nube. Un controlador de host de VTS se ejecuta en una máquina host y controla una instancia de un conjunto de pruebas (por ejemplo, Tradefed), como se muestra a continuación:
Figura 1: Arquitectura del controlador de host de VTS
El controlador extrae comandos de un comandante de clúster que se ejecuta como una instancia de Google App Engine (GAE) y, luego, retransmite comandos y respuestas entre su comandante de clúster y la instancia del sistema de pruebas.
Esta arquitectura incluye las siguientes ventajas:
- Debido a que está separado de cualquier instancia de conjunto de pruebas, puede controlar diferentes tipos de conjuntos de pruebas y es más sólido. El diseño alternativo (incorporar la lógica de control del host en un conjunto de pruebas) no impide que se propaguen los errores.
- Debido a que usa un modelo de comando y control (C&C) basado en la extracción, puede funcionar con diferentes tipos de comandantes de clústeres del lado de la nube, así como con hosts que existen detrás de un firewall (para conexiones de entrada). Es posible que el diseño alternativo (modelo de C&C basado en push) no permita que un comandante de nube acceda a instancias de controlador de host que existen en computadoras host en una red privada.
El contenido y las muestras de código que aparecen en esta página están sujetas a las licencias que se describen en la Licencia de Contenido. Java y OpenJDK son marcas registradas de Oracle o sus afiliados.
Última actualización: 2025-07-27 (UTC)
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Falta la información que necesito","missingTheInformationINeed","thumb-down"],["Muy complicado o demasiados pasos","tooComplicatedTooManySteps","thumb-down"],["Desactualizado","outOfDate","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Problema con las muestras o los códigos","samplesCodeIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 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."]]
