Manifeste

Ein VINTF-Objekt aggregiert Daten aus Device Manifest- und Framework Manifest-Dateien (XML). Beide Manifeste haben dasselbe Format, aber nicht alle Elemente gelten für beide. Weitere Informationen zum Schema findest du unter Manifestdateischema.

Gerätemanifest

Das Gerätemanifest (vom Gerät bereitgestellt) besteht aus dem Anbietermanifest und dem ODM-Manifest.

  • Im Anbietermanifest werden HALs, SELinux-Richtlinienversionen usw. für ein SoC angegeben. Es wird empfohlen, es im Android-Quellbaum unter device/VENDOR/DEVICE/manifest.xml zu platzieren. Es können jedoch mehrere Fragmentdateien verwendet werden. Weitere Informationen finden Sie unter Manifest-Fragmente und DM aus Fragmenten generieren.
  • Das ODM-Manifest enthält produktspezifische HALs in der ODM-Partition. Das VINTF-Objekt lädt das ODM-Manifest in dieser Reihenfolge:
    1. Wenn SKU definiert ist (SKU ist der Wert der Property 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
  • Das Anbietermanifest enthält produktspezifische HALs in der Anbieterpartition. Das VINTF-Objekt lädt das Anbietermanifest in dieser Reihenfolge:
    1. Wenn SKU definiert ist (SKU ist der Wert der Property 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 dieser Reihenfolge:
    1. Wenn das Anbietermanifest vorhanden ist, kombinieren Sie Folgendes:
      1. Das Anbietermanifest
      2. Optionale Manifestfragmente von Anbietern
      3. Optionales ODM-Manifest
      4. Optionale ODM-Manifest-Fragmente
    2. Andernfalls, wenn das ODM-Manifest vorhanden ist, kombinieren Sie das ODM-Manifest mit den optionalen ODM-Manifest-Fragmenten.
    3. /vendor/manifest.xml (alt, keine Fragmente)
    4. Kombinieren Sie abschließend Manifestfragmente aus allen APEX-Dateien der Anbieter. Manifestfragmente werden aus dem etc/vintf-Verzeichnis jedes APEX-Objekts (z.B. /apex/<apex name>/etc/vintf) geladen.

    Hinweise:

    • Auf Legacy-Geräten werden das Legacy-Anbietermanifest und das ODM-Manifest verwendet. Das ODM-Manifest kann das alte Anbietermanifest vollständig überschreiben.
    • Auf Geräten, die mit Android 9 eingeführt wurden, wird das ODM-Manifest mit dem Anbietermanifest kombiniert.
    • Wenn du eine Liste von Manifesten kombinierst, können Manifeste, die später in der Liste erscheinen, Tags in Manifesten überschreiben, die früher in der Liste erscheinen, sofern die Tags im späteren Manifest das Attribut override="true" haben. So können im ODM-Manifest beispielsweise einige <hal>-Tags aus dem Anbietermanifest überschrieben werden. Weitere Informationen finden Sie unten in der Dokumentation zum Attribut override.

Mit dieser Konfiguration können mehrere Produkte mit demselben Board dasselbe Anbieter-Image (mit gemeinsamen HALs) verwenden, aber unterschiedliche ODM-Images (mit produktspezifischen HALs) haben.

Hier 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 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 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 finden Sie unter Entwicklung des Gerätemanifests.

Framework-Manifest

Die Manifestdatei des Frameworks besteht aus dem Systemmanifest, dem Produktmanifest und dem Manifest „system_ext“.

  • Das Systemmanifest (von Google bereitgestellt) wird manuell generiert und befindet sich im Android-Quellbaum unter /system/libhidl/manifest.xml.
  • Das vom Gerät bereitgestellte Produktmanifest enthält HALs, die von Modulen bereitgestellt werden, die in der Produktpartition installiert sind.
  • Das vom Gerät bereitgestellte Manifest „system_ext“ enthält Folgendes:
    • HALs, die von Modulen auf der Partition „system_ext“ verwaltet werden;
    • VNDK-Versionen;
    • System-SDK-Version.

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

Hier 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 einen Manifesteintrag einem HAL-Modul im Build-System zuordnen. So lässt sich das HAL-Modul einfacher bedingt in das Build-System einbinden.

Verwendungsbeispiele

Fügen Sie in der Datei Android.bp oder Android.mk jedem Modul, das explizit auf dem Gerät installiert ist, z. B. cc_binary oder rust_binary, vintf_fragments hinzu. Sie können das Modul beispielsweise mit Ihrer HAL-Implementierung (my.package.foo@1.0-service-bar) ändern. 

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

Erstellen Sie in einer Datei mit dem Namen manifest_foo.xml das Manifest für dieses Modul. Dieses Manifest wird dem Gerät während der Buildzeit hinzugefügt. Das Hinzufügen eines Eintrags hier entspricht dem Hinzufügen eines Eintrags im Hauptmanifest des Geräts. So können Clients die Oberfläche verwenden und VTS kann ermitteln, welche HAL-Implementierungen auf dem Gerät vorhanden sind. Dieses Manifest bietet alle Funktionen eines regulären Manifests.

Im folgenden Beispiel wird android.hardware.foo@1.0::IFoo/default implementiert, das in der Partition vendor oder odm installiert wird. Wenn es auf der Partition system, product oder system_ext installiert ist, verwenden Sie den Typ framework anstelle des Typs device. 

<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 APEX des Anbieters verpackt ist, verpacken Sie die zugehörigen VINTF-Fragmente im selben APEX mit prebuilt_etc, wie unter VINTF-Fragmente beschrieben.

Manifestdateischema

In diesem Abschnitt wird die Bedeutung dieser XML-Tags beschrieben. Einige „erforderliche“ Tags können in der Quelldatei im Android-Quellbaum fehlen und werden bei der Buildzeit von assemble_vintf geschrieben. Die erforderlichen Tags müssen in den entsprechenden Dateien auf dem Gerät vorhanden sein.

?xml
Optional. Bietet nur Informationen für den XML-Parser.
manifest.version
Erforderlich. Metaversion dieses Manifests. Hier werden die Elemente beschrieben, die im Manifest erwartet werden. Hat nichts mit der XML-Version zu tun.
manifest.type
Erforderlich. Der Typ dieses Manifests. Er hat den Wert device für die Gerätemanifestdatei und framework für die Framework-Manifestdatei.
manifest.target-level
Erforderlich für das Gerätemanifest. Gibt die Version der Framework Compatibility Matrix (FCM) an, mit der dieses Gerätemanifest kompatibel sein soll. Diese Version wird auch als „ausgelieferte FCM-Version des Geräts“ bezeichnet.
manifest.hal
Optional, kann wiederholt werden. Eine einzelne HAL (HIDL oder nativ, z. B. GL), je nach format-Attribut.
manifest.hal.format
Optional. Folgende Werte sind möglich:
  • hidl: HIDL HALs. Das ist die Standardeinstellung.
  • aidl: AIDL HALs Nur gültig bei Manifest-Metaversion 2.0 und höher.
  • native: Native HALs.
manifest.hal.max-level
Optional. Nur für Framework-Manifeste gültig. Wenn diese Option festgelegt ist, werden HALs mit einer maximalen Ebene, die niedriger als die Ziel-FCM-Version im Framework-Manifest ist, deaktiviert.
manifest.hal.override
Optional. Folgende Werte sind möglich:
  • true: Andere <hal>-Elemente mit derselben <name>- und Hauptversion überschreiben. Wenn dieses <hal>-Element weder <version> noch <fqname> enthält, wird mit dem <hal>-Element angegeben, dass diese HAL deaktiviert ist.
  • false: Überschreiben Sie keine anderen <hal>-Elemente mit derselben <name> und Hauptversion.
manifest.hal.name
Erforderlich. Vollständig qualifizierter Paketname der HAL. Mehrere HAL-Einträge können denselben Namen verwenden. Beispiele:
  • android.hardware.camera (HIDL- oder AIDL-HAL)
  • GLES (native HAL, nur Name erforderlich)
manifest.hal.transport
Erforderlich, wenn manifest.hal.format == "hidl". Andernfalls darf sie NICHT vorhanden sein. Gibt an, welcher Transport verwendet wird, wenn eine Schnittstelle aus diesem Paket vom Dienstmanager abgefragt wird. Folgende Werte sind möglich:
  • hwbinder: Binderized-Modus
  • passthrough: Passthrough-Modus
Optional bei manifest.hal.format == "aidl". Andernfalls darf sie NICHT vorhanden sein. Gibt an, welcher Transport verwendet wird, wenn eine Benutzeroberfläche aus der Ferne bereitgestellt wird. Der Wert muss folgende Anforderungen erfüllen:
  • inet: Inet-Socket
Die manifest.hal.transport.ip und manifest.hal.transport.port müssen verwendet werden, um die Inet-Verbindungsinformationen weiter anzugeben.
manifest.hal.transport.arch
Erforderlich für passthrough und darf für hwbinder nicht vorhanden sein. Beschreibt die Bitanzahl des bereitgestellten Passthrough-Dienstes. Folgende Werte sind möglich:
  • 32: 32-Bit-Modus
  • 64: 64-Bit-Modus
  • 32+64: Beides
manifest.hal.transport.ip
Erforderlich für inet und darf andernfalls NICHT vorhanden sein. Die IP-Adresse, von der aus die Remote-Benutzeroberfläche bereitgestellt wird.
manifest.hal.transport.port
Erforderlich für inet und darf andernfalls NICHT vorhanden sein. Beschreibt den Port, über den die Remote-Benutzeroberfläche bereitgestellt wird.
manifest.hal.version
Optional, kann wiederholt werden. Eine Version für die hal-Tags in einem Manifest.

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

HIDL- und native HALs können mehrere Versionsfelder verwenden, solange sie unterschiedliche Hauptversionen darstellen. Es darf nur eine Nebenversion pro Hauptversion angegeben werden. Beispielsweise können 3.1 und 3.2 nicht gleichzeitig verwendet werden, aber 1.0 und 3.4 schon. Dies gilt für alle hal-Elemente mit demselben Namen, sofern nicht override="true". Die Werte von <version> sind nicht mit <fqname> verknüpft, da <fqname> eine Version hat.

Bei AIDL HALs darf <version> auf Geräten mit Android 11 oder niedriger nicht vorhanden sein. <version> muss auf Geräten mit Android 12 und höher eine einzelne Ganzzahl sein. Für jedes (package, interface, instance)-Tupel darf es höchstens ein <version> geben. Wenn nicht vorhanden, ist der Standardwert 1. Der Wert von <version> ist allen <fqname> in derselben <hal> zugeordnet, da ein <fqname> keine Version hat.
manifest.hal.interface
Erforderlich, kann wiederholt werden, ohne dass Duplikate entstehen. Geben Sie im Paket eine Schnittstelle mit einem Instanznamen an. Ein <hal> kann mehrere <interface>-Elemente enthalten. Die Namen müssen eindeutig sein.
manifest.hal.interface.name
Erforderlich. Name der Schnittstelle.
manifest.hal.interface.instance
Erforderlich, kann wiederholt werden. Instanzname der Schnittstelle. Es können mehrere Instanzen für eine Benutzeroberfläche vorhanden sein, aber keine duplizierten <instance>-Elemente.
manifest.hal.fqname
Optional, kann wiederholt werden. Eine alternative Möglichkeit, eine Instanz für die HAL mit dem Namen manifest.hal.name anzugeben.
  • Für HIDL HALs lautet das Format @MAJOR.MINOR::INTERFACE/INSTANCE.
  • Für AIDL HALs ist das Format INTERFACE/INSTANCE.
manifest.sepolicy
Erforderlich. Enthält alle sepolicy-bezogenen Einträge.
manifest.sepolicy.version
Erforderlich für das Gerätemanifest. Gibt die SELinux-Version an. Sie hat das Format SDK_INT.PLAT_INT.
manifest.vendor-ndk
Erforderlich, kann wiederholt werden; erforderlich für das Framework-Manifest. Darf nicht im Gerätemanifest vorhanden sein. Mehrere <vendor-ndk>-Einträge müssen unterschiedliche <version>s haben. Beschreibt eine Reihe von VNDK-Snapshots, die vom Framework bereitgestellt werden.
manifest.vendor-ndk.version
Erforderlich. Eine positive Ganzzahl, die die Version des VNDK-Snapshots darstellt.
manifest.vendor-ndk.library
Optional, kann wiederholt werden, ohne Duplikate. Beschreibt eine Reihe von VNDK-Bibliotheken, die vom Framework für diesen VNDK-Anbieter-Snapshot bereitgestellt werden. Der Wert ist der Dateiname einer Bibliothek, z.B. libjpeg.so, einschließlich des Präfixes lib und des Suffixes .so. Pfadkomponenten sind nicht zulässig.
manifest.system-sdk.version
Optional, kann wiederholt werden, ohne Duplikate; wird nur vom Framework-Manifest verwendet. Beschreibt eine Reihe von System-SDK-Versionen, die vom Framework für Anbieter-Apps bereitgestellt werden.
manifest.kernel
Optional. Hier werden statische Informationen zum Kernel beschrieben.
manifest.kernel.target-level
Optional. Beschreibt den Kernel-Branch. Wenn der Wert nicht vorhanden ist, wird standardmäßig manifest.target-level verwendet. Muss größer oder gleich manifest.target-level sein. Weitere Informationen finden Sie unter Kernel-Abgleichsregeln.