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 einen Test-HAL (z.B. IR) nicht unterstützt, muss VTS für diesen HAL-Test keine Tests 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 stellen die Kompatibilität zwischen Framework- und Anbieterpartitionen sicher. 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 Compliancetest ist, hängt davon ab, zu welchem Tarif er gehört. Tests, die mit dem VTS-Plan ausgeführt werden, gelten als Compliancetests.

Unterstützte HALs ermitteln

VTS kann anhand der folgenden Dateien feststellen, ob das Geräteziel eine bestimmte 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 die HAL vom 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“. Erklärt Anspruch auf 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:

Testbarkeitsprüfung auf Compliance

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

Richtlinienverstöße

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. Entscheidungsfluss:

Testbarkeitscheck auf Nichteinhaltung

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 derselbe HAL an beiden Stellen definiert ist, überschreibt das ODM-Manifest den in /vendor/etc/vintf/manifest.xml)
  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-Testbarkeitsprüfung

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>
  • Bei einem Verstoßtest: 
    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 in 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 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 ein HAL definiert ist, sollte VTS ihn testen. Für die vom System bereitgestellten HAL-Dienste (z.B. graphics.composer/vr) werden die HALs in /system/manifest.xml deklariert.