Fichiers manifestes

Un objet VINTF agrège les données de l'appareil fichiers manifestes et fichiers manifestes du framework (XML). Les deux les fichiers manifestes ont le même format, bien que tous les éléments ne s'appliquent pas aux deux (pour en savoir plus sur le schéma, consultez la section Schéma du fichier manifeste).

Fichier manifeste de l'appareil

Le fichier manifeste de l'appareil (fourni par l'appareil) se compose du fichier manifeste du fournisseur. et le fichier manifeste ODM.

  • Le fichier manifeste du fournisseur spécifie les HAL, les versions de règles SELinux, etc. communs à un SoC. Il il est recommandé de le placer dans l'arborescence source Android à l'adresse device/VENDOR/DEVICE/manifest.xml, mais plusieurs fragments fichiers peuvent être utilisés. Pour en savoir plus, consultez Fragments du fichier manifeste et Générer MP à partir de fragments
  • Le fichier manifeste ODM répertorie les HAL spécifiques au produit dans les Partition ODM. L'objet VINTF charge le fichier manifeste ODM dans cet ordre: <ph type="x-smartling-placeholder">
      </ph>
    1. Si SKU est défini (où SKU est la valeur de la propriété ro.boot.product.hardware.sku), /odm/etc/vintf/manifest_SKU.xml
    2. /odm/etc/vintf/manifest.xml
    3. Si SKU est défini, /odm/etc/manifest_SKU.xml
    4. /odm/etc/manifest.xml
  • Le fichier manifeste du fournisseur répertorie les HAL spécifiques au produit dans la partition des fournisseurs. L'objet VINTF charge le fichier manifeste du fournisseur dans cet ordre: <ph type="x-smartling-placeholder">
      </ph>
    1. Si SKU est défini (où SKU est la valeur de la propriété ro.boot.product.vendor.sku), /vendor/etc/vintf/manifest_SKU.xml
    2. /vendor/etc/vintf/manifest.xml
  • L'objet VINTF charge le fichier manifeste de l'appareil dans cet ordre: <ph type="x-smartling-placeholder">
      </ph>
    1. Si le fichier manifeste du fournisseur existe, combinez les éléments suivants: <ph type="x-smartling-placeholder">
        </ph>
      1. Fichier manifeste du fournisseur
      2. Fragments de fichier manifeste de fournisseur facultatifs
      3. Fichier manifeste ODM facultatif
      4. Fragments de fichier manifeste ODM facultatifs
    2. Sinon, si le fichier manifeste ODM existe, combinez-le avec l'ODM facultatif. fragments du fichier manifeste.
    3. /vendor/manifest.xml (ancien, aucun fragment)
    4. Enfin, combinez les fragments de manifestes de n'importe quel fournisseur APEX.

    Gardez à l'esprit les points suivants :

    • Sur les anciens appareils, le fichier manifeste de l'ancien fournisseur et celui de l'ODM sont utilisés. La Le fichier manifeste de l'ODM peut remplacer complètement le fichier manifeste de l'ancien fournisseur.
    • Sur les appareils lancés avec Android 9, le fichier manifeste ODM est combiné avec le fichier manifeste du fournisseur.
    • Lorsque vous combinez une liste de fichiers manifestes, ceux qui apparaissent plus tard dans la liste peuvent remplacer dans les fichiers manifestes qui apparaissent plus tôt dans la liste, à condition qu'elles apparaissent dans le fichier manifeste comportent l'attribut override="true". Par exemple, le fichier manifeste ODM peut remplacer certaines balises <hal> du fichier manifeste du fournisseur. Consultez la documentation pour l'attribut override ci-dessous.

Cette configuration permet à plusieurs produits d'un même tableau de partager du fournisseur (qui fournit des HAL communes), mais des images ODM différentes (qui spécifier des HAL spécifiques aux produits).

Voici un exemple de fichier manifeste de fournisseur.

<?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>

Voici un exemple de fichier manifeste 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>

Voici un exemple de fichier manifeste d'appareil dans un package 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>

Pour en savoir plus, consultez la section Fichier manifeste de l'appareil Développement.

Fichier manifeste du framework

