Sprawdzenie testowalności HAL

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:

1. /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 )
2. /vendor/etc/vintf/manifest.xml
3. Plik manifest.xml ODM, ładowany z następujących plików w następującej 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

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 .)