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:
- Wenn
SKU
definiert ist (wobeiSKU
der Wert der Eigenschaftro.boot.product.hardware.sku
ist),/odm/etc/vintf/manifest_ SKU .xml
-
/odm/etc/vintf/manifest.xml
- Wenn
SKU
definiert ist,/odm/etc/manifest_ SKU .xml
-
/odm/etc/manifest.xml
- Wenn
- 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:
- Wenn
SKU
definiert ist (wobeiSKU
der Wert der Eigenschaftro.boot.product.vendor.sku
ist),/vendor/etc/vintf/manifest_ SKU .xml
-
/vendor/etc/vintf/manifest.xml
- Wenn
- Das VINTF-Objekt lädt das Gerätemanifest in dieser Reihenfolge:
- Wenn das Anbietermanifest vorhanden ist, kombinieren Sie Folgendes:
- Das Anbietermanifest
- Optionale Anbietermanifestfragmente
- Optionales ODM-Manifest
- Optionale ODM-Manifestfragmente
- Andernfalls, wenn das ODM-Manifest vorhanden ist, kombinieren Sie das ODM-Manifest mit den optionalen ODM-Manifestfragmenten.
-
/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 zuroverride
unten.
- Wenn das Anbietermanifest vorhanden ist, kombinieren Sie Folgendes:
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 undframework
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
undmanifest.hal.transport.port
müssen verwendet werden, um die Inet-Verbindungsinformationen weiter anzugeben. -
-
manifest.hal.transport.arch
- Erforderlich für
passthrough
und darf fürhwbinder
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 FormatMAJOR . MINOR
. Beispiele finden Sie unterhardware/interfaces
,vendor/${VENDOR}/interfaces
,frameworks/hardware/interfaces
odersystem/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 gleichnamigenhal
Elemente, sofern nichtoverride="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äßig1
. 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
.
- Für HIDL-HALs ist das Format
-
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äfixeslib
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 gleichmanifest.target-level
. Siehe Kernel-Match-Regeln für Details.