HAL-Testbarkeitsprüfung

Die Android 9-Anbietertestsuite (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 oder höher auf den Markt gebracht werden. Nicht alle VTS-Tests gelten jedoch für alle Geräteziele. 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 Anbieter-Image haben, aber unterschiedliche Hardwarefunktionen, muss VTS ermitteln, 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 mit Android 8.0 oder höher ausgeführt und bestanden werden.
• Nicht konforme 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 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 einen bestimmten HAL unterstützt:

• /system/compatibility_matrix.xml. Er fordert die vom Framework erforderlichen 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 das HAL für das Framework unbedingt erforderlich ist.
  • Die Datei kann mehrere Einträge für dieselbe HAL (mit demselben Namen) mit unterschiedlicher Version und unterschiedlichen Schnittstellen enthalten.
  • Die Datei kann mehrere version-Konfigurationen für denselben Eintrag enthalten, was darauf hinweist, dass das Framework mit verschiedenen Versionen funktionieren kann.
  • version1.0-1 bedeutet, dass das Framework mit der niedrigsten Version 1.0 arbeiten kann und keine höhere Version als 1.1 erfordert.
• 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 dieselbe HAL (mit demselben Namen) mit unterschiedlicher Version und unterschiedlichen 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 enthält, 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 Compliance-Tests verwendet VTS das Anbietermanifest, um alle vom Gerät bereitgestellten HAL-Instanzen zu ermitteln und zu testen. Entscheidungsfluss:

Abbildung 1: Testbarkeitsprüfung für VTS-Compliance-Tests

Nicht konforme Tests

Bei Nichteinhaltungstests verwendet VTS das Anbietermanifest und die lshal-Ausgaben, um die experimentellen HALs zu ermitteln und zu testen, die in der manifest.xml-Datei nicht angegeben wurden. Entscheidungsablauf:

Abbildung 2 Testbarkeitsprüfung für VTS-Nichteinhaltungstests

Anbietermanifest finden

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

1. /vendor/etc/vintf/manifest.xml + ODM-Manifest (Wenn an beiden Stellen dieselbe HAL definiert ist, wird die in /vendor/etc/vintf/manifest.xml definierte HAL vom ODM-Manifest überschrieben.)
2. /vendor/etc/vintf/manifest.xml
3. ODM-manifest.xml-Datei, die in der folgenden Reihenfolge aus den folgenden Dateien 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 Testability Checker

vts_testibility_checker ist ein Binärprogramm, das mit VTS verpackt ist und vom VTS-Test-Framework zur Laufzeit verwendet wird, um festzustellen, ob ein bestimmter HAL-Test testbar ist oder nicht. Es 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 verwendet das folgende JSON-Format:

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

Zugegriffene HALs ermitteln

Um zu ermitteln, auf welche HALs von VTS-Tests zugegriffen wird, müssen Sie dafür sorgen, dass jeder HAL-Test die Vorlage VtsHalHidlTargetTestEnvBase verwendet, um die HALs zu registrieren, auf die im Test zugegriffen wird. Das VTS-Testframework kann dann die registrierten HALs bei der Vorverarbeitung des Tests extrahieren.

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