Ogólna struktura konfiguracji modułów jest podobna do zwykłej konfiguracji Tradefed XML, ale z pewnymi ograniczeniami wynikającymi z faktu, że działają one jako część pakietu.
Lista dozwolonych tagów
AndroidTest.xml lub szerzej konfiguracja modułu może zawierać tylko następujące tagi XML: target_preparer , multi_target_preparer , test i metrics_collector .
Chociaż ta lista wygląda na restrykcyjną, pozwala precyzyjnie zdefiniować potrzeby konfiguracji modułu testowego i test do uruchomienia.
UWAGA: Zobacz konfigurację Tradefed XML , jeśli potrzebujesz odświeżenia różnych tagów.
Obiekty takie jak build_provider lub result_reporter zgłoszą wyjątek ConfigurationException w przypadku próby uruchomienia z wnętrza konfiguracji modułu. Ma to na celu uniknięcie oczekiwania, że te obiekty rzeczywiście wykonują jakieś zadanie z poziomu modułu.
Przykładowa konfiguracja modułu
<configuration description="Config for CTS Gesture test cases">
<option name="test-suite-tag" value="cts" />
<target_preparer class="com.android.tradefed.targetprep.suite.SuiteApkInstaller">
<option name="cleanup-apks" value="true" />
<option name="test-file-name" value="CtsGestureTestCases.apk" />
</target_preparer>
<test class="com.android.tradefed.testtype.AndroidJUnitTest" >
<option name="package" value="android.gesture.cts" />
<option name="runtime-hint" value="10m50s" />
</test>
</configuration>
Ta konfiguracja opisuje test, który wymaga zainstalowania CtsGestureTestCases.apk i uruchomi oprzyrządowanie względem pakietu android.gesture.cts .
Specjalny przypadek tagu metrics_collector
metrics_collector jest dozwolony, ale ograniczony do klasy FilePullerLogCollector w celu określenia danego pliku lub katalogu, który ma zostać pobrany i zarejestrowany dla modułu. Jest to przydatne, jeśli zostawiasz dzienniki w określonej lokalizacji i chcesz je automatycznie odzyskać.
Przykładowa konfiguracja:
<configuration description="Config for CTS UI Rendering test cases">
<target_preparer class="com.android.tradefed.targetprep.suite.SuiteApkInstaller">
<option name="cleanup-apks" value="true" />
<option name="test-file-name" value="CtsUiRenderingTestCases.apk" />
</target_preparer>
<test class="com.android.tradefed.testtype.AndroidJUnitTest" >
<option name="package" value="android.uirendering.cts" />
<option name="runtime-hint" value="11m55s" />
<option name="runner" value="android.uirendering.cts.runner.UiRenderingRunner" />
<option name="isolated-storage" value="false" />
</test>
<!-- Collect the files in the dump directory for debugging -->
<metrics_collector class="com.android.tradefed.device.metric.FilePullerLogCollector">
<option name="directory-keys" value="/sdcard/UiRenderingCaptures" />
<option name="collect-on-run-ended-only" value="true" />
</metrics_collector>
</configuration>
A co z informacjami o kompilacji lub plikami do pobrania?
Definicja dozwolonych tagów może dawać błędne wrażenie, że moduł nie otrzyma żadnych informacji o kompilacji. To nie jest prawda .
Informacje o kompilacji pochodzą z konfiguracji na poziomie pakietu i będą współużytkowane przez wszystkie moduły pakietu. Pozwala to na pojedynczą konfigurację najwyższego poziomu dla pakietu w celu uruchomienia wszystkich modułów wchodzących w skład pakietu.
Na przykład, zamiast każdego modułu Compatibility Test Suite (CTS) indywidualnie sprawdzać informacje o urządzeniach, typach itp., konfiguracja na poziomie pakietu CTS ( cts.xml ) robi to raz, a każdy moduł otrzyma te informacje, jeśli o to poprosi.
Aby obiekty w module otrzymały informacje o kompilacji, muszą zrobić to samo, co w zwykłej konfiguracji Tradefed: zaimplementować interfejs IBuildReceiver , aby otrzymać IBuildInfo . Zobacz testowanie z urządzeniem , aby uzyskać więcej informacji.
Pola metadanych
Duża liczba modułów testowych zawiera pewne specyfikacje metadata , z których każdy ma inny cel.
Przykład:
<option name="config-descriptor:metadata" key="component" value="framework" />
<option name="config-descriptor:metadata" key="parameter" value="instant_app" />
<option name="config-descriptor:metadata" key="parameter" value="multi_abi" />
<option name="config-descriptor:metadata" key="parameter" value="secondary_user" />
Część
Metadane component opisują ogólny komponent Androida, który moduł zamierza przetestować. Nie ma to bezpośredniego wpływu na wykonanie testu; jest używany głównie do celów organizacyjnych.
Aktualna lista dozwolonych składników dla CTS jest dostępna w CtsConfigLoadingTest . Ten test kończy się niepowodzeniem podczas wstępnego przesyłania, jeśli do modułu CTS zostanie dodany nieistniejący komponent.
Uruchomienie pakietu można filtrować na podstawie składników przy użyciu module-metadata-include-filter i module-metadata-exclude-filter .
Przykład:
--module-metadata-include-filter component framework
Ten przykład uruchamia tylko moduł testowy z adnotacją komponentu framework .
Parametr
Metadane parameter mają charakter informacyjny i wpływają na wykonanie testu. Określa, do którego trybu Androida odnosi się moduł testowy. W takim przypadku tryby są ograniczone do zaawansowanych trybów Androida, takich jak instant apps , secondary users lub different abis .
Podczas uruchamiania pakietu, jeśli tryb ma zastosowanie do testu, na podstawie tego trybu tworzonych jest kilka odmian modułu testowego. Każda odmiana przeprowadza podobne testy, ale w innych trybach.
-
instant_app: utwórz odmianę testów, które instalują pliki APK jako aplikacje błyskawiczne. -
multi_abi: Utwórz odmianę testów dla każdego ABI obsługiwanego przez urządzenie. -
secondary_user: utwórz odmianę testów, które instalują pliki APK i uruchamiają testy jako użytkownik dodatkowy.