HAL-Testbarkeitsprüfung

Die Android 9 Vendor Test Suite (VTS) unterstützt eine Laufzeitmethode, mit der anhand der Gerätekonfiguration ermittelt werden kann, welche VTS-Tests für das jeweilige Geräteziel übersprungen werden sollen.

VTS-Testflexibilität

Ab Android 8.0 sind VTS-Tests für alle Geräte erforderlich, die mit Android 8.0 und höher auf den Markt kommen. Allerdings gelten nicht alle VTS-Tests für alle Gerätezielwerte. Beispiel:

• Wenn ein bestimmtes Gerät keine Test-HAL (z.B. IR) unterstützt, muss VTS keine Tests für diesen HAL-Test für dieses Geräteziel ausführen.
• Wenn mehrere Geräte dasselbe SoC und dasselbe Anbieterimage verwenden, aber unterschiedliche Hardwarefunktionen haben, muss VTS ermitteln, ob ein Test ausgeführt oder übersprungen werden soll für ein bestimmtes Geräteziel.

VTS-Testtypen

VTS umfasst die folgenden Testtypen:

• Compliance-Tests sorgen für Kompatibilität zwischen Framework und Anbieterpartitionen. Diese Tests müssen auf Geräten, die mit Android 8.0 oder höher auf den Markt kommen, ausgeführt werden und bestanden werden.
• Noncompliance-Tests helfen Anbietern, die Produktqualität zu verbessern (Leistung, Fuzzing usw.). Diese Tests sind für Anbieter optional.

Ob ein Test ein Compliance-Test ist, hängt davon ab, zu welchem Plan er gehört Tests, die mit dem VTS-Plan ausgeführt werden, gelten als Compliance-Tests.

Unterstützte HALs ermitteln

VTS kann anhand der folgenden Dateien ermitteln, ob das Geräteziel eine bestimmte HAL unterstützt:

• /system/compatibility_matrix.xml: Hier werden die HAL-Instanzen deklariert, die vom Framework benötigt werden. Beispiel:

  <hal format="hidl" optional="true">
      <name>android.hardware.vibrator</name>
      <version>1.0-1</version>
      <interface>
         <name>IVibrator</name>
         <instance>default</instance>
      </interface>
  </hal>

  • Das Attribut optional gibt an, ob die HAL unbedingt vom Framework benötigt wird.
  • Die Datei kann mehrere Einträge für dieselbe HAL (mit demselben Namen) aber mit unterschiedlichen Versionen und Schnittstellen enthalten.
  • Die Datei kann mehrere version Konfigurationen für denselben Eintrag enthalten. Das bedeutet, dass das Framework mit verschiedenen Versionen verwendet werden kann.
  • version1.0-1 bedeutet, dass das Framework mit der niedrigsten Version 1.0 verwendet werden kann und keine höhere Version als 1.1 erforderlich ist.
• manifest.xml-Datei des Geräts Hier werden die HAL-Instanzen deklariert, die vom Anbieter bereitgestellt werden. Beispiel:

  <hal format="hidl">
      <name>android.hardware.vibrator</name>
      <transport>hwbinder</transport>
      <version>1.2</version>
      <interface>
          <name>IVibrator</name>
         <instance>default</instance>
      </interface>
  </hal>

  • Die Datei kann mehrere Einträge für dieselbe HAL (mit demselben Namen) aber mit unterschiedlichen Versionen und Schnittstellen enthalten.
  • Wenn die Datei nur eine einzige version Konfiguration für einen Eintrag enthält, bedeutet version1.2, dass der Anbieter alle Versionen von 1.0 bis 1.2 unterstützt.
• lshal Ein Tool auf dem Gerät, das Laufzeitinformationen zu den HAL-Diensten anzeigt, die mit dem hwservicemanager registriert sind. Beispiel:

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

  
  lshal zeigt auch alle HALs mit Passthrough Implementierungen an (d. h. mit der entsprechenden -impl.so Datei auf dem Gerät). Beispiel:

  android.hardware.nfc@1.0::I*/* (/vendor/lib/hw/)
  android.hardware.nfc@1.0::I*/* (/vendor/lib64/hw/)

Compliance-Tests

Für Compliance-Tests verwendet VTS das Anbietermanifest, um alle HAL-Instanzen zu ermitteln (und zu testen), die vom Gerät bereitgestellt werden. Entscheidungsablauf:

Noncompliance-Tests

Für Noncompliance-Tests verwendet VTS das Anbietermanifest und lshal Ausgaben, um die experimentellen HALs zu ermitteln (und zu testen), die nicht in der manifest.xml Datei deklariert sind. Entscheidungsablauf:

Anbietermanifest suchen

VTS sucht an den folgenden Orten in der folgenden Reihenfolge nach der Datei des Anbieters manifest.xml:

1. /vendor/etc/vintf/manifest.xml + ODM-Manifest (wenn dieselbe HAL an beiden Orten definiert ist, überschreibt das ODM-Manifest die Definition in /vendor/etc/vintf/manifest.xml)
2. /vendor/etc/vintf/manifest.xml
3. ODM manifest.xml-Datei, die aus den folgenden Dateien in der folgenden Reihenfolge geladen wird:
   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

VTS-Testbarkeitsprüfung

Die vts_testibility_checker ist eine Binärdatei, die in VTS enthalten ist und vom VTS-Testframework zur Laufzeit verwendet wird, um zu ermitteln, ob ein bestimmter HAL-Test testbar ist. Sie basiert auf libvintf , um die Anbietermanifestdatei zu laden und zu parsen, und implementiert den Entscheidungsablauf , der im vorherigen Abschnitt beschrieben wird.

So verwenden Sie vts_testability_check:

• Für einen Compliance-Test:

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

• Für einen Noncompliance-Test:

  vts_testability_check -b <bitness>  <hal@version>

Die Ausgabe von vts_testability_check verwendet das folgende JSON Format:

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

Aufgerufene HALs ermitteln

Damit Sie ermitteln können, auf welche HALs von VTS-Tests zugegriffen wird, muss für jeden HAL-Test die VtsHalHidlTargetTestEnvBase Vorlage verwendet werden, um die HALs zu registrieren, auf die im Test zugegriffen wird. Das VTS-Testframework kann die registrierten HALs dann bei der Vorverarbeitung des Tests extrahieren.

Für Compliance-Tests können Sie auch /system/etc/vintf/manifest.xml prüfen. Wenn hier eine HAL definiert ist, sollte sie von VTS getestet werden. Bei den vom System bereitgestellten HAL-Diensten (z.B. graphics.composer/vr) werden die HALs in /system/manifest.xml deklariert.