Sprawdzanie możliwości testowania HAL

Pakiet testów dostawcy (VTS) na Androida 9 obsługuje metodę czasu wykonywania, która umożliwia używanie 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 w przypadku wszystkich urządzeń wprowadzonych na rynek z Androidem 8.0 lub nowszym. Nie wszystkie testy VTS mają jednak zastosowanie do wszystkich urządzeń docelowych. Na 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ń ma ten sam układ SoC i obraz dostawcy, ale 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ą kompatybilność między ramami a partycjami dostawcy. Te testy muszą być przeprowadzane (i przechodzone) na urządzeniach z Androidem 8.0 lub nowszym.
• Testy niezgodności pomagają dostawcom poprawić jakość produktów (wydajność, testowanie nieprawidłowych danych 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.

Określanie obsługiwanych warstw HAL

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

• /system/compatibility_matrix.xml. Zgłasza instancje HAL wymagane 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 HAL jest bezwzględnie wymagany przez platformę.
  • 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 konfiguracji version dla tego samego wpisu, co oznacza, że platforma może współpracować z różnymi wersjami.
  • version1.0-1 oznacza, że platforma może działać z najniższą wersją 1.0 i nie wymaga wersji wyższej niż 1.1.
• Urządzenie manifest.xml Deklaruje instancje HAL dostarczone 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 1 versionkonfiguracjęversion1.2 dla wpisu, oznacza to, ż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 zarejestrowanych w hwservicemanager. Przykład:

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

  
  lshal wyświetla też wszystkie interfejsy HAL 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 udostępniane przez urządzenie. Proces podejmowania decyzji:

Testy niezgodności

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

Znajdź plik manifestu sprzedawcy

VTS sprawdza obecność pliku dostawcy manifest.xml w tych miejscach w tej kolejności:

1. /vendor/etc/vintf/manifest.xml + plik manifestu ODM (jeśli ten sam HAL jest zdefiniowany w obu miejscach, plik manifestu ODM zastępuje ten w /vendor/etc/vintf/manifest.xml)
2. /vendor/etc/vintf/manifest.xml
3. Plik ODM manifest.xml wczytany 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

Sprawdzanie możliwości testowania VTS

vts_testibility_checker to plik binarny spakowany z VTS, który jest używany przez platformę testową VTS w czasie działania do określania, czy dany test HAL jest testowalny. Opiera się na bibliotece libvintf do wczytywania i parsowania pliku manifestu dostawcy oraz implementuje 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 zgodności:

  vts_testability_check -b <bitness>  <hal@version>

Dane wyjściowe vts_testability_check mają następujący format JSON:

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

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

Aby określić, do których interfejsów HAL mają dostęp testy VTS, upewnij się, że każdy test interfejsu HAL korzysta z VtsHalHidlTargetTestEnvBaseszablonuVtsHalHidlTargetTestEnvBase do rejestrowania interfejsów HAL, do których uzyskuje dostęp. Platforma testowa VTS może następnie wyodrębnić zarejestrowane interfejsy HAL podczas wstępnego przetwarzania testu.

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