Test możliwości testowania HAL

Android 9 Vendor Test Suite (VTS) obsługuje metoda w czasie działania do używania konfiguracji urządzenia do wskazywania testów VTS należy pominąć w przypadku tego urządzenia docelowego.

Elastyczność testów VTS

Od Androida 8.0 testy VTS są wymagane w przypadku wszystkich urządzeń uruchamianych z Android 8.0 lub nowszy. Jednak nie wszystkie testy VTS dotyczą wszystkich urządzeń celów. Na przykład:

• Jeśli dane urządzenie nie obsługuje testowego interfejsu HAL (np.podczerwień), VTS je obsługuje. nie muszą przeprowadzać testów HAL na urządzeniu docelowym.
• Jeśli kilka urządzeń używa tego samego obrazu układu SOC i obrazu dostawcy, ale różnych funkcji sprzętu, VTS musi określić, czy powinno być wykonywane lub pomijane w przypadku konkretnego urządzenia docelowego.

Typy testów VTS

VTS obejmuje te typy testów:

• Testy zgodności zapewniają zgodność między platformą i partycje dostawcy. Te testy należy przeprowadzić (i zaakceptować) urządzeń z Androidem 8.0 lub nowszym.
• Testy niezgodności z zasadami pomagają dostawcom ulepszać produkty i usługi jej jakości (wydajność, rozmazywanie itd.). Te testy są opcjonalne dla dostawców.

To, czy test jest testem zgodności czy nie, zależy od tego, do którego abonamentu należy do. Testy uruchamiane z użyciem Plan VTS jest uważany za testy zgodności.

Określanie obsługiwanych HAL

Usługa VTS może używać tych plików do określenia, czy urządzenie docelowe obsługuje konkretna HAL:

• /system/compatibility_matrix.xml Żąda instancji HAL wymagane przez zasady. 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 ściśle wymagane przez zasady.
  • Plik może zawierać wiele pozycji dla tej samej listy HAL (o tej samej nazwie) ale z różnymi wersjami i interfejsami.
  • Plik może zawierać wiele konfiguracji version dla ten sam wpis, który wskazuje, że platforma może działać z różnymi wersjami.
  • version1.0-1 oznacza, że platforma może działać z najniższej wersji 1.0 i nie wymaga wersji wyższej niż 1.1.
• Urządzenie manifest.xml. Żąda instancji HAL podanych przez dostawcy. 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 pozycji dla tej samej listy 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 pokazuje informacje o czasie działania aplikacji usługi HAL zarejestrowane w hwservicemanager. Przykład:

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

  
  lshal pokazuje również wszystkie HAL, które dzięki przekazywaniu (np.odpowiedni plik -impl.so jest urządzenia). 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ć (oraz test) wszystkich instancji HAL udostępnionych przez urządzenie. Proces podejmowania decyzji:

Rysunek 1. Kontrola możliwości przeprowadzenia testów zgodności VTS

.

Testy zgodności

W przypadku testów zgodności VTS korzysta z pliku manifestu dostawcy, Dane wyjściowe funkcji lshal w celu określenia (i przetestowania) eksperymentalnych list HAL, które nie objęte roszczeniem w pliku manifest.xml. Proces podejmowania decyzji:

Rysunek 2. Kontrola testowania pod kątem niezgodności VTS testy

.

Znajdź plik manifestu dostawcy

VTS szuka pliku manifest.xml dostawcy w: miejsca w następującej kolejności:

1. /vendor/etc/vintf/manifest.xml + plik manifestu ODM (jeśli ta sama wartość HAL jest zdefiniowany w obu miejscach, plik manifestu ODM zastępuje /vendor/etc/vintf/manifest.xml)
2. /vendor/etc/vintf/manifest.xml
3. Plik ODM manifest.xml, wczytany z następujących plików 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 możliwości testowania VTS

vts_testibility_checker to plik binarny spakowany z VTS i używany przez Platforma testowa VTS w czasie działania pozwalająca określić, czy dany test HAL jest pod kątem możliwości przetestowania, czy też nie. Jest oparta na danych libvintf do wczytywania i analizy pliku manifestu dostawcy oraz wdrożenia procesu decyzyjnego opisane w poprzedniej sekcji.

Aby użyć aplikacji vts_testability_check:

• Aby przeprowadzić test zgodności:

  vts_testability_check -c -b <bitness>  <hal@version>
  

• W przypadku testu niezgodności:

  vts_testability_check -b <bitness>  <hal@version>
  

W danych wyjściowych funkcji vts_testability_check używany jest następujący plik JSON format:

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

Określanie, do których dostępu HAL uzyskuje dostęp

Aby określić, do których kont HAL używane są testy VTS, zadbaj o to, aby każdy test HAL korzysta z funkcji VtsHalHidlTargetTestEnvBase szablon do zarejestrowania interfejsów HAL, do których dostęp jest uzyskiwany w teście. Testowanie VTS platforma może następnie wyodrębniać zarejestrowane HAL podczas wstępnego przetwarzania testu.

W przypadku testów zgodności możesz też sprawdzić: /system/etc/vintf/manifest.xml Jeśli zdefiniowano tutaj wartość HAL, VTS należy go przetestować. W przypadku usług HAL świadczonych w systemie (np. graphics.composer/vr), wartości HAL są zadeklarowane w polu /system/manifest.xml).