Manifeste

Ein VINTF-Objekt aggregiert Daten aus Gerätemanifest- und Framework- Manifestdateien (XML). Beide Manifeste haben ein gemeinsames Format, allerdings gelten nicht alle Elemente für beide (Einzelheiten zum Schema finden Sie unter Schema der Manifestdatei ).

Gerätemanifest

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

  • Das Herstellermanifest gibt HALs, SELinux-Richtlinienversionen usw. an, die einem SoC gemeinsam sind. Es wird empfohlen, es im Android-Quellbaum unter device/ VENDOR / DEVICE /manifest.xml zu platzieren, es können jedoch mehrere Fragmentdateien verwendet werden. Einzelheiten finden Sie unter Manifestieren von Fragmenten und Generieren von DM aus Fragmenten .
  • Das ODM-Manifest listet HALs auf, die für das Produkt in der ODM-Partition spezifisch sind. Das VINTF-Objekt lädt das ODM-Manifest in dieser Reihenfolge:
    1. Wenn SKU definiert ist (wobei SKU der Wert der Eigenschaft ro.boot.product.hardware.sku ist), /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 Herstellermanifest listet HALs auf, die für das Produkt in der Anbieterpartition spezifisch sind. Das VINTF-Objekt lädt das Anbietermanifest in dieser Reihenfolge:
    1. Wenn SKU definiert ist (wobei SKU der Wert der Eigenschaft ro.boot.product.vendor.sku ist), /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 Anbietermanifestfragmente
      3. Optionales ODM-Manifest
      4. Optionale ODM-Manifestfragmente
    2. Andernfalls, wenn das ODM-Manifest vorhanden ist, kombinieren Sie das ODM-Manifest mit den optionalen ODM-Manifestfragmenten.
    3. /vendor/manifest.xml (Legacy, keine Fragmente)

    Beachten Sie, dass:

    • Auf Legacy-Geräten werden das Legacy-Vendor-Manifest und das ODM-Manifest verwendet. Das ODM-Manifest kann das Manifest des alten Anbieters vollständig überschreiben.
    • Auf Geräten, die mit Android 9 gestartet wurden, wird das ODM-Manifest mit dem Herstellermanifest kombiniert.
    • Beim Kombinieren einer Liste von Manifesten können Manifeste, die später in der Liste erscheinen, Tags in Manifesten überschreiben, die weiter oben in der Liste erscheinen, vorausgesetzt, dass die Tags im späteren Manifest das Attribut override="true" haben. Beispielsweise kann das ODM-Manifest einige <hal> -Tags aus dem Herstellermanifest überschreiben. Weitere Informationen zur override finden Sie weiter unten in der Dokumentation.

