HAL-Testbarkeitsprüfung

Die Vendor Test Suite (VTS) für Android 9 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

Seit Android 8.0 sind VTS-Tests für alle Geräte erforderlich, die mit Android 8.0 oder höher eingeführt werden. Allerdings gelten nicht alle VTS-Tests für alle Geräteziele. Beispiel:

• Wenn ein bestimmtes Gerät keinen Test-HAL unterstützt (z.B. IR), müssen für dieses Gerät keine VTS-Tests für diesen HAL-Test ausgeführt werden.
• Wenn sich mehrere Geräte dasselbe SoC und dasselbe Anbieter-Image teilen, aber unterschiedliche Hardwarefunktionen haben, muss VTS feststellen, ob ein Test für ein bestimmtes Geräteziel ausgeführt oder übersprungen werden soll.

VTS-Testtypen

VTS umfasst die folgenden Testtypen:

• Compliance-Tests sorgen für die 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.
• Tests zur Nichteinhaltung von Richtlinien helfen Anbietern, die Produktqualität (Leistung/Fuzzing usw.) zu verbessern. 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 einem VTS-Plan ausgeführt werden, gelten als Compliance-Tests.

Unterstützte HALs ermitteln

VTS kann die folgenden Dateien verwenden, um festzustellen, ob das Geräteziel eine bestimmte HAL unterstützt:

• /system/compatibility_matrix.xml. Fordert die vom Framework benötigten HAL-Instanzen an. 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 vom Framework zwingend erforderlich ist.
  • Die Datei kann mehrere Einträge für dasselbe HAL (mit demselben Namen) enthalten, jedoch mit unterschiedlichen Versionen und Schnittstellen.
  • Die Datei kann mehrere version-Konfigurationen für denselben Eintrag enthalten, was darauf hindeutet, 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.
• Gerät „manifest.xml“ Beansprucht die vom Anbieter bereitgestellten HAL-Instanzen. 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 dasselbe HAL (mit demselben Namen) enthalten, jedoch mit unterschiedlichen Versionen und Schnittstellen.
  • Wenn die Datei nur eine einzelne 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 bei 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

Bei Konformitätstests stützt sich VTS auf das Anbietermanifest, um alle vom Gerät bereitgestellten HAL-Instanzen zu ermitteln und zu testen. Entscheidungsablauf:

Tests zur Nichteinhaltung

Bei Tests zur Einhaltung von Richtlinien stützt sich VTS auf das Herstellermanifest und die lshal-Ausgaben, um die experimentellen HALs zu ermitteln (und zu testen), die in der Datei manifest.xml nicht angegeben sind. Entscheidungsablauf:

Anbietermanifest suchen

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

1. /vendor/etc/vintf/manifest.xml + ODM-Manifest (wenn dasselbe HAL an beiden Stellen definiert ist, wird das in /vendor/etc/vintf/manifest.xml überschrieben)
2. /vendor/etc/vintf/manifest.xml
3. ODM-Datei manifest.xml, 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

Das vts_testibility_checker ist ein Binärpaket, das mit VTS ausgeliefert wird und vom VTS-Testframework zur Laufzeit verwendet wird, um zu bestimmen, ob ein bestimmter HAL-Test testbar ist oder nicht. Sie basiert auf libvintf, um die Manifestdatei des Anbieters zu laden und zu parsen, und implementiert den im vorherigen Abschnitt beschriebenen Entscheidungsablauf.

Gehe so vor, wenn du vts_testability_check verwenden möchtest:

• Für einen Compliance-Test:

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

• Für einen Test auf Nichteinhaltung:

  vts_testability_check -b <bitness>  <hal@version>

Die Ausgabe von vts_testability_check hat das folgende JSON-Format:

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

Zugegriffene HALs ermitteln

Um zu ermitteln, auf welche HALs durch VTS-Tests zugegriffen wird, muss jeder HAL-Test die Vorlage VtsHalHidlTargetTestEnvBase verwenden, um die im Test verwendeten HALs zu registrieren. Das VTS-Testframework kann dann die registrierten HALs beim Vorverarbeiten des Tests extrahieren.

Informationen zu Konformitätstests finden Sie auch unter /system/etc/vintf/manifest.xml. Wenn hier ein HAL definiert ist, sollte es von VTS getestet werden. Für die vom System bereitgestellten HAL-Dienste (z.B. graphics.composer/vr) werden die HALs in /system/manifest.xml deklariert.