Manifeste

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Ein VINTF-Objekt aggregiert Daten aus Gerätemanifest- und Frameworkmanifestdateien (XML). Beide Manifeste haben ein gemeinsames Format, obwohl nicht alle Elemente für beide gelten (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, aber mehrere Fragmentdateien können verwendet werden. Einzelheiten finden Sie unter Manifestfragmente und DM aus Fragmenten generieren .
  • 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 Herstellerpartition 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-Anbietermanifest und das ODM-Manifest verwendet. Das ODM-Manifest kann das Legacy-Lieferantenmanifest 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 früher 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 Anbietermanifest überschreiben. Siehe die Dokumentation zur override unten.

Dieses Setup ermöglicht es mehreren Produkten mit derselben Platine, dasselbe Anbieter-Image (das gemeinsame HALs bereitstellt) gemeinsam zu nutzen, jedoch unterschiedliche ODM-Images zu haben (die produktspezifische HALs spezifizieren).

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 Gerätemanifestentwicklung .

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 Manifest system_ext (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>

Fragmente manifestieren

In Android 10 und höher können Sie einen Manifesteintrag einem HAL-Modul im Buildsystem zuordnen. Dadurch wird es einfacher, das HAL-Modul bedingt in das Build-System aufzunehmen.

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 Ihrer HAL ( my.package.foo@1.0-service-bar ) modifizieren.

... {
    ...
    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 Buildzeit 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 verwenden und VTS erkennen, welche HAL-Implementierungen sich auf dem Gerät befinden. Alles, was ein reguläres Manifest tut, tut dieses Manifest auch.

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 type framework anstelle von type 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>

Schema der Manifestdatei

Dieser Abschnitt beschreibt die Bedeutung dieser XML-Tags. Einige „erforderliche“ Tags können in der Quelldatei in der Android-Quellstruktur fehlen und zur Erstellungszeit von assemble_vintf 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. Meta-Version dieses Manifests. Beschreibt die im Manifest erwarteten Elemente. Unabhängig von der XML-Version.
manifest.type
Erforderlich. Typ dieses Manifests. Es hat den Wert device für die Gerätemanifestdatei und framework für die Frameworkmanifestdatei.
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. Dies wird auch als Versand-FCM-Version des Geräts bezeichnet.
manifest.hal
Optional, kann wiederholt werden. Eine einzelne 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 kein <version> oder <fqname> in diesem <hal> -Element enthalten ist, dann erklärt das <hal> -Element diese HAL als deaktiviert.
  • false : Keine anderen <hal> -Elemente mit demselben <name> und derselben Hauptversion überschreiben.
manifest.hal.name
Erforderlich. Vollqualifizierter Paketname der HAL. Mehrere HAL-Einträge können denselben Namen verwenden. Beispiele:
  • android.hardware.camera (HIDL oder AIDL HAL)
  • GLES (natives HAL, erfordert nur den 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
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. Der Wert kann einer der folgenden sein:
  • 32 : 32-Bit-Modus
  • 64 : 64-Bit-Modus
  • 32+64 : Beides
manifest.hal.transport.ip
Wird für inet und darf sonst NICHT vorhanden sein. Beschreibt die IP-Adresse, von der die Remoteschnittstelle bedient wird.
manifest.hal.transport.port
Wird für inet und darf sonst NICHT vorhanden sein. Beschreibt den Port, von dem aus die Remoteschnittstelle 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 koexistieren, aber 1.0 und 3.4 schon. Dies gilt für alle gleichnamigen hal Elemente, sofern nicht override="true" . Die Werte von <version> sind nicht mit <fqname> da ein <fqname> eine Version enthält.

Für AIDL HALs darf <version> auf Geräten mit Android 11 und darunter nicht vorhanden sein. <version> muss auf Geräten mit Android 12 und höher eine einzelne ganze Zahl sein. Es darf höchstens eine <version> für jedes Tupel (package, interface, instance) geben. Wenn nicht vorhanden, standardmäßig 1 . Der Wert von <version> wird allen <fqname> in derselben <hal> zugeordnet, da ein <fqname> keine Version trägt.
manifest.hal.interface
Erforderlich, kann ohne Duplikate wiederholt werden. Geben Sie eine Schnittstelle im Paket an, die einen Instanznamen hat. Es können mehrere <interface> Elemente in einem <hal> sein; 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; erforderlich für das Framework-Manifest. Darf nicht im Gerätemanifest vorhanden sein. Mehrere <vendor-ndk> 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 ganze Zahl, 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 Snapshot des VNDK-Anbieters bereitgestellt werden. Der Wert ist der Dateiname einer Bibliothek, zB libjpeg.so , einschließlich des Präfixes lib und des Suffixes .so . Es sind keine Pfadkomponenten 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. Beschreibt statische Informationen über den Kernel.
manifest.kernel.target-level
Optional. Beschreibt den Kernel-Zweig. Sein Wert ist standardmäßig manifest.target-level falls nicht vorhanden. Muss größer oder gleich manifest.target-level . Siehe Kernel-Match-Regeln für Details.