Dieses Setup ermöglicht es mehreren Produkten mit derselben Platine, dasselbe Hersteller-Image zu verwenden (das gemeinsame HALs bereitstellt), jedoch über unterschiedliche ODM-Images zu verfügen (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 Einzelheiten finden Sie unter Entwicklung von Gerätemanifesten .

Framework-Manifest

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

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

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

Hier ist ein Beispiel-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>

Manifeste Fragmente

In Android 10 und höher können Sie einen Manifesteintrag mit einem HAL-Modul im Build-System verknüpfen. Dies erleichtert die bedingte Einbindung des HAL-Moduls in das Build-System.

Beispiel

Fügen Sie in Ihrer Android.bp oder Android.mk Datei vintf_fragments zu einem beliebigen Modul hinzu. Beispielsweise können Sie das Modul mit Ihrer Implementierung Ihres HAL ( 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 namens manifest_foo.xml das Manifest für dieses Modul. Zur Erstellungszeit wird dieses Manifest dem Gerät hinzugefügt. Das Hinzufügen eines Eintrags hier entspricht dem Hinzufügen eines Eintrags im Hauptmanifest des Geräts. Dadurch können Clients die Schnittstelle nutzen und VTS kann erkennen, welche HAL-Implementierungen auf dem Gerät vorhanden sind. Alles, was ein reguläres Manifest tut, tut auch dieses Manifest.

Das folgende Beispiel implementiert android.hardware.foo@1.0::IFoo/default , das auf der vendor oder odm -Partition 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>

Manifestdateischema

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

?xml
Optional. Stellt nur Informationen für den XML-Parser bereit.
manifest.version
Erforderlich. Metaversion dieses Manifests. Beschreibt die im Manifest erwarteten Elemente. Hat nichts mit der XML-Version zu tun.
manifest.type
Erforderlich. Typ dieses Manifests. Es 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 FCM-Version (Framework Compatibility Matrix) an, mit der dieses Gerätemanifest kompatibel sein soll. Dies wird auch als Versand-FCM-Version des Geräts bezeichnet.
manifest.hal
Optional, kann wiederholt werden. Ein einzelnes HAL (HIDL oder nativ, z. B. GL), abhängig vom format .
manifest.hal.format
Optional. Der Wert kann einer der folgenden sein:
  • hidl : HIDL-HALs. Dies 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 gültig für Framework-Manifeste. Wenn festgelegt, werden HALs mit einer maximalen Ebene, die niedriger als die Ziel-FCM-Version im Framework-Manifest ist, deaktiviert.
manifest.hal.override
Optional. Der Wert kann einer der folgenden sein:
  • true : Überschreiben Sie andere <hal> -Elemente mit demselben <name> und derselben Hauptversion. Wenn in diesem <hal> -Element kein <version> oder <fqname> vorhanden ist, deklariert das <hal> -Element dieses HAL als deaktiviert.
  • false : Überschreiben Sie keine anderen <hal> -Elemente mit demselben <name> und derselben Hauptversion.
manifest.hal.name
Erforderlich. Vollqualifizierter Paketname des HAL. Mehrere HAL-Einträge können denselben Namen verwenden. Beispiele:
  • android.hardware.camera (HIDL oder AIDL HAL)
  • GLES (natives HAL, erfordert nur Namen)
manifest.hal.transport
Erforderlich, wenn manifest.hal.format == "hidl" . Darf sonst NICHT vorhanden sein. Gibt an, welcher Transport verwendet wird, wenn eine Schnittstelle aus diesem Paket vom Dienstmanager abgefragt wird. Der Wert kann einer der folgenden sein:
  • hwbinder : Binderisierter Modus
  • passthrough : Passthrough-Modus
Optional, wenn manifest.hal.format == "aidl" . Darf sonst NICHT vorhanden sein. Gibt an, welcher Transport verwendet wird, wenn eine Schnittstelle remote bedient wird. Der Wert muss sein:
  • inet : Inet-Socket
Zur weiteren Angabe der Inet-Verbindungsinformationen müssen manifest.hal.transport.ip und manifest.hal.transport.port verwendet werden.
manifest.hal.transport.arch
Erforderlich für passthrough und darf für hwbinder nicht vorhanden sein. Beschreibt die Bitzahl des bereitgestellten Passthrough-Dienstes. Der Wert kann einer der folgenden sein:
  • 32 : 32-Bit-Modus
  • 64 : 64-Bit-Modus
  • 32+64 : Beides
manifest.hal.transport.ip
Erforderlich für inet und darf ansonsten NICHT vorhanden sein. Beschreibt die IP-Adresse, von der aus die Remote-Schnittstelle bedient wird.
manifest.hal.transport.port
Erforderlich für inet und darf ansonsten NICHT vorhanden sein. Beschreibt den Port, von dem aus die Remote-Schnittstelle bedient 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 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 unterschiedliche Hauptversionen darstellen, wobei nur eine Nebenversion pro Hauptversion bereitgestellt wird. Beispielsweise können 3.1 und 3.2 nicht nebeneinander existieren, 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 mit <fqname> verknüpft, da ein <fqname> eine Version enthält.

Für AIDL-HALs darf <version> auf Geräten mit Android 11 und niedriger nicht vorhanden sein. <version> muss auf Geräten mit Android 12 und höher eine einzelne Ganzzahl sein. Für jedes Tupel (package, interface, instance) darf es höchstens eine <version> geben. Wenn nicht vorhanden, wird standardmäßig 1 verwendet. Der Wert von <version> ist allen <fqname> in derselben <hal> zugeordnet, da ein <fqname> keine Version enthält.
manifest.hal.interface
Erforderlich, kann ohne Duplikate wiederholt werden. Geben Sie im Paket eine Schnittstelle an, die einen Instanznamen hat. Es kann mehrere <interface> -Elemente in einem <hal> geben; 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 haben, 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 ist 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. Deklariert die SELinux-Version. Es hat das Format SDK_INT . PLAT_INT .
manifest.vendor-ndk
Erforderlich, kann wiederholt werden; für das Framework-Manifest erforderlich. 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. Dies ist eine positive Ganzzahl, die die Version des VNDK-Snapshots darstellt.
manifest.vendor-ndk.library
Optional, kann ohne Duplikate wiederholt werden. 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 . Es sind keine Pfadkomponenten zulässig.
manifest.system-sdk.version
Optional, kann ohne Duplikate wiederholt werden; 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. Beschreibt statische Informationen über den Kernel.
manifest.kernel.target-level
Optional. Beschreibt den Kernel-Zweig. Sein Wert ist standardmäßig manifest.target-level wenn er nicht vorhanden ist. Muss größer oder gleich manifest.target-level sein. Weitere Informationen finden Sie unter Kernel-Match-Regeln .