A partire dal 27 marzo 2025, ti consigliamo di utilizzare android-latest-release anziché aosp-main per compilare e contribuire ad AOSP. Per ulteriori informazioni, vedi Modifiche ad AOSP.
Architettura del controller host
Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
L'architettura del framework di test VTS si integra con il servizio di pubblicazione dei test basato su cloud. Un controller host VTS viene eseguito su una macchina host e controlla un'istanza di test harness (ad esempio Tradefed) come mostrato di seguito:
Figura 1. Architettura del controller host VTS.
Il controller estrae i comandi da un cluster commander in esecuzione come istanza Google App Engine (GAE), quindi inoltra i comandi e le risposte tra il cluster commander e l'istanza del test harness.
Questa architettura offre i seguenti vantaggi:
- Poiché è scollegato da qualsiasi istanza di test harness,
può controllare diversi tipi di test harness ed è più affidabile. Il design alternativo (incorporazione della logica di controllo dell'host in un test harness) non blocca la propagazione degli errori.
- Poiché utilizza un modello di controllo e comando (C&C) basato su pull, può funzionare con diversi tipi di comandi di cluster lato cloud e con host che si trovano dietro un firewall (per le connessioni in entrata). Il design alternativo (modello C&C basato su push) potrebbe non consentire a un cloud commander di accedere alle istanze del controller host esistenti sui computer host di una rete privata.
I campioni di contenuti e codice in questa pagina sono soggetti alle licenze descritte nella Licenza per i contenuti. Java e OpenJDK sono marchi o marchi registrati di Oracle e/o delle sue società consociate.
Ultimo aggiornamento 2025-07-27 UTC.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Mancano le informazioni di cui ho bisogno","missingTheInformationINeed","thumb-down"],["Troppo complicato/troppi passaggi","tooComplicatedTooManySteps","thumb-down"],["Obsoleti","outOfDate","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Problema relativo a esempi/codice","samplesCodeIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 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."]]
