Die Android 9 Vendor Test Suite (VTS) unterstützt eine Laufzeitmethode zur Verwendung der Gerätekonfiguration, um zu identifizieren, 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 kein Test-HAL unterstützt (z. B. IR), muss VTS keine Tests für diesen HAL-Test für dieses Geräteziel ausführen.
- Wenn mehrere Geräte denselben SoC und dasselbe Hersteller-Image verwenden, jedoch über unterschiedliche Hardwarefunktionen verfügen, 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:
- Compliance- Tests stellen die Kompatibilität zwischen Framework- und Anbieterpartitionen sicher. Diese Tests müssen auf Geräten ausgeführt (und bestanden) werden, die mit Android 8.0 oder höher starten.
- Non-Compliance -Tests helfen Anbietern, die Produktqualität zu verbessern (Leistung/Fuzzing etc.). Diese Tests sind für Anbieter optional.
Ob es sich bei einem Test um einen Compliance-Test handelt 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.
Bestimmen Sie unterstützte HALs
VTS kann die folgenden Dateien verwenden, um festzustellen, ob das Geräteziel ein bestimmtes 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 enthält möglicherweise mehrere Einträge für dieselbe HAL (mit demselben Namen), jedoch mit unterschiedlichen Versionen und Schnittstellen.
- 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 höhere Version als 1.1 erfordert.
- Das
- 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 enthält möglicherweise mehrere Einträge für dieselbe HAL (mit demselben Namen), jedoch mit unterschiedlichen Versionen und Schnittstellen.
- Wenn die Datei nur eine einzige
version
für einen Eintrag enthält, bedeutetversion1.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 beim
hwservicemanager
registriert sind. Beispiel:android.hardware.vibrator@1.0::IVibrator/default
lshal
zeigt auch alle HALs mit Passthrough-Implementierungen (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/)
Konformitätstests
Für Konformitätstests verlässt sich VTS auf das Herstellermanifest, um alle vom Gerät bereitgestellten HAL-Instanzen zu ermitteln (und zu testen). Entscheidungsablauf:
Nichtkonformitätstests
Bei Nichtkonformitätstests verlässt sich VTS auf die Manifest- und lshal
Ausgaben des Herstellers, um die experimentellen HALs zu ermitteln (und zu testen), die nicht in der Datei manifest.xml
beansprucht werden. Entscheidungsablauf:
Suchen Sie das Anbietermanifest
VTS sucht an den folgenden Stellen in der folgenden Reihenfolge nach der Datei „vendor manifest.xml
:
-
/vendor/etc/vintf/manifest.xml
+ ODM-Manifest (Wenn an beiden Stellen dasselbe HAL definiert ist, überschreibt das ODM-Manifest das in/vendor/etc/vintf/manifest.xml
) -
/vendor/etc/vintf/manifest.xml
- ODM-Datei
manifest.xml
, geladen aus den folgenden Dateien in der folgenden Reihenfolge:-
/odm/etc/vintf/manifest_$(ro.boot.product.hardware.sku).xml
-
/odm/etc/vintf/manifest.xml
-
/odm/etc/manifest_$(ro.boot.product.hardware.sku).xml
-
/odm/etc/manifest.xml
-
/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
zum Laden und Analysieren der Herstellermanifestdatei und implementiert den im vorherigen Abschnitt beschriebenen Entscheidungsfluss.
So verwenden Sie vts_testability_check
:
- Für einen Konformitätstest:
vts_testability_check -c -b <bitness> <hal@version>
- Für einen Nichtkonformitätstest:
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>}
Bestimmen Sie die HALs, auf die zugegriffen wurde
Um festzustellen, 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 ein HAL definiert ist, sollte VTS es testen. (Für die vom System bereitgestellten HAL-Dienste (z. B. graphics.composer/vr
) werden die HALs in /system/manifest.xml
deklariert.)