Un oggetto VINTF aggrega i dati dai file manifest del dispositivo e file manifest del framework (XML). Entrambi i manifest condividono un formato, sebbene non tutti gli elementi si applichino a entrambi (per dettagli sullo schema, vedere Schema del file manifest ).
Manifesto del dispositivo
Il manifesto del dispositivo (fornito dal dispositivo) è costituito dal manifesto del fornitore e dal manifesto dell'ODM.
- Il manifest del fornitore specifica HAL, versioni della policy SELinux, ecc. comuni a un SoC. Si consiglia di inserirlo nell'albero dei sorgenti Android in
device/ VENDOR / DEVICE /manifest.xml
, ma è possibile utilizzare più file di frammenti. Per maggiori dettagli, consulta Manifestare frammenti e Genera DM da frammenti . - Il manifesto ODM elenca gli HAL specifici del prodotto nella partizione ODM . L'oggetto VINTF carica il manifest ODM in questo ordine:
- Se
SKU
è definito (doveSKU
è il valore della proprietàro.boot.product.hardware.sku
),/odm/etc/vintf/manifest_ SKU .xml
-
/odm/etc/vintf/manifest.xml
- Se
SKU
è definito,/odm/etc/manifest_ SKU .xml
-
/odm/etc/manifest.xml
- Se
- Il manifesto del fornitore elenca gli HAL specifici del prodotto nella partizione del fornitore. L'oggetto VINTF carica il manifest del fornitore in questo ordine:
- Se
SKU
è definito (doveSKU
è il valore della proprietàro.boot.product.vendor.sku
),/vendor/etc/vintf/manifest_ SKU .xml
-
/vendor/etc/vintf/manifest.xml
- Se
- L'oggetto VINTF carica il manifest del dispositivo in questo ordine:
- Se il manifest del fornitore esiste, combinare quanto segue:
- Il manifesto del venditore
- Frammenti manifest del fornitore facoltativi
- Manifesto ODM facoltativo
- Frammenti manifest ODM opzionali
- Altrimenti, se il manifest ODM esiste, combina il manifest ODM con i frammenti facoltativi del manifest ODM.
-
/vendor/manifest.xml
(legacy, senza frammenti)
Notare che:
- Sui dispositivi legacy vengono utilizzati il manifest del fornitore legacy e il manifest dell'ODM. Il manifest ODM può sovrascrivere completamente il manifest del fornitore legacy.
- Sui dispositivi lanciati con Android 9, il manifest ODM è combinato con il manifest del fornitore.
- Quando si combina un elenco di manifesti, i manifesti che appaiono più avanti nell'elenco possono sovrascrivere i tag nei manifesti che appaiono prima nell'elenco, a condizione che i tag nel manifesto successivo abbiano l'attributo
override="true"
. Ad esempio, il manifest ODM potrebbe sovrascrivere alcuni tag<hal>
del manifest del fornitore. Consulta la documentazione peroverride
degli attributi di seguito.
- Se il manifest del fornitore esiste, combinare quanto segue:
Questa configurazione consente a più prodotti con la stessa scheda di condividere la stessa immagine del fornitore (che fornisce HAL comuni) ma di avere immagini ODM diverse (che specificano HAL specifici del prodotto).
Ecco un esempio di manifest del fornitore.
<?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>
Ecco un esempio di manifest ODM.
<?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>
Ecco un esempio di manifest del dispositivo in un pacchetto OTA.
<?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>
Per ulteriori dettagli, consulta Sviluppo del manifesto del dispositivo .
Manifesto del quadro
Il file manifest del framework è costituito dal manifesto del sistema, dal manifesto del prodotto e dal manifesto system_ext.
- Il manifest del sistema (fornito da Google) viene generato manualmente e si trova nell'albero dei sorgenti Android in
/system/libhidl/manifest.xml
. - Il manifesto del prodotto (fornito dal dispositivo) elenca gli HAL serviti dai moduli installati nella partizione del prodotto.
- Il manifest system_ext (fornito dal dispositivo) elenca quanto segue:
- HAL serviti dai moduli installati sulla partizione system_ext;
- Versioni VNDK;
- Versione dell'SDK di sistema.
Analogamente al manifest del dispositivo, è possibile utilizzare più file di frammenti. Per maggiori dettagli, consulta Frammenti manifest .
Ecco un manifesto del framework di esempio.
<?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>
Frammenti manifesti
In Android 10 e versioni successive, puoi associare una voce manifest a un modulo HAL nel sistema di build. Ciò semplifica l'inclusione condizionale del modulo HAL nel sistema di compilazione.
Esempio
Nel tuo file Android.bp
o Android.mk
, aggiungi vintf_fragments
a qualsiasi modulo. Ad esempio, puoi modificare il modulo con l'implementazione del tuo HAL ( my.package.foo@1.0-service-bar
).
... { ... vintf_fragments: ["manifest_foo.xml"], ... }
LOCAL_MODULE := ... LOCAL_VINTF_FRAGMENTS := manifest_foo.xml
In un file chiamato manifest_foo.xml
, crea il manifest per questo modulo. In fase di compilazione, questo manifest viene aggiunto al dispositivo. Aggiungere una voce qui equivale ad aggiungere una voce nel manifest principale del dispositivo. Ciò consente ai client di utilizzare l'interfaccia e consente a VTS di identificare quali implementazioni HAL sono presenti sul dispositivo. Tutto ciò che fa un manifest regolare, lo fa anche questo manifest.
L'esempio seguente implementa android.hardware.foo@1.0::IFoo/default
, che è installato nella partizione vendor
o odm
. Se è installato nella partizione system
, product
o system_ext
, utilizza il tipo framework
anziché il tipo 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>
Se un modulo HAL è confezionato in un fornitore APEX , confezionare i frammenti VINTF associati all'interno dello stesso APEX con `prebuilt_etc` come spiegato in Frammenti VINTF .
Schema del file manifesto
Questa sezione descrive il significato di questi tag XML. Alcuni tag "richiesti" potrebbero mancare nel file sorgente nell'albero dei sorgenti Android e scritti da assemble_vintf
in fase di compilazione. I tag richiesti devono essere presenti nei file corrispondenti sul dispositivo.
-
?xml
- Opzionale. Fornisce solo informazioni al parser XML.
-
manifest.version
- Necessario. Meta-versione di questo manifest. Descrive gli elementi previsti nel manifest. Non correlato alla versione XML.
-
manifest.type
- Necessario. Tipo di questo manifesto. Ha il valore
device
per il file manifesto del dispositivo eframework
per il file manifesto del framework. -
manifest.target-level
- Obbligatorio per il manifesto del dispositivo. Specifica la versione della matrice di compatibilità del framework (FCM) con cui è previsto che questo manifesto del dispositivo sia compatibile. Questa è anche chiamata versione FCM di spedizione del dispositivo.
-
manifest.hal
- Facoltativo, può ripetere. Un singolo HAL (HIDL o nativo, come GL), a seconda dell'attributo
format
. -
manifest.hal.format
- Opzionale. Il valore può essere uno tra:
-
hidl
: HAL HIDL. Questa è l'impostazione predefinita. -
aidl
: HAL AIDL . Valido solo nella meta-versione manifest 2.0 e successive. -
native
: HAL nativi.
-
-
manifest.hal.max-level
- Opzionale. Valido solo sui manifest del framework. Se impostati, gli HAL con un livello massimo inferiore alla versione FCM di destinazione nel manifest del framework vengono disabilitati.
-
manifest.hal.override
- Opzionale. Il valore può essere uno tra:
-
true
: sovrascrive altri elementi<hal>
con lo stesso<name>
e la stessa versione principale. Se non ci sono<version>
o<fqname>
in questo elemento<hal>
, allora l'elemento<hal>
dichiara che questo HAL è disabilitato. -
false
: non sovrascrive altri elementi<hal>
con lo stesso<name>
e la stessa versione principale.
-
-
manifest.hal.name
- Necessario. Nome del pacchetto completo dell'HAL. Più voci HAL possono utilizzare lo stesso nome. Esempi:
-
android.hardware.camera
(HIDL o AIDL HAL) -
GLES
(HAL nativo, richiede solo il nome)
-
-
manifest.hal.transport
- Obbligatorio quando
manifest.hal.format == "hidl"
. NON deve essere presente altrimenti. Indica quale trasporto viene utilizzato quando un'interfaccia di questo pacchetto viene interrogata dal gestore del servizio. Il valore può essere uno tra:-
hwbinder
: modalità Binderizzata -
passthrough
: modalità passthrough
-
- Facoltativo quando
manifest.hal.format == "aidl"
. NON deve essere presente altrimenti. Indica quale trasporto viene utilizzato quando un'interfaccia viene servita in remoto. Il valore deve essere:-
inet
: presa Inet
manifest.hal.transport.ip
emanifest.hal.transport.port
devono essere utilizzati per specificare ulteriormente le informazioni sulla connessione Inet. -
-
manifest.hal.transport.arch
- Richiesto per
passthrough
e non deve essere presente perhwbinder
. Descrive la struttura del servizio passthrough fornito. Il valore può essere uno tra:-
32
: modalità a 32 bit -
64
: modalità a 64 bit -
32+64
: Entrambi
-
-
manifest.hal.transport.ip
- Obbligatorio per
inet
e NON deve essere presente altrimenti. Descrive l'indirizzo IP da cui viene servita l'interfaccia remota. -
manifest.hal.transport.port
- Obbligatorio per
inet
e NON deve essere presente altrimenti. Descrive la porta da cui viene servita l'interfaccia remota. -
manifest.hal.version
- Facoltativo, può ripetere. Una versione per i tag
hal
in un manifest.
Per HIDL e HAL nativi, il formato èMAJOR . MINOR
. Ad esempio, fare riferimento ahardware/interfaces
,vendor/${VENDOR}/interfaces
,frameworks/hardware/interfaces
osystem/hardware/interfaces
.
HIDL e HAL nativi possono utilizzare più campi di versione purché rappresentino versioni principali distinte , con una sola versione secondaria per versione principale fornita. Ad esempio, 3.1 e 3.2 non possono coesistere, ma 1.0 e 3.4 sì. Questo si applica a tutti gli elementihal
con lo stesso nome, a meno cheoverride="true"
. I valori di<version>
non sono associati a<fqname>
perché<fqname>
contiene una versione.
Per gli HAL AIDL,<version>
non deve essere presente sui dispositivi che eseguono Android 11 e versioni precedenti.<version>
deve essere un singolo numero intero sui dispositivi con Android 12 e versioni successive. Deve essere presente al massimo una<version>
per ciascuna tupla(package, interface, instance)
. Se non presente, il valore predefinito è1
. Il valore di<version>
è associato a tutti<fqname>
nello stesso<hal>
perché un<fqname>
non contiene una versione. -
manifest.hal.interface
- Obbligatorio, può ripetere senza duplicati. Indica un'interfaccia nel pacchetto che ha un nome di istanza. Possono esserci più elementi
<interface>
in un<hal>
; i nomi devono essere distinti. -
manifest.hal.interface.name
- Necessario. Nome dell'interfaccia.
-
manifest.hal.interface.instance
- Richiesto, può ripetere. Nome dell'istanza dell'interfaccia. Può avere più istanze per un'interfaccia ma nessun elemento
<instance>
duplicato. -
manifest.hal.fqname
- Facoltativo, può ripetere. Un modo alternativo per specificare un'istanza per l'HAL con il nome
manifest.hal.name
.- Per gli HAL HIDL, il formato è
@ MAJOR . MINOR :: INTERFACE / INSTANCE
. - Per gli HAL AIDL, il formato è
INTERFACE / INSTANCE
.
- Per gli HAL HIDL, il formato è
-
manifest.sepolicy
- Necessario. Contiene tutte le voci relative alla sepolicy.
-
manifest.sepolicy.version
- Obbligatorio per il manifesto del dispositivo. Dichiara la versione di SELinux. Ha il formato
SDK_INT . PLAT_INT
. -
manifest.vendor-ndk
- Richiesto, può ripetere; richiesto per il manifesto del framework. Non deve essere presente nel manifest del dispositivo. Più voci
<vendor-ndk>
devono avere<version>
diverse. Descrive una serie di snapshot VNDK forniti dal framework. -
manifest.vendor-ndk.version
- Necessario. Questo è un numero intero positivo che rappresenta la versione dello snapshot VNDK.
-
manifest.vendor-ndk.library
- Facoltativo, può ripetere, senza duplicati. Descrive un set di librerie VNDK fornite dal framework per questo snapshot del fornitore VNDK. Il valore è il nome file di una libreria, ad esempio
libjpeg.so
, incluso il prefissolib
e il suffisso.so
. Non sono consentiti componenti del percorso. -
manifest.system-sdk.version
- Facoltativo, può ripetersi, senza duplicati; utilizzato solo dal manifest del framework. Descrive un set di versioni dell'SDK di sistema fornite dal framework alle app del fornitore.
-
manifest.kernel
- Opzionale. Descrive le informazioni statiche sul kernel.
-
manifest.kernel.target-level
- Opzionale. Descrive il ramo del kernel. Il suo valore predefinito è
manifest.target-level
se non presente. Deve essere maggiore o uguale amanifest.target-level
. Vedi le regole di corrispondenza del kernel per i dettagli.