Sprawdzanie możliwości testowania HAL

Pakiet VTS (Vendor Test Suite) w Androidzie 9 obsługuje metodę środowiska wykonawczego, która umożliwia używanie konfiguracji urządzenia do określania, które testy VTS należy pominąć w przypadku danego urządzenia.

Elastyczność testów VTS

Od Androida 8.0 testy VTS są wymagane w przypadku wszystkich urządzeń, które zostały wprowadzone na rynek z Androidem 8.0 lub nowszym. Nie wszystkie testy VTS dotyczą jednak wszystkich urządzeń. Przykład:

• Jeśli konkretne urządzenie nie obsługuje testowego HAL-u (np. IR), VTS nie musi uruchamiać testów tego HAL-u na tym urządzeniu.
• Jeśli kilka urządzeń korzysta z tego samego SoC i obrazu dostawcy, ale ma różne funkcje sprzętowe, VTS musi określić, czy test powinien zostać uruchomiony, czy pominięty w przypadku konkretnego urządzenia.

Typy testów VTS

VTS obejmuje te typy testów:

• Testy zgodności zapewniają zgodność między partycjami platformy i dostawcy. Te testy muszą zostać uruchomione (i zakończyć się powodzeniem) na urządzeniach, które zostały wprowadzone na rynek z Androidem 8.0 lub nowszym.
• Testy**niezgodności** pomagają dostawcom poprawić jakość produktu (wydajność, fuzzing 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 do. Testy uruchamiane w ramach planu VTS są uważane za testy zgodności.

Określanie obsługiwanych HAL-ów

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

• /system/compatibility_matrix.xml. Zawiera informacje o instancjach HAL-u wymaganych przez framework. 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 HAL jest bezwzględnie wymagany przez framework.
  • Plik może zawierać wiele wpisów dotyczących tego samego HAL-u (o tej samej nazwie) ale z różnymi wersjami i interfejsami.
  • Plik może zawierać wiele version konfiguracji dla tego samego wpisu, co oznacza, że framework 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 urządzenia. Zawiera informacje o instancjach HAL-u 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 dotyczących tego samego HAL-u (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 usługach HAL-u zarejestrowanych w hwservicemanager. Przykład:

  android.hardware.vibrator@1.0::IVibrator/default

  
  lshal wyświetla też wszystkie HAL-e z implementacjami passthrough (czyli mają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 korzysta z manifestu dostawcy, aby określić (i przetestować) wszystkie instancje HAL-u dostarczone przez urządzenie. Przebieg decyzji:

Testy niezgodności

W przypadku testów niezgodności VTS korzysta z manifestu dostawcy i lshal danych wyjściowych, aby określić (i przetestować) eksperymentalne HAL-e, które nie są zadeklarowane w pliku manifest.xml. Przebieg decyzji:

Znajdowanie manifestu dostawcy

VTS sprawdza plik manifest.xml dostawcy w tych miejscach w tej kolejności:

1. /vendor/etc/vintf/manifest.xml + manifest ODM (jeśli ten sam HAL jest zdefiniowany w obu miejscach, manifest ODM zastępuje ten w /vendor/etc/vintf/manifest.xml)
2. /vendor/etc/vintf/manifest.xml
3. Plik manifest.xml ODM wczytywany z tych plików w tej kolejności:
   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

Kontroler możliwości testowania VTS

vts_testibility_checker to plik binarny dołączony do VTS, który jest używany przez framework testowy VTS w środowisku wykonawczym do określania, czy dany test HAL-u jest możliwy do przeprowadzenia. Jest on oparty na libvintf aby wczytywać i analizować plik manifestu dostawcy, oraz implementuje przebieg 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 mają ten format JSON:

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

Określanie HAL-ów, do których uzyskano dostęp

Aby określić, do których HAL-ów uzyskują dostęp testy VTS, upewnij się, że każdy test HAL-u używa VtsHalHidlTargetTestEnvBase szablonu do rejestrowania HAL-ów, do których uzyskano dostęp w teście. Framework testowy VTS może następnie 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 HAL jest tu zdefiniowany, VTS powinien go przetestować. (W przypadku usług HAL-u dostarczanych przez system (np. graphics.composer/vr) HAL-e są deklarowane w /system/manifest.xml.)