Test możliwości testowania HAL

Pakiet testów dostawcy (VTS) Androida 9 obsługuje metodę czasu wykonywania, która umożliwia korzystanie z konfiguracji urządzenia do identyfikowania testów VTS, które należy pominąć na danym urządzeniu docelowym.

Elastyczność testów VTS

Od Androida 8.0 testy VTS są wymagane w przypadku wszystkich urządzeń z Androidem 8.0 lub nowszym. Jednak nie wszystkie testy VTS dotyczą wszystkich urządzeń docelowych. Na przykład:

  • Jeśli konkretne urządzenie nie obsługuje testowego HAL (np. IR), VTS nie musi przeprowadzać testów tego testu HAL na tym urządzeniu docelowym.
  • Jeśli kilka urządzeń ma ten sam SoC i obraz dostawcy, ale różni się pod względem funkcjonalności sprzętowej, VTS musi określić, czy test powinien zostać uruchomiony, czy pominięty w przypadku konkretnego urządzenia docelowego.

Typy testów VTS

VTS obejmuje te typy testów:

  • Testy zgodności zapewniają zgodność między podziałem frameworku a podziałem dostawcy. Te testy muszą zostać uruchomione (i zaliczone) na urządzeniach z Androidem 8.0 lub nowszym.
  • Testy niezgodności pomagają dostawcom poprawić jakość produktów (wydajność, rozmycie itp.). Te testy są opcjonalne dla dostawców.

To, czy test jest testem zgodności, zależy od tego, do którego planu należy. Testy przeprowadzane w ramach planu VTS są uznawane za testy zgodności.

Sprawdzanie obsługiwanych HAL-i

VTS może użyć tych plików, aby określić, czy docelowe urządzenie obsługuje określony interfejs HAL:

  • /system/compatibility_matrix.xml. Zajmuje się instancjami HAL wymaganymi 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>
    • Atrybut optional wskazuje, czy platforma HAL jest wymagana przez platformę.
    • Plik może zawierać wiele wpisów dla tego samego interfejsu HAL (o tej samej nazwie), ale z różnymi wersjami i interfejsami.
    • Plik może zawierać wiele konfiguracji version dla tego samego wpisu, co oznacza, że framework może działać z różnymi wersjami.
    • version1.0-1 oznacza, że framework może działać w wersji co najmniej 1.0 i nie wymaga wersji wyższej niż 1.1.
  • Urządzenie manifest.xml. Reklamuje instancje HAL udostępnione 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 tego samego interfejsu HAL (o tej samej nazwie), ale z różnymi wersjami i interfejsami.
    • Jeśli plik zawiera tylko jedną konfigurację version dla wpisu, version1.2 oznacza, że dostawca obsługuje wszystkie wersje od 1.0 do 1.2.
  • lshal. Narzędzie na urządzeniu, które wyświetla informacje o czasie wykonywania dotyczące usług HAL zarejestrowanych w hwservicemanager. Przykład: 
    android.hardware.vibrator@1.0::IVibrator/default
    lshal pokazuje też wszystkie listy HAL w przypadku implementacji przekazywania (tzn.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 korzysta z pliku manifestu dostawcy, aby określić (i przetestować) wszystkie instancje HAL udostępniane przez urządzenie. Schemat decyzyjny:

Sprawdzanie zgodności pod kątem testowania

Rysunek 1. Sprawdzanie możliwości testowania w przypadku testów zgodności VTS

Testy niezgodności

W przypadku testów zgodności VTS korzysta z pliku manifestu dostawcy i wyników lshal, aby określić (i przetestować) eksperymentalne interfejsy HAL, których nie określono w pliku manifest.xml. Schemat decyzyjny:

Sprawdzanie możliwości testowania niezgodności

Rysunek 2. Sprawdzanie możliwości testowania w przypadku niezgodności z testami VTS

Znajdowanie pliku manifestu dostawcy

VTS szuka pliku manifest.xml dostawcy w tych miejscach w tej kolejności:

  1. /vendor/etc/vintf/manifest.xml + manifest ODM (jeśli w obu miejscach zdefiniowano ten sam adres HAL, to manifest ODM zastąpi ten w pliku /vendor/etc/vintf/manifest.xml).
  2. /vendor/etc/vintf/manifest.xml
  3. Plik ODM manifest.xml wczytany z tych plików w takim porządku:
    1. /odm/etc/vintf/manifest_$(ro.boot.product.hardware.sku).xml
    2. /odm/etc/vintf/manifest.xml
    3. /odm/etc/manifest_$(ro.boot.product.hardware.sku).xml
    4. /odm/etc/manifest.xml
    5. /vendor/manifest.xml

Sprawdzanie możliwości testowania VTS

vts_testibility_checker to plik binarny w pakiecie z VTS używany przez platformę testową VTS w czasie działania do określenia, czy dany test HAL można przetestować. Jest ono oparte na interfejsie libvintf, który wczytuje i analizuje plik manifestu dostawcy, a następnie wdraża proces decyzyjny opisany w poprzedniej sekcji.

Aby użyć aplikacji 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 funkcji vts_testability_check mają następujący format JSON: 

{testable: <True/False> Instances: <list of instance names of HAL service>}

Określanie zapytań HAL

Aby określić, do których interfejsów HAL mają dostęp testy VTS, sprawdź, czy każdy test HAL używa szablonu VtsHalHidlTargetTestEnvBase, aby zarejestrować interfejsy HAL dostępne w teście. Następnie framework testowania VTS może wyodrębnić zarejestrowane HAL-e podczas wstępnego przetwarzania testu.

Testy zgodności możesz też przeprowadzić na stronie /system/etc/vintf/manifest.xml. Jeśli zdefiniowana jest tutaj wartość HAL, usługa VTS powinna ją przetestować. (W przypadku usług HAL udostępnianych przez system (np. graphics.composer/vr) interfejsy HAL są deklarowane w pliku /system/manifest.xml).