HAL-Testbarkeitsprüfung

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

VTS-Testflexibilität

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

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

VTS-Testtypen

VTS umfasst die folgenden Testtypen:

  • Konformitätstests stellen die Kompatibilität zwischen Framework- und Herstellerpartitionen sicher. Diese Tests müssen auf Geräten ausgeführt (und bestanden) werden, die mit Android 8.0 oder höher gestartet werden.
  • Non-Compliance- Tests helfen Anbietern, die Produktqualität zu verbessern (Performance/Fuzzing etc.). Diese Tests sind für Anbieter optional.

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

Ermitteln unterstützter HALs

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

  • /system/compatibility_matrix.xml . Beansprucht die vom Framework benötigten HAL-Instanzen. 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 optional Attribut gibt an, ob die HAL vom Framework unbedingt erforderlich ist.
    • 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 für denselben Eintrag enthalten, was darauf hinweist, dass das Framework mit verschiedenen Versionen arbeiten kann.
    • version1.0-1 bedeutet, dass das Framework mit der niedrigsten Version 1.0 arbeiten kann und keine Version höher als 1.1 benötigt.
  • 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), aber mit unterschiedlichen Versionen und Schnittstellen enthalten.
    • Wenn die Datei nur eine einzige version für einen Eintrag enthält, version1.2 Version 1.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 beim hwservicemanager registrierten HAL-Diensten anzeigt. Beispiel:
    android.hardware.vibrator@1.0::IVibrator/default
    

    lshal zeigt auch alle HALs mit Passthrough-Implementierungen (dh 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/)
    

Konformitätstests

Bei Konformitätstests verlässt sich VTS auf das Herstellermanifest, um alle vom Gerät bereitgestellten HAL-Instanzen zu bestimmen (und zu testen). Entscheidungsfluss:

Testability check for compliance

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

Non-Compliance-Tests

Bei Nichtkonformitätstests verlässt sich VTS auf die Manifest- und lshal Ausgaben des Anbieters, um die experimentellen HALs zu bestimmen (und zu testen), die nicht in der Datei manifest.xml “ beansprucht werden. Entscheidungsfluss:

Testability check for non-compliance

Abbildung 2. Testbarkeitsprüfung für VTS-Non-Compliance-Tests

Lokalisieren des Anbietermanifests

VTS sucht an den folgenden Stellen in der folgenden Reihenfolge nach der Datei „vendor manifest.xml “:

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

Der vts_testibility_checker ist eine mit VTS gepackte Binärdatei, die vom VTS-Testframework zur Laufzeit verwendet wird, um zu bestimmen, ob ein bestimmter HAL-Test testbar ist oder nicht. Es basiert auf libvintf , um die Herstellermanifestdatei zu laden und zu analysieren, und implementiert den im vorherigen Abschnitt beschriebenen Entscheidungsablauf.

So verwenden vts_testability_check :

  • Für einen Konformitätstest:
    vts_testability_check -c -b <bitness>  <hal@version>
    
  • Für einen Non-Compliance-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>}

Zugegriffene HALs bestimmen

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

Für Konformitätstests können Sie auch /system/etc/vintf/manifest.xml überprü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.)