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 określania, które testy VTS powinny zostać pominięte w przypadku danego urządzenia docelowego.

Elastyczność testów VTS

Od Androida 8.0 testy VTS są wymagane na wszystkich urządzeniach z Androidem 8.0 lub nowszym. Nie wszystkie testy VTS są jednak stosowane do wszystkich urządzeń docelowych. 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 układ 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 (skuteczność, fuzzing itp.). Testy te 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 framework wymaga interfejsu HAL.
    • 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 zawiera również wszystkie interfejsy HAL z implementacją typu passthrough (czyli z odpowiednim plikiem -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 z zasadami

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

Testy zgodności

W przypadku testów niezgodności VTS korzysta z pliku manifestu dostawcy i wyników lshal, aby określić (i przetestować) eksperymentalne interfejsy HAL, które nie zostały zadeklarowane w pliku manifest.xml. Schemat decyzji:

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 sprawdza obecność pliku manifest.xml w tych miejscach i 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 zapakowany w VTS, który jest używany przez framework testowy VTS w czasie wykonywania, aby określić, czy dany test HAL można przeprowadzić. Wykorzystuje ona funkcję libvintf do wczytywania i analizowania pliku manifestu dostawcy oraz implementuje przepływ decyzji 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ą 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 do rejestrowania interfejsów HAL, do których ma dostęp w ramach testu. Następnie framework testów VTS może wyodrębnić zarejestrowane HAL-e podczas wstępnego przetwarzania testu.

W przypadku testów zgodności możesz też sprawdzić /system/etc/vintf/manifest.xml. Jeśli tutaj zdefiniowano HAL, VTS powinien go przetestować. (W przypadku usług HAL udostępnianych przez system (np. graphics.composer/vr) interfejsy HAL są deklarowane w pliku /system/manifest.xml).