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 identyfikowania testów VTS, które należy pominąć na danym urządzeniu docelowym.

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. Na 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 platformą i partycje dostawcy. Te testy należy przeprowadzić (i zaakceptować) urządzeń z Androidem 8.0 lub nowszym.
• Testy niezgodności pomagają dostawcom poprawić jakość produktu (skuteczność, 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. Testy przeprowadzane w ramach planu VTS są uznawane 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 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 platforma może działać z najniższymi wartościami wersji 1.0 i nie wymaga wersji wyższej niż 1.1.
• Urządzenie manifest.xml. Rezerwuje wystąpienia HAL udostępnione 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 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 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 z przekazywaniem (np.w odniesieniu do danego środowiska wykonawczego ma odpowiedni plik -impl.so 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ć (i przetestować) wszystkie instancje HAL udostępniane przez urządzenie. Schemat decyzyjny:

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:

Znajdowanie pliku manifestu dostawcy

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

1. /vendor/etc/vintf/manifest.xml + manifest ODM (jeśli w obu miejscach zdefiniowano ten sam identyfikator 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 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>

Dane wyjściowe funkcji vts_testability_check mają format JSON:

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

Określanie adresów HAL, do których uzyskano 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.

Testy zgodności możesz też sprawdzić w /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.)