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 testowania automatycznego VTS korzysta z tej architektury:
Po uruchomieniu testu infrastruktura automatycznego testowania VTS wykonuje te czynności:
- Pobiera artefakty kompilacji i zasoby testowe z różnych lokalizacji:
- Partner Android Build (PAB). Dotyczy frameworków GSI i VTS oraz niektórych 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.
- Flashes build artifacts (from the device) and the GSI (from AOSP) onto the connected device(s).
- Uruchamia testy VTS za pomocą lokalnej usługi TradeFed lub usługi TradeFed w chmurze.
- Przekazuje wyniki testów do 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. Zadaniem administratora głównego jest pobieranie najnowszych wersji, instalowanie ich na urządzeniach oraz 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. Szczegółowe informacje o kontrolerze hosta znajdziesz w artykule Architektura kontrolera hosta.
Dostawcy zasobów
Testowanie automatyczne wymaga zasobów takich jak kompilacje systemu, pliki testów i artefakty VTS. Chociaż można je skompilować z źródła, łatwiej jest regularnie tworzyć je z tip-of-tree, a potem publikować artefakty do pobrania.
Partnerzy mogą uzyskać dostęp do zasobów automatyzacji w tych miejscach:
- Partner Android Build. Dostęp zautomatyzowany przyznawany na poziomie konta.
- Lokalny system plików (lub podobny). W przypadku partnerów, którzy nie używają wersji Androida dla partnera.
Zasoby do korzystania z flashowania urządzeń obejmują dostawców kompilacji dla obu opcji, rozszerzając pojedynczy element build_provider.py, który 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 kłopotliwego procesu, Android 9 obsługuje automatyczne pobieranie tych zasobów z PAB, jeśli zostaną podane 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 procedur zdalnego wywoływania procedur RPC.
Aby użyć standardowego podejścia do generowania danych logowania OAuth 2, partner musi skonfigurować parę identyfikator klienta/klucz tajny w 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 do adresu URL
Kliknięcie linku do zasobu w PAB powoduje wysłanie żądania POST zawierającego niezbędne dane tego zasobu, w tym:
- build id, build target
- nazwa zasobu
- gałąź
- nazwa wersji kandydackiej i to, czy jest to kompilacja wewnętrzna;
Żądanie POST jest odbierane przez metodę downloadBuildArtifact interfejsu buildsvc RPC, która zwraca adres URL, którego można użyć do uzyskania dostępu do zasobu.
- W przypadku zasobów APK Clockwork Companion adres URL to czytelny adres URL hostowany na PAB (który jest chroniony autoryzacją i dostępny z użyciem odpowiednich danych logowania OAuth 2).
- 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).
Adres 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 zwiększa bezpieczeństwo procesu, znacznie utrudnia też dostęp programowy, ponieważ do uzyskania dostępu wymagany jest teraz token (dostępny tylko w JavaScript na stronie PAB).
Aby uniknąć tego problemu, w Androidzie 9 zmieniono schemat nazewnictwa adresów URL wszystkich plików (nie tylko plików APK) tak, aby używały przewidywalnych nazw URL do uzyskiwania dostępu do list i adresów URL artefaktów. PAB używa teraz wygodnego formatu adresu URL, który umożliwia partnerom pobieranie zasobów. Skrypty HC mogą łatwo pobierać te pliki APK, ponieważ format adresu URL jest znany, a HC może pomijać problemy związane z XSS i plikami cookie, ponieważ nie potrzebuje wywołania RPC buildsvc.
Lokalny system plików
Na podstawie katalogu z listą (lub pliku ZIP) artefaktów dostawca kompilacji ustawia odpowiednie obrazy na podstawie tego, co znajduje się w katalogu. Pliki z Google Cloud Storage możesz kopiować do katalogu lokalnego za pomocą 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:
- Aktualizacja tylko obrazu 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łać testy, korzystając z jednego z tych sposobów:
- Jeśli używasz TradeFed lokalnie, w kontrolerze hosta użyj polecenia
test, które przyjmuje nazwę planu testu VTS (np.vts-selftest) i uruchamia test. - Jeśli używasz klastra TradeFed (opcjonalnie połączonego z MTT), w konsoli kontrolera hosta użyj polecenia
lease, które sprawdza niewykonane testy.
Jeśli używasz usługi TradeFedCluster, usługa ta działa lokalnie jako menedżer zdalny. W przeciwnym razie testy są wywoływane za pomocą podprocesów Pythona.
Raportowanie wyników
Wyniki testów są automatycznie przesyłane do niektórych projektów w panelu VTS przez VtsMultiDeviceTest.