Le fichier manifeste du framework comprend le fichier manifeste du système, le fichier manifeste du produit le fichier manifeste system_ext.

  • Le fichier manifeste système (fourni par Google) est généré manuellement et se trouve dans l'arborescence source Android /system/libhidl/manifest.xml
  • Le fichier manifeste du produit (fourni par l'appareil) liste les HAL traitées par les modules installés sur le la partition des produits.
  • Le fichier manifeste system_ext (fourni par l'appareil) répertorie les éléments suivants: <ph type="x-smartling-placeholder">
      </ph>
    • HAL gérés par les modules installés sur la partition system_ext.
    • Versions du VNDK
    • Version du SDK système.

Comme pour le fichier manifeste de l'appareil, vous pouvez utiliser plusieurs fichiers de fragment. Pour en savoir plus, consultez Fragments du fichier manifeste.

Voici un exemple de fichier manifeste de framework.

<?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>

Fragments du fichier manifeste

Sous Android 10 ou version ultérieure, vous pouvez associer un fichier manifeste par un module HAL dans le système de compilation. Il est ainsi plus facile de inclure de manière conditionnelle le module HAL dans le système de compilation.

Exemple

Dans votre fichier Android.bp ou Android.mk, ajoutez vintf_fragments à n'importe quel module. Par exemple, vous pouvez modifier le module avec votre implémentation de l'algorithme HAL (my.package.foo@1.0-service-bar). 

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

Dans un fichier nommé manifest_foo.xml, créez le fichier manifeste pour dans ce module. Au moment de la compilation, ce fichier manifeste est ajouté à l'appareil. Ajout... une entrée ici revient à ajouter une entrée dans le fichier manifeste principal de l'appareil. Cela permet aux clients d'utiliser l'interface et à VTS d'identifier quel HAL implémentations sont sur l'appareil. Tout ce qui est dans un fichier manifeste standard le cas échéant, ce fichier manifeste le fait également.

L'exemple ci-dessous met en œuvre android.hardware.foo@1.0::IFoo/default, qui est installé dans la partition vendor ou odm. S'il est installé sur Partition system, product ou system_ext, utilisez le type framework au lieu de saisissez 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>

Si un module HAL est inclus dans un apex de fournisseur, empaqueter les fragments VINTF associés dans le même APEX avec prebuilt_etc expliqué dans la section Fragments VINTF.

Schéma du fichier manifeste

Cette section décrit la signification de ces balises XML. Certaines valeurs "obligatoires" tags peut être absente du fichier source de l'arborescence source Android et écrite par assemble_vintf au moment de la compilation. Les balises requises doivent être présentes dans les fichiers correspondants sur le appareil.

?xml
Facultatif. Fournit uniquement des informations à l'analyseur XML.
manifest.version
Obligatoire. Métaversion de ce fichier manifeste. Décrit les attendus dans le fichier manifeste. Sans rapport avec la version XML.
manifest.type
Obligatoire. Type de ce fichier manifeste. Il a la valeur device pour le fichier manifeste de l'appareil et framework pour le fichier manifeste du framework .
manifest.target-level
Obligatoire pour le fichier manifeste de l'appareil. Spécifie la matrice de compatibilité du framework (FCM) cible de la compatibilité du fichier manifeste de l'appareil . Également appelée version FCM de livraison de l'appareil.
manifest.hal
Facultatif, peut être répété. Un seul HAL (HIDL ou natif, tel que GL) en fonction de l'attribut format.
manifest.hal.format
Facultatif. Les valeurs possibles sont les suivantes: <ph type="x-smartling-placeholder">
    </ph>
  • hidl: HIDL HAL. Il s'agit de l'option par défaut.
  • aidl: HAL AIDL. Uniquement valide dans la méta-version 2.0 ou ultérieure du fichier manifeste.
  • native: HAL natives.
manifest.hal.max-level
Facultatif. N'est valide que sur les fichiers manifestes de framework. S'il est défini, les HAL avec un niveau maximal inférieur que la version FCM cible dans le fichier manifeste du framework sont désactivées.
manifest.hal.override
Facultatif. Les valeurs possibles sont les suivantes: <ph type="x-smartling-placeholder">
    </ph>
  • true: remplacez les autres éléments <hal> par le même <name> et la même version majeure. Si non <version> ou <fqname> se trouvent dans cette l'élément <hal>, puis l'élément <hal>. déclare que ce HAL est désactivé.
  • false: ne pas remplacer les autres éléments <hal> avec le même <name> et la même version majeure.
manifest.hal.name
Obligatoire. Nom de package complet du HAL. Plusieurs entrées HAL peuvent utiliser le même nom. Exemples: <ph type="x-smartling-placeholder">
    </ph>
  • android.hardware.camera (HIDL ou AIDL HAL)
  • GLES (HAL natif, nom uniquement requis)
manifest.hal.transport
Obligatoire lorsque manifest.hal.format == "hidl". Ne doit PAS être autrement. Indique quel transport est utilisé lorsqu'une interface de ce package est interrogé depuis le gestionnaire de services. Les valeurs possibles sont les suivantes: <ph type="x-smartling-placeholder">
    </ph>
  • hwbinder: mode Binderized
  • passthrough: mode passthrough
Facultatif lorsque manifest.hal.format == "aidl". Ne doit PAS être autrement. Indique quel moyen de transport est utilisé lorsqu'une interface est desservie à distance. Cette valeur doit être: <ph type="x-smartling-placeholder">
    </ph>
  • inet: socket Inet
manifest.hal.transport.ip et manifest.hal.transport.port doit être utilisé pour spécifier davantage les informations de connexion Inet.
manifest.hal.transport.arch
Obligatoire pour passthrough et ne doit pas être présent pour hwbinder Décrit le débit du service passthrough faisant l'objet fournies. Les valeurs possibles sont les suivantes: <ph type="x-smartling-placeholder">
    </ph>
  • 32: mode 32 bits
  • 64: mode 64 bits
  • 32+64: les deux
manifest.hal.transport.ip
Obligatoire pour inet et ne doit PAS être présent dans les autres cas. Décrit l'adresse IP à partir duquel l'interface distante est servie.
manifest.hal.transport.port
Obligatoire pour inet et ne doit PAS être présent dans les autres cas. Décrit le port depuis dans laquelle l'interface distante est diffusée.
manifest.hal.version
Facultatif, peut être répété. Une version des tags hal dans un fichier manifeste.

Pour les HAL natives et HIDL, le format est le suivant : MAJOR.MINOR Pour exemples, reportez-vous à hardware/interfaces. vendor/${VENDOR}/interfaces, frameworks/hardware/interfaces ou system/hardware/interfaces

Les HAL natives et HIDL peuvent utiliser plusieurs champs de version, à condition qu'ils représentent versions majeures distinctes, avec une seule version mineure par majeure version fournie. Par exemple, les versions 3.1 et 3.2 ne peuvent pas coexister, contrairement aux versions 1.0 et 3.4. Cela s'applique à tous les éléments hal portant le même nom, sauf si override="true" Les valeurs de <version> ne sont pas associé à <fqname>, car un <fqname> contient une version.

Pour les HAL AIDL, <version> ne doit pas être présent sur les appareils exécutant Android 11 et versions antérieures. <version> doit être une entier unique sur les appareils équipés d'Android 12 ou version ultérieure. Un <version> par élément doit être au maximum Nuptial (package, interface, instance). S'il n'est pas présent, utiliser par défaut 1 La valeur de <version> est associée à toutes les <fqname> dans le même <hal>, car une <fqname> ne comporte pas de version.
manifest.hal.interface
Obligatoire, peut être répété sans doublon. Indiquez une interface dans contenant un nom d'instance. Il peut y avoir plusieurs Éléments <interface> dans une <hal>. noms doivent être distinctes.
manifest.hal.interface.name
Obligatoire. Nom de l'interface.
manifest.hal.interface.instance
Obligatoire, peut être répété. Nom d'instance de l'interface. Peut avoir plusieurs instances pour une interface, mais pas de <instance> en double éléments.
manifest.hal.fqname
Facultatif, peut être répété. Autre moyen de spécifier une instance pour le HAL avec le nom manifest.hal.name.
  • Pour les HAL HIDL, le format est @MAJOR.MINOR::INTERFACE/INSTANCE
  • Pour les HAL AIDL, le format est le suivant : INTERFACE/INSTANCE
manifest.sepolicy
Obligatoire. Contient toutes les entrées liées à la règle sepolicy.
manifest.sepolicy.version
Obligatoire pour le fichier manifeste de l'appareil. Déclare la version SELinux. Il contient les le format SDK_INT.PLAT_INT.
manifest.vendor-ndk
Obligatoire, peut être répété ; requise pour le fichier manifeste du framework. Ne doit pas être présent dans le fichier manifeste de l'appareil. Plusieurs entrées <vendor-ndk> doivent contenir <version> différentes. Décrit un ensemble d'instantanés VNDK fournis par le framework.
manifest.vendor-ndk.version
Obligatoire. Il s'agit d'un entier positif représentant la version du VNDK. un instantané.
manifest.vendor-ndk.library
Facultatif, peut être répété, sans doublon. Décrit un ensemble de bibliothèques VNDK fourni par le framework pour cet instantané de fournisseur VNDK. Cette valeur correspond au nom de fichier d'une bibliothèque, par exemple libjpeg.so, y compris le préfixe lib et le suffixe .so. Aucun composant de chemin d'accès autorisés.
manifest.system-sdk.version
Facultatif, peut être répété, sans doublon utilisé uniquement par le framework fichier manifeste. Décrit un ensemble de versions du SDK système fournies par le framework pour applications de fournisseurs tiers.
manifest.kernel
Facultatif. Décrit les informations statiques sur le noyau.
manifest.kernel.target-level
Facultatif. Décrit la branche du noyau. Sa valeur par défaut est manifest.target-level si absent. Doit être supérieur à ou égal à manifest.target-level. Voir règles de correspondance du noyau pour en savoir plus.