Android 9 zawiera infrastrukturę pakietu testów dostawcy (VTS) do automatycznego testowania VTS, CTS lub innych testów na urządzeniach partnerów z systemem AOSP GSI. Wcześniej uruchamianie tych testów było bardzo żmudną czynnością manualną. Nowa infrastruktura testów VTS została zaprojektowana tak, aby obsługiwać automatyczne testowanie kilka razy dziennie na wielu urządzeniach.
Architektura
Infrastruktura automatycznego testowania VTS korzysta z tej architektury:
Gdy test zostanie uruchomiony, infrastruktura automatycznego testowania VTS wykonuje te czynności:
- Pobiera artefakty kompilacji i zasoby testowe z różnych lokalizacji:
- Partner Android Build (PAB). Dla GSI: VTS i kilka innych kompilacji.
- Lokalny system plików, Google Cloud Storage lub inny system kompilacji specyficzny dla danego dostawcy. Dla partnerów, którzy nie przechowują wersji w chmurze Google.
- Migawki kompilują artefakty (z urządzenia) i GSI (z AOSP) w połączonych urządzeń.
- Uruchamia testy VTS za pomocą lokalnego interfejsu TradeFed lub interfejsu TradeFed w chmurze.
- Raportuje wyniki testu w panelu VTS
Proces jest koordynowany przez kontroler hosta VTS (HC), czyli maszynę w laboratorium, która kieruje działaniem wszystkich podłączonych urządzeń będących w trakcie testowania. HC odpowiada za pobieranie najnowszych wersji, instalowanie ich na urządzeniach i uruchamianie testów (lokalnie lub za pomocą polecenia). Komunikacja odbywa się również z planistą chmury, który kieruje ruchem między planistą a instancją TradeFed (lub innym elementem) działającą na HC. Więcej informacji: kontrolera hosta, patrz sekcja Host Architektura kontrolera.
Dostawcy zasobów
Automatyczne testowanie wymaga zasobów, takich jak kompilacje systemu, pliki testowe Artefakty VTS. Chociaż można je tworzyć na podstawie źródeł, łatwiej jest je i regularnie budować je od czubka drzewa, a potem publikować artefakty do pobrania.
Partnerzy mogą uzyskać dostęp do zasobów automatyzacji w tych miejscach:
- Partner Android Build. dla każdego konta.
- Lokalny system plików (lub podobny). Dla partnerów, którzy nie używać kompilacji Androida partnera.
Zasoby do korzystania z flashowania urządzeń obejmują dostawców kompilacji dla obu opcji, rozszerzając pojedynczą usługę build_provider.py
, która przechowuje kompilacje w lokalnych katalogach tymczasowych.
Kompilacja Androida dla partnera
W przypadku wersji Androida 8.1 i starszych partnerzy Androida musieli odwiedzić stronę Partner Android Build (https://partner.android.com/build), przejść do swojego konta i pobrać najnowsze obrazy systemu za pomocą interfejsu użytkownika. Aby pomóc partnerom uniknąć tego powolnego i pracochłonnego procesu, Android 9 obsługuje automatyczne pobierz te zasoby z PAB, gdy podaj odpowiednie dane logowania.
Uzyskiwanie dostępu
Dostęp programowy korzysta z protokołu OAuth 2 w interfejsach API Google, aby uzyskać dostęp do wymaganych poleceń RPC.
Korzystanie z
standardowa
do generowania danych logowania OAuth2
identyfikator/tajny klucz klienta z Google. Gdy usługa PartnerAndroidBuildClient
po raz pierwszy odwołuje się do tego sekretu, otwiera okno przeglądarki, aby użytkownik mógł zalogować się na swoje konto Google. Generuje to dane logowania OAuth2 potrzebne do dalszych działań. Dane logowania (token dostępu i token odświeżania) są przechowywane lokalnie, co oznacza, że partnerzy muszą się zalogować tylko raz.
Żądanie POST dla adresu URL
Kliknięcie linku do zasobu w PAB powoduje wysłanie żądania POST zawierającego niezbędne dane dotyczące tego zasobu, w tym:
- identyfikator kompilacji, cel kompilacji
- nazwa zasobu
- gałąź
- nazwa wersji kandydackiej i to, czy jest to kompilacja wewnętrzna;
Żądanie POST jest odbierane przez metodę downloadBuildArtifact
wywołania RPC buildsvc
, które zwraca adres URL, którego można użyć do
uzyskać dostęp do zasobu.
- W przypadku zasobów pakietu APK aplikacji Clockwork Companion adres URL to czytelny adres URL hostowany w PAB (chroniony uwierzytelnianiem i dostępny za pomocą odpowiedniego protokołu OAuth2), dane logowania).
- W przypadku innych zasobów adres URL jest długim, niezabezpieczonym adresem URL z wewnętrznego interfejsu API Android Build (który wygasa po 5 minutach).
Pobieranie adresu URL
Aby uniknąć fałszowania żądań z innych witryn, usługa buildsvc
RPC wymaga przesłania tokena XSRF wraz z innymi parametrami. Chociaż ten token sprawia, że
bezpieczniejszym przetwarzaniem danych, utrudnia też dostęp zautomatyzowany,
(dostępny tylko w kodzie JavaScript strony PAB) jest teraz również
wymagane do uzyskania dostępu.
Aby uniknąć tego problemu, Android 9 zmienia URL
schemat nazewnictwa wszystkich plików (nie tylko plików APK) tak, by używać przewidywalnych nazw adresów URL
dostęp do list artefaktów i adresów URL artefaktów. PAB używa teraz wygodnego adresu URL
format, który umożliwia partnerom pobieranie zasobów; Skrypty Centrum pomocy można pobierać
te pliki APK, ponieważ format adresu URL jest znany, więc Centrum pomocy może pominąć
Problemy z XSRF/plikiem cookie, ponieważ nie wymagają RPC buildsvc
.
Lokalny system plików
Jeśli katalog zawiera listę artefaktów (lub plik ZIP), dostawca kompilacji ustawia odpowiednie obrazy na podstawie zawartości katalogu. Aby skopiować pliki z Google Cloud Storage do katalogu lokalnego, możesz użyć narzędzia gsutil.
Kompilacje Flash
Po pobraniu najnowszych obrazów urządzeń na hosta należy je wgrać na urządzenia. Jest to realizowane za pomocą standardowych poleceń adb
i fastboot
oraz podprocesów Pythona na podstawie ścieżek do plików tymczasowych przechowywanych przez dostawców kompilacji.
Obsługiwane działania:
- Wyświetlanie tylko GSI
- migające pojedyncze obrazy z głównego systemu (np.
fastboot flash boot boot.img
) - Flashing all images from the main system. Przykład:
fastboot flashall
(za pomocą wbudowanego narzędziaflashall
)fastboot flash
(pojedynczo)
Przeprowadzanie testów
W Androidzie 9 infrastruktura automatycznego testowania VTS obsługuje tylko testowy zestaw narzędzi TradeFed, ale w przyszłości może zostać rozszerzona, aby obsługiwać inne zestawy narzędzi.
Po przygotowaniu urządzeń możesz wywoływać testy za pomocą jednej z tych opcji:
- Jeśli korzystasz z The TradeFed lokalnie, użyj polecenia
test
na hoście kontroler, który nosi nazwę planu testów VTS (np.vts-selftest
) i przeprowadza test. - Jeśli używasz klastra TradeFed (opcjonalnie połączonego z MTT), użyj
lease
w konsoli kontrolera hosta, które szuka niezrealizowane uruchomienia testów.
Jeśli korzystasz z klastra TradeFedCluster, działa TradeFed lokalnie jako menedżer zdalny. W przeciwnym razie testy są wywoływane przy użyciu podprocesów Pythona.
Raportowanie wyników
Wyniki testów są automatycznie przekazywane do niektórych projektów panelu VTS przez
VtsMultiDeviceTest