Manifeste

Ein VINTF-Objekt aggregiert Daten von device Manifest-Dateien und Framework-Manifestdateien (XML). Beide Manifeste haben dasselbe Format, obwohl nicht alle Elemente auf beide angewendet werden (weitere Informationen siehe Schema der Manifestdatei.

Gerätemanifest

Das Gerätemanifest (vom Gerät zur Verfügung gestellt) besteht aus dem Anbietermanifest. und das ODM-Manifest.

  • Im Anbietermanifest sind HALs, SELinux-Richtlinienversionen usw. angegeben, die für ein SoC üblich sind. Es wird empfohlen, in der Android-Quellstruktur unter device/VENDOR/DEVICE/manifest.xml, aber mehrere Fragmente -Dateien verwendet werden können. Weitere Informationen finden Sie unter Manifestfragmente und Generieren DN von Fragmenten
  • Im ODM-Manifest sind HALs speziell für das Produkt im ODM-Partition: Das VINTF-Objekt lädt das ODM-Manifest in der folgenden Reihenfolge: <ph type="x-smartling-placeholder">
      </ph>
    1. Wenn SKU definiert ist (wobei SKU der Wert von die Eigenschaft ro.boot.product.hardware.sku) /odm/etc/vintf/manifest_SKU.xml
    2. /odm/etc/vintf/manifest.xml
    3. Wenn SKU definiert ist, /odm/etc/manifest_SKU.xml
    4. /odm/etc/manifest.xml
  • Im Anbietermanifest werden für das Produkt in der Anbieterpartition spezifische HALs aufgeführt. Das VINTF-Objekt lädt das Anbietermanifest in folgender Reihenfolge: <ph type="x-smartling-placeholder">
      </ph>
    1. Wenn SKU definiert ist (wobei SKU der Wert von die Eigenschaft ro.boot.product.vendor.sku) /vendor/etc/vintf/manifest_SKU.xml
    2. /vendor/etc/vintf/manifest.xml
  • Das VINTF-Objekt lädt das Gerätemanifest in der folgenden Reihenfolge: <ph type="x-smartling-placeholder">
      </ph>
    1. Wenn das Anbietermanifest vorhanden ist, kombinieren Sie Folgendes: <ph type="x-smartling-placeholder">
        </ph>
      1. Das Anbietermanifest
      2. Optionale Fragmente des Anbietermanifests
      3. Optionales ODM-Manifest
      4. Optionale ODM-Manifestfragmente
    2. Wenn das ODM-Manifest vorhanden ist, kombinieren Sie andernfalls das ODM-Manifest mit dem optionalen ODM-Manifest. Manifest-Fragmente.
    3. /vendor/manifest.xml (Legacy, keine Fragmente)
    4. Kombinieren Sie schließlich Manifestfragmente von beliebigen Anbieter-APEXes.

    Hinweise:

    • Auf Legacy-Geräten werden das Legacy-Anbietermanifest und das ODM-Manifest verwendet. Die Das ODM-Manifest kann das Legacy-Anbietermanifest vollständig überschreiben.
    • Auf Geräten mit Android 9 ist das ODM-Manifest kombiniert mit dem Anbieter-Manifest ein.
    • Wenn du eine Liste von Manifesten kombinierst, können Manifeste, die weiter unten in der Liste erscheinen, überschreiben Tags in Manifesten, die weiter oben in der Liste angezeigt werden, vorausgesetzt, dass die Tags in den Manifest das Attribut override="true" haben. Das ODM-Manifest kann beispielsweise <hal>-Tags aus dem Anbietermanifest überschreiben. Weitere Informationen finden Sie in der Dokumentation zu Attribut override unten.

So können mehrere Produkte mit demselben Board dasselbe Board verwenden Anbieter-Image (das gängige HALs bereitstellt) und dennoch unterschiedliche ODM-Images haben (die produktspezifische HALs angeben.

Hier ist ein Beispiel für ein Anbietermanifest.

<?xml version="1.0" encoding="UTF-8"?>
<!-- Comments, Legal notices, etc. here -->
<manifest version="2.0" type="device" target-level="1">
    <hal>
        <name>android.hardware.camera</name>
        <transport>hwbinder</transport>
        <version>3.4</version>
        <interface>
            <name>ICameraProvider</name>
            <instance>legacy/0</instance>
            <instance>proprietary/0</instance>
        </interface>
    </hal>
    <hal>
        <name>android.hardware.nfc</name>
        <transport>hwbinder</transport>
        <version>1.0</version>
        <version>2.0</version>
        <interface>
            <name>INfc</name>
            <instance>nfc_nci</instance>
        </interface>
    </hal>
    <hal>
        <name>android.hardware.nfc</name>
        <transport>hwbinder</transport>
        <fqname>@2.0::INfc/default</fqname>
    </hal>
    <hal>
        <name>android.hardware.drm</name>
        <transport>hwbinder</transport>
        <version>1.0</version>
        <interface>
            <name>ICryptoFactory</name>
            <instance>default</instance>
        </interface>
        <interface>
            <name>IDrmFactory</name>
            <instance>default</instance>
        </interface>
        <fqname>@1.1::ICryptoFactory/clearkey</fqname>
        <fqname>@1.1::IDrmFactory/clearkey</fqname>
    </hal>
    <hal format="aidl">
        <name>android.hardware.light</name>
        <version>1</version>
        <fqname>ILights/default</fqname>
    </hal>
    <hal format="aidl">
        <name>android.hardware.power</name>
        <version>2</version>
        <interface>
            <name>IPower</name>
            <instance>default</instance>
        </interface>
    </hal>
    <hal format="native">
        <name>EGL</name>
        <version>1.1</version>
    </hal>
    <hal format="native">
        <name>GLES</name>
        <version>1.1</version>
        <version>2.0</version>
        <version>3.0</version>
    </hal>
    <sepolicy>
        <version>25.0</version>
    </sepolicy>
</manifest>

Hier ist ein Beispiel für ein ODM-Manifest.

<?xml version="1.0" encoding="UTF-8"?>
<!-- Comments, Legal notices, etc. here -->
<manifest version="1.0" type="device">
    <!-- camera 3.4 in vendor manifest is ignored -->
    <hal override="true">
        <name>android.hardware.camera</name>
        <transport>hwbinder</transport>
        <version>3.5</version>
        <interface>
            <name>ICameraProvider</name>
            <instance>legacy/0</instance>
        </interface>
    </hal>
    <!-- NFC is declared to be disabled -->
    <hal override="true">
        <name>android.hardware.nfc</name>
        <transport>hwbinder</transport>
    </hal>
    <hal>
        <name>android.hardware.power</name>
        <transport>hwbinder</transport>
        <version>1.1</version>
        <interface>
            <name>IPower</name>
            <instance>default</instance>
        </interface>
    </hal>
</manifest>

Hier ist ein Beispiel für ein Gerätemanifest in einem OTA-Paket.

<?xml version="1.0" encoding="UTF-8"?>
<!-- Comments, Legal notices, etc. here -->
<manifest version="1.0" type="device" target-level="1">
    <!-- hals ommited -->
    <kernel version="4.4.176">
        <config>
            <key>CONFIG_ANDROID</key>
            <value>y</value>
        </config>
        <config>
            <key>CONFIG_ARM64</key>
            <value>y</value>
        </config>
    <!-- other configs ommited -->
    </kernel>
</manifest>

Weitere Informationen findest du unter Gerätemanifest. Entwicklung.

Framework-Manifest

Die Framework-Manifestdatei besteht aus dem Systemmanifest, dem Produktmanifest und dem system_ext.

  • Das von Google bereitgestellte Systemmanifest wird manuell generiert und befindet sich in der Android Source Tree unter /system/libhidl/manifest.xml
  • Im vom Gerät bereitgestellten Produktmanifest werden HALs aufgelistet, die von auf dem Produktaufteilung.
  • Das vom Gerät bereitgestellte Manifest „system_ext“ enthält Folgendes: <ph type="x-smartling-placeholder">
      </ph>
    • HALs, die von Modulen bedient werden, die auf der Partition system_ext installiert sind;
    • VNDK-Versionen:
    • System SDK-Version.

Ähnlich wie beim Gerätemanifest können mehrere Fragmentdateien verwendet werden. Weitere Informationen finden Sie unter Manifestfragmente.

Hier ist ein Beispiel für ein Framework-Manifest.

<?xml version="1.0" encoding="UTF-8"?>
<!-- Comments, Legal notices, etc. here -->
<manifest version="1.0" type="framework">
    <hal>
        <name>android.hidl.allocator</name>
        <transport>hwbinder</transport>
        <version>1.0</version>
        <interface>
            <name>IAllocator</name>
            <instance>ashmem</instance>
        </interface>
    </hal>
    <hal>
        <name>android.hidl.memory</name>
        <transport arch="32+64">passthrough</transport>
        <version>1.0</version>
        <interface>
            <name>IMapper</name>
            <instance>ashmem</instance>
        </interface>
    </hal>
    <hal>
        <name>android.hidl.manager</name>
        <transport>hwbinder</transport>
        <version>1.0</version>
        <interface>
            <name>IServiceManager</name>
            <instance>default</instance>
        </interface>
    </hal>
    <hal>
        <name>android.frameworks.sensorservice</name>
        <transport>hwbinder</transport>
        <version>1.0</version>
        <interface>
            <name>ISensorManager</name>
            <instance>default</instance>
        </interface>
    </hal>
    <hal max-level="5">
        <name>android.frameworks.schedulerservice</name>
        <transport>hwbinder</transport>
        <version>1.0</version>
        <interface>
            <name>ISchedulingPolicyService</name>
            <instance>default</instance>
        </interface>
    </hal>
    <vendor-ndk>
        <version>27</version>
    </vendor-ndk>
    <system-sdk>
        <version>27</version>
    </system-sdk>
</manifest>

Manifestfragmente

Unter Android 10 und höher können Sie ein Manifest mit mit einem HAL-Modul im Build-System. So können Sie das HAL-Modul bedingt in das Build-System einbinden.

Beispiel

Fügen Sie in der Datei Android.bp oder Android.mk vintf_fragments auf ein beliebiges Modul. Sie können beispielsweise das Modul mit Ihrer HAL-Implementierung (my.package.foo@1.0-service-bar) 

... {
    ...
    vintf_fragments: ["manifest_foo.xml"],
    ...
}
LOCAL_MODULE := ...
LOCAL_VINTF_FRAGMENTS := manifest_foo.xml

Erstellen Sie in der Datei manifest_foo.xml das Manifest für dieses Moduls. Bei der Build-Erstellung wird dieses Manifest dem Gerät hinzugefügt. Wird hinzugefügt Ein Eintrag hier entspricht dem Hinzufügen eines Eintrags im Hauptmanifest des Geräts. So können Clients die Schnittstelle verwenden und VTS kann ermitteln, welcher HAL Implementierungen auf dem Gerät. Alles, was ein reguläres Manifest tut, tut dieses Manifest ebenfalls das.

Im folgenden Beispiel wird eine android.hardware.foo@1.0::IFoo/default, installiert auf die Partition vendor oder odm. Wenn es auf dem Partition system, product oder system_ext, Typ verwenden framework statt Geben Sie device ein. 

<manifest version="1.0" type="device">
    <hal format="hidl">
        <name>android.hardware.foo</name>
        <transport>hwbinder</transport>
        <fqname>@1.0::IFoo/default</fqname>
    </hal>
</manifest>

Wenn ein HAL-Modul in einem Anbieter-APEX verpackt ist, seine verknüpften VINTF-Fragmente im selben APEX mit prebuilt_etc als Paket Weitere Informationen finden Sie unter VINTF-Fragmente.

Schema der Manifestdatei

In diesem Abschnitt wird die Bedeutung dieser XML-Tags beschrieben. Einige „erforderliche“ Tags in der Quelldatei in der Android-Quellstruktur fehlen und assemble_vintf während der Build-Erstellung. Erforderliche Tags müssen in den entsprechenden Dateien auf der .

?xml
Optional. Stellt nur Informationen für den XML-Parser bereit.
manifest.version
Erforderlich. Metaversion dieses Manifests. Beschreibt die Elemente, die im Manifest erwartet werden. Kein Bezug zur XML-Version.
manifest.type
Erforderlich. Typ dieses Manifests. Sie hat den Wert device für die Geräte-Manifestdatei und framework für das Framework-Manifest -Datei.
manifest.target-level
Erforderlich für das Gerätemanifest. Gibt die Framework-Kompatibilitätsmatrix an (FCM-Version), auf die dieses Gerätemanifest ausgerichtet ist, mit. Sie wird auch als FCM-Versandversion des Geräts bezeichnet.
manifest.hal
Optional, kann wiederholt werden. Ein einzelner HAL (HIDL oder nativ wie GL) abhängig vom Attribut format.
manifest.hal.format
Optional. Folgende Werte sind möglich: <ph type="x-smartling-placeholder">
    </ph>
  • hidl: HIDL HALs. Das ist die Standardeinstellung.
  • aidl: AIDL HALs Nur gültig ab Manifest-Meta-Version 2.0 und höher.
  • native: Native HALs.
manifest.hal.max-level
Optional. Nur für Framework-Manifeste gültig. Wenn festgelegt, HALs mit einer niedrigeren Stufe als die FCM-Zielversion im Framework-Manifest deaktiviert ist.
manifest.hal.override
Optional. Folgende Werte sind möglich: <ph type="x-smartling-placeholder">
    </ph>
  • true: Andere <hal>-Elemente überschreiben mit dieselbe <name>- und Hauptversion. Falls nein <version> oder <fqname> sind in dieser <hal>-Element, dann das <hal>-Element deklariert diesen HAL als deaktiviert.
  • false: keine anderen <hal>-Elemente überschreiben mit derselben <name>- und Hauptversion.
manifest.hal.name
Erforderlich. Voll qualifizierter Paketname des HAL. Mehrere HAL-Einträge können verwendet werden mit demselben Namen. Beispiele: <ph type="x-smartling-placeholder">
    </ph>
  • android.hardware.camera (HIDL oder AIDL HAL)
  • GLES (natives HAL, nur Name erforderlich)
manifest.hal.transport
Erforderlich, wenn manifest.hal.format == "hidl". Darf NICHT sein nicht vorhanden sind. Gibt an, welcher Transport verwendet wird, Dieses Paket wird vom Dienstmanager abgefragt. Folgende Werte sind möglich: <ph type="x-smartling-placeholder">
    </ph>
  • hwbinder: Bindungsmodus
  • passthrough: Passthrough-Modus
Optional, wenn manifest.hal.format == "aidl". Darf NICHT sein nicht vorhanden sind. Gibt an, welcher Transport verwendet wird, wenn eine Schnittstelle bereitgestellt wird Remote-Zugriff. Der Wert muss wie folgt aussehen: <ph type="x-smartling-placeholder">
    </ph>
  • inet: Inet-Socket
manifest.hal.transport.ip und manifest.hal.transport.port muss zur weiteren Angabe der Inet-Verbindungsinformationen verwendet werden.
manifest.hal.transport.arch
Erforderlich für passthrough und darf nicht vorhanden sein für hwbinder Beschreibt die Bitqualität des Passthrough-Dienstes bereitgestellt. Folgende Werte sind möglich: <ph type="x-smartling-placeholder">
    </ph>
  • 32: 32-Bit-Modus
  • 64: 64-Bit-Modus
  • 32+64: Beide
manifest.hal.transport.ip
Erforderlich für inet und darf NICHT angegeben werden. Beschreibt die IP-Adresse über die die Remote-Schnittstelle bereitgestellt wird.
manifest.hal.transport.port
Erforderlich für inet und darf NICHT angegeben werden. Beschreibt den Port aus für die die Remote-Schnittstelle bereitgestellt wird.
manifest.hal.version
Optional, kann wiederholt werden. Eine Version der hal-Tags in einer Manifests.

Für HIDL und native HALs lautet das Format: MAJOR.MINOR. Für Beispiele finden Sie unter hardware/interfaces, vendor/${VENDOR}/interfaces, frameworks/hardware/interfaces oder system/hardware/interfaces.

HIDL- und native HALs können mehrere Versionsfelder verwenden, solange sie für unterschiedliche Hauptversionen mit nur einer Nebenversion pro Hauptversion Version bereitgestellt. Beispielsweise können 3.1 und 3.2 nicht gleichzeitig vorhanden sein, 1.0 und 3.4 jedoch schon. Dies gilt für alle hal-Elemente mit demselben Namen, es sei denn, override="true". Die Werte von <version> sind nicht verknüpft mit <fqname>, da ein <fqname> eine Version enthält.

Für AIDL HALs darf <version> nicht auf Geräten vorhanden sein, die ausgeführt werden Android 11 und niedriger. <version> muss ein einzelne Ganzzahl auf Geräten mit Android 12 und höher. Es darf jeweils nur ein <version> vorhanden sein Tupel (package, interface, instance). Falls nicht vorhanden, wird standardmäßig 1 Der Wert von <version> ist verknüpft mit alle <fqname> in derselben <hal>, weil Für <fqname> ist keine Version vorhanden.
manifest.hal.interface
Erforderlich, kann ohne Duplikate wiederholt werden. Geben Sie eine Schnittstelle im Paket mit einem Instanznamen. Es können mehrere <interface>-Elemente in einem <hal>; Namen müssen eindeutig sein.
manifest.hal.interface.name
Erforderlich. Name der Schnittstelle.
manifest.hal.interface.instance
Erforderlich, kann wiederholt werden. Instanzname der Schnittstelle. Kann mehrere Instanzen für eine Schnittstelle, aber keine duplizierten <instance> Elemente.
manifest.hal.fqname
Optional, kann wiederholt werden. Alternative Methode zum Angeben einer Instanz für die HAL namens manifest.hal.name.
  • Für HIDL HALs lautet das Format: @MAJOR.MINOR::INTERFACE/INSTANCE
  • Für AIDL HALs lautet das Format: INTERFACE/INSTANCE
manifest.sepolicy
Erforderlich. Enthält alle sepolicy-bezogenen Einträge.
manifest.sepolicy.version
Erforderlich für das Gerätemanifest. Deklariert die SELinux-Version. Es hat die Format SDK_INT.PLAT_INT.
manifest.vendor-ndk
Erforderlich, kann wiederholt werden; für das Framework-Manifest erforderlich. Darf nicht vorhanden sein im Gerätemanifest. Mehrere <vendor-ndk>-Einträge müssen verschiedenen <version>s. Beschreibt eine Reihe von VNDK-Snapshots durch das Framework bereitgestellt wird.
manifest.vendor-ndk.version
Erforderlich. Dies ist eine positive Ganzzahl für die Version des VNDK Snapshot.
manifest.vendor-ndk.library
Optional, kann wiederholt werden, ohne Duplikate. Beschreibt eine Reihe von VNDK-Bibliotheken das durch das Framework für diesen Snapshot des VNDK-Anbieters bereitgestellt wird. Der Wert ist der Dateiname einer Bibliothek, z.B. libjpeg.so, einschließlich Präfix lib und das Suffix .so. Es werden keine Pfadkomponenten zulässig.
manifest.system-sdk.version
Optional, kann wiederholt werden, ohne Duplikate; werden nur vom Framework verwendet Manifests. Beschreibt eine Reihe von System-SDK-Versionen, die vom Framework für Apps von Anbietern.
manifest.kernel
Optional. Beschreibt statische Informationen zum Kernel.
manifest.kernel.target-level
Optional. Beschreibt den Kernel-Zweig. Der Standardwert ist manifest.target-level, falls nicht vorhanden. Muss größer sein als oder gleich manifest.target-level ist. Weitere Informationen finden Sie unter Kernel-Match-Regeln .