Android 9 include un'infrastruttura VTS (Vendor Test Suite) per i test automatici di VTS, CTS o altri test sui dispositivi partner che eseguono l'immagine di sistema generica AOSP (GSI). In precedenza, l'esecuzione di questi test era un'operazione molto manuale. La nuova infrastruttura di test VTS è progettata per supportare i test automatici più volte al giorno su più dispositivi.
Architettura
L'infrastruttura di test automatico VTS utilizza la seguente architettura:
Quando viene attivato un test, l'infrastruttura di test automatico VTS esegue le seguenti attività:
- Recupera gli elementi di build e le risorse di test da posizioni diverse:
- Partner Android Build (PAB). Per GSI, VTS e alcune altre build.
- File system locale, Google Cloud Storage o un altro sistema di compilazione specifico del fornitore. Per i partner che non archiviano le build nel cloud di Google.
- Esegue il flashing degli elementi di build (dal dispositivo) e del GSI (da AOSP) sui dispositivi connessi.
- Esegue test VTS utilizzando un TradeFed locale o un TradeFed nel cloud.
- Segnala i risultati del test nella dashboard VTS
Il processo è coordinato dal controller host VTS (HC), una macchina che stabilisce il comportamento di tutti i dispositivi connessi sottoposti a test. Il Centro assistenza è responsabile di recuperare le build più recenti, eseguirne il flashing sui dispositivi richiamare i test (in locale o tramite il comandante). Inoltre, comunica mediante Cloud Scheduler e indirizza il traffico tra Istanza TradeFed (o qualche altro cablaggio) in esecuzione sul Centro assistenza. Per maggiori dettagli su per il controller host, consulta Host dell'architettura del controller.
Fornitori di risorse
I test automatici richiedono risorse quali build di sistema, file di test Artefatti VTS. Sebbene sia possibile crearli dal codice sorgente, è più facile creali regolarmente dalla punta dell'albero e poi pubblicali per il download.
I partner possono accedere alle risorse di automazione utilizzando le seguenti posizioni:
- Build Android del partner. L'accesso programmatico concesso su una per account.
- File system locale (o simile). Per i partner che non utilizzano la build Android per i partner.
Per l'utilizzo durante il flashing dei dispositivi in un secondo momento, le risorse includono i provider di build per entrambe le opzioni, che si estendono da un singolo build_provider.py che memorizza le build in directory temporanee locali.
Partner Android Build
In Android 8.1 e versioni precedenti, i partner Android dovevano visitare la Sito web partner Android Build (https://partner.android.com/build) accedere al proprio account e recuperare le immagini di sistema più recenti tramite l'utente a riga di comando. Per aiutare i partner a evitare questo processo lento e laborioso, Android 9 include il supporto per scaricare queste risorse da PAB quando vengano fornite le credenziali appropriate.
Stabilisci l'accesso
L'accesso programmatico utilizza OAuth2 sulle API di Google per accedere alle RPC richieste.
L'utilizzo del
standard
per generare le credenziali OAuth2, il partner deve configurare
tramite ID client/segreto e Google. Quando
PartnerAndroidBuildClient punta al secret per la prima volta
volta, l'utente apre una finestra del browser in cui potrà accedere al proprio account Google.
che genera le credenziali OAuth2 necessarie per procedere. La
(token di accesso e di aggiornamento) vengono archiviate localmente, ovvero
i partner devono effettuare l'accesso una sola volta.
Richiesta POST per l'URL
Facendo clic sul link di una risorsa in PAB viene inviata una richiesta POST che include necessari per la risorsa, tra cui:
- build id, build target
- nome risorsa
- ramo
- nome del candidato della release e se il candidato è interno crea
La richiesta POST viene ricevuta con il metodo downloadBuildArtifact
dell'RPC buildsvc, che restituisce un URL utilizzabile per
per accedere alla risorsa.
- Per le risorse APK Watchwork Companion, l'URL è un URL leggibile ospitato su PAB (protetto da autenticazione e accessibile con il token OAuth2 appropriato) credenziali).
- Per le altre risorse, l'URL è lungo e non protetto dall'API Android Build interna (che scade dopo cinque minuti).
Recuperare l'URL
Per evitare la contraffazione delle richieste cross-site, l'RPC buildsvc richiede che un
token XSRF venga inviato tramite POST con gli altri parametri. Sebbene questo token renda la procedura più sicura, rende anche molto più difficile l'accesso programmatico, poiché ora il token (disponibile solo nel codice JavaScript della pagina PAB) è obbligatorio anche per l'accesso.
Per evitare questo problema, Android 9 riprogetta lo schema di denominazione degli URL per tutti i file (non solo gli APK) in modo da utilizzare nomi di URL prevedibili per accedere agli elenchi di elementi e agli URL degli elementi. Ora PAB utilizza un pratico formato URL che consente ai partner di scaricare le risorse; gli script HC possono scaricare facilmente questi APK, poiché il formato dell'URL è noto e HC può aggirare i problemi XSRF/cookie perché non ha bisogno dell'RPC buildsvc.
File system locale
Data una directory con un elenco (o file ZIP) di elementi, il provider di build imposta le immagini pertinenti in base ai contenuti della directory. Puoi utilizzare lo strumento gsutil per copiare i file da Google Cloud Storage in una directory locale.
Build di Flash
Dopo aver scaricato le immagini dispositivo più recenti sull'host, queste immagini
dei dispositivi. Per farlo, usa lo standard
i comandi adb e fastboot e i sottoprocessi Python,
in base ai percorsi dei file temporanei archiviati dai provider di build.
Azioni supportate:
- Esegui il flashing solo di GSI
- Lampeggiamento di singole immagini del sistema principale (ad es.
fastboot flash boot boot.img) - Flash di tutte le immagini dal sistema principale. Esempio:
fastboot flashall(con l'appflashallintegrata )fastboot flash(uno alla volta)
Esegui test
In Android 9, il test automatico VTS infrastruttura supporta solo il sistema di test TradeFed, ma potrebbe essere esteso per supportare altre imperfezioni in futuro.
Dopo aver preparato i dispositivi, puoi richiamare i test utilizzando una delle seguenti opzioni:
- Quando utilizzi TradeFed localmente, usa il comando
testnell'host di un controller, che prende il nome di un piano di test VTS (ad es.vts-selftest) ed esegue il test. - Quando utilizzi un cluster TradeFed (connesso facoltativamente a MTT), utilizza la classe
leasenella console del controller host, che cerca esecuzioni di test non completate.
Se utilizzi TradeFedCluster, TradeFed viene eseguito localmente come gestore remoto. In caso contrario, i test vengono richiamati utilizzando i sottoprocessi Python.
Risultati dei report
I risultati dei test vengono automaticamente segnalati in alcuni progetti della dashboard VTS tramite
VtsMultiDeviceTest.