HAL-Testbarkeitsprüfung

Die Android 9 Vendor Test Suite (VTS) unterstützt eine Laufzeitmethode, um anhand der Gerätekonfiguration zu ermitteln, welche VTS-Tests für dieses Geräteziel übersprungen werden soll.

Flexibilität bei VTS-Tests

Ab Android 8.0 sind VTS-Tests für alle Geräte erforderlich, die Android 8.0 und höher. Allerdings gelten nicht alle VTS-Tests für alle Geräte. Ziele. Beispiel:

• Wenn ein bestimmtes Gerät eine HAL zum Testen (z.B. IR) nicht unterstützt, tut VTS keine Tests für diesen HAL-Test für dieses Geräteziel durchführen müssen.
• Wenn mehrere Geräte dasselbe SoC und dasselbe Anbieter-Image verwenden, aber unterschiedlichen Hardwarefunktionen verwendet wird, muss VTS bestimmen, ob ein Test die für ein bestimmtes Geräteziel ausgeführt oder übersprungen werden soll.

VTS-Testtypen

VTS umfasst die folgenden Testtypen:

• Compliance-Tests stellen die Kompatibilität zwischen den Frameworks sicher und Anbieterpartitionen. Diese Tests müssen durchgeführt (und bestanden) Geräte mit Android 8.0 oder höher auf den Markt bringen.
• Compliance-Tests helfen Anbietern, ihre Produkte zu verbessern Qualität (Leistung, Fuzzing usw.). Diese Tests sind für Anbieter optional.

Ob ein Test ein Compliancetest ist oder nicht, hängt davon ab, zu welchem Tarif er gehört an. Tests, die mit <ph type="x-smartling-placeholder"></ph> VTS-Plan gelten als Compliancetests.

Unterstützte HALs ermitteln

VTS kann anhand der folgenden Dateien feststellen, ob das Geräteziel ein bestimmte HAL:

• /system/compatibility_matrix.xml Beansprucht die HAL-Instanzen die vom Framework gefordert 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 der HAL streng die vom Framework gefordert werden.
  • Die Datei kann mehrere Einträge für denselben HAL (mit demselben Namen) enthalten. aber mit unterschiedlichen Versionen und Benutzeroberflächen.
  • Die Datei kann mehrere version-Konfigurationen für denselben Eintrag, was darauf hinweist, dass das Framework mit verschiedenen Versionen funktioniert.
  • version1.0-1 bedeutet, dass das Framework mit der niedrigsten Stufe Version 1.0 und erfordert keine höhere Version als 1.1.
• Gerät „manifest.xml“. Beansprucht die HAL-Instanzen, die vom Zulieferunternehmen. 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 denselben HAL (mit demselben Namen) enthalten. aber mit anderen Versionen und Benutzeroberflächen.
  • Wenn die Datei nur eine einzige version-Konfiguration enthält für einen Eintrag bedeutet version1.2, dass der Anbieter alle Versionen unterstützt von 1,0 bis 1,2.
• lshal: Ein Tool auf dem Gerät, das Laufzeitinformationen zu die HAL-Dienste, die mit hwservicemanager registriert sind. Beispiel:

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

  
  lshal zeigt auch alle HALs an, die mit Passthrough (d. h. mit der entsprechenden -impl.so-Datei auf das 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 stützt sich VTS auf das Anbietermanifest, Test) alle vom Gerät bereitgestellten HAL-Instanzen. Entscheidungsfluss:

Richtlinienverstöße

Bei Nicht-Compliance-Tests stützt sich VTS auf das Anbietermanifest lshal gibt die Ausgabe aus, um die experimentellen HALs zu bestimmen (und zu testen), die in der Datei manifest.xml beansprucht wurden. Entscheidungsfluss:

Anbietermanifest finden

VTS prüft Folgendes auf die Datei des Anbieters manifest.xml in der folgenden Reihenfolge:

1. /vendor/etc/vintf/manifest.xml + ODM-Manifest (bei gleicher HAL) definiert ist, überschreibt das ODM-Manifest die /vendor/etc/vintf/manifest.xml)
2. /vendor/etc/vintf/manifest.xml
3. ODM-Datei manifest.xml, aus den folgenden Dateien geladen in in der folgenden Reihenfolge: <ph type="x-smartling-placeholder">
   </ph>
   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 ein mit VTS verpacktes Binärprogramm, das von VTS-Testframework zur Laufzeit, um zu bestimmen, ob ein bestimmter HAL-Test ob sie testbar sind oder nicht. Sie basiert auf libvintf Zum Laden und Parsen der Anbieter-Manifestdatei sowie zur Implementierung des Entscheidungsablaufs wie im vorherigen Abschnitt beschrieben.

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

• Für einen Compliance-Test:

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

• Bei einem Verstoßtest:

  vts_testability_check -b <bitness>  <hal@version>
  

Für die Ausgabe von vts_testability_check wird die folgende JSON-Datei verwendet Format:

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

HALs, auf die zugegriffen wurde, ermitteln

Um zu ermitteln, auf welche HALs von VTS-Tests zugegriffen wird, stellen Sie sicher, dass jeder HAL-Test verwendet die VtsHalHidlTargetTestEnvBase Vorlage, um die HAL(s) zu registrieren, auf die im Test zugegriffen wurde. VTS-Tests kann das Framework die registrierten HALs bei der Vorverarbeitung des Tests extrahieren.

Für Compliance-Tests können Sie auch /system/etc/vintf/manifest.xml Wenn hier ein HAL definiert ist, sollten Sie es testen. Für die vom System bereitgestellten HAL-Dienste (z.B. graphics.composer/vr), werden die HALs in /system/manifest.xml)