Pakiet testowy dostawcy systemu Android 9 (VTS) obsługuje metodę uruchomieniową umożliwiającą wykorzystanie konfiguracji urządzenia do określenia, które testy VTS należy pominąć w przypadku tego urządzenia docelowego.
Elastyczność testów VTS
Od wersji Androida 8.0 testy VTS są wymagane dla wszystkich urządzeń z systemem Android 8.0 i nowszym. Jednak nie wszystkie testy VTS dotyczą wszystkich urządzeń docelowych. Na przykład:
- Jeśli określone urządzenie nie obsługuje testującej warstwy HAL (np. IR), VTS nie musi przeprowadzać testów tego testu HAL na tym docelowym urządzeniu.
- Jeśli kilka urządzeń ma ten sam SoC i obraz dostawcy, ale ma różne funkcjonalności sprzętowe, VTS musi określić, czy dla konkretnego urządzenia docelowego należy przeprowadzić test, czy też go pominąć.
Rodzaje testów VTS
VTS obejmuje następujące typy testów:
- Testy zgodności zapewniają zgodność pomiędzy platformą i partycjami dostawcy. Testy te należy uruchomić (i zaliczyć) na urządzeniach z systemem Android 8.0 lub nowszym.
- Testy niezgodności pomagają dostawcom poprawić jakość produktu (wydajność/zamglenie itp.). Testy te są opcjonalne dla dostawców.
To, czy test jest testem zgodności, zależy od planu, do którego należy. Testy przeprowadzane w ramach planu VTS są uważane za testy zgodności.
Określ obsługiwane warstwy HAL
VTS może użyć następujących plików, aby określić, czy urządzenie docelowe obsługuje określoną warstwę HAL:
-
/system/compatibility_matrix.xml
. Żąda instancji HAL wymaganych przez platformę. Przykład:<hal format="hidl" optional="true"> <name>android.hardware.vibrator</name> <version>1.0-1</version> <interface> <name>IVibrator</name> <instance>default</instance> </interface> </hal>
-
optional
atrybut wskazuje, czy warstwa HAL jest ściśle wymagana przez platformę. - Plik może zawierać wiele wpisów dla tej samej warstwy HAL (o tej samej nazwie), ale z inną wersją i interfejsem.
- Plik może zawierać wiele konfiguracji
version
tego samego wpisu, co wskazuje, że platforma może współpracować z różnymi wersjami. -
version1.0-1
oznacza, że framework może współpracować z najniższą wersją 1.0 i nie wymaga wersji wyższej niż 1.1.
-
-
manifest.xml
. Żąda instancji HAL dostarczonych przez dostawcę. Przykład:<hal format="hidl"> <name>android.hardware.vibrator</name> <transport>hwbinder</transport> <version>1.2</version> <interface> <name>IVibrator</name> <instance>default</instance> </interface> </hal>
- Plik może zawierać wiele wpisów dla tej samej warstwy HAL (o tej samej nazwie), ale z inną wersją i interfejsem.
- Jeśli plik zawiera tylko konfigurację jednej
version
wpisu,version1.2
oznacza, że dostawca obsługuje wszystkie wersje od 1.0~1.2.
- lshal . Narzędzie na urządzeniu wyświetlające informacje o czasie wykonywania usług HAL zarejestrowanych w
hwservicemanager
. Przykład:android.hardware.vibrator@1.0::IVibrator/default
lshal
pokazuje także wszystkie warstwy HAL z implementacjami przekazywania (tj. posiadające odpowiedni plik-impl.so
na urządzeniu). Przykład:android.hardware.nfc@1.0::I*/* (/vendor/lib/hw/) android.hardware.nfc@1.0::I*/* (/vendor/lib64/hw/)
Testy zgodności
W przypadku testów zgodności VTS opiera się na manifeście dostawcy w celu określenia (i przetestowania) wszystkich instancji HAL dostarczonych przez urządzenie. Przepływ decyzji:
Testy niezgodności
W przypadku testów niezgodności VTS opiera się na manifeście dostawcy i wynikach lshal
w celu określenia (i przetestowania) eksperymentalnych warstw HAL, które nie są uwzględnione w pliku manifest.xml
. Przepływ decyzji:
Znajdź manifest dostawcy
VTS sprawdza plik manifest.xml
dostawcy w następujących miejscach w następującej kolejności:
-
/vendor/etc/vintf/manifest.xml
+ manifest ODM (Jeśli w obu miejscach zdefiniowano tę samą warstwę HAL, manifest ODM zastępuje manifest w/vendor/etc/vintf/manifest.xml
) -
/vendor/etc/vintf/manifest.xml
- Plik
manifest.xml
ODM, ładowany z następujących plików w następującej kolejności:-
/odm/etc/vintf/manifest_$(ro.boot.product.hardware.sku).xml
-
/odm/etc/vintf/manifest.xml
-
/odm/etc/manifest_$(ro.boot.product.hardware.sku).xml
-
/odm/etc/manifest.xml
-
/vendor/manifest.xml
-
Narzędzie do sprawdzania testowalności VTS
vts_testibility_checker
to plik binarny spakowany z VTS i używany przez platformę testową VTS w czasie wykonywania w celu ustalenia, czy dany test HAL nadaje się do testowania, czy nie. Opiera się na libvintf
do ładowania i analizowania pliku manifestu dostawcy oraz implementuje przepływ decyzji opisany w poprzedniej sekcji.
Aby użyć vts_testability_check
:
- W przypadku testu zgodności:
vts_testability_check -c -b <bitness> <hal@version>
- W przypadku testu niezgodności:
vts_testability_check -b <bitness> <hal@version>
Dane wyjściowe vts_testability_check
wykorzystują następujący format JSON:
{testable: <True/False> Instances: <list of instance names of HAL service>}
Określ dostępne warstwy HAL
Aby określić, do których warstw HAL uzyskują dostęp testy VTS, upewnij się, że każdy test HAL korzysta z szablonu VtsHalHidlTargetTestEnvBase
w celu zarejestrowania warstw HAL, do których uzyskano dostęp w teście. Struktura testowania VTS może następnie wyodrębnić zarejestrowane warstwy HAL podczas wstępnego przetwarzania testu.
W przypadku testów zgodności możesz także sprawdzić /system/etc/vintf/manifest.xml
. Jeśli zdefiniowano tutaj warstwę HAL, VTS powinien ją przetestować. (W przypadku usług HAL udostępnianych przez system (np. graphics.composer/vr
) warstwy HAL są zadeklarowane w /system/manifest.xml
.)