Fichiers manifestes

Un objet VINTF regroupe les données des fichiers manifestes de périphérique et des fichiers manifestes de structure (XML). Les deux manifestes partagent un format, bien que tous les éléments ne s'appliquent pas aux deux (pour plus de détails sur le schéma, voir Schéma du fichier manifeste ).

Manifeste de l'appareil

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

  • Le manifeste du fournisseur spécifie les HAL, les versions de politique SELinux, etc. communes à un SoC. Il est recommandé de le placer dans l'arborescence des sources Android à l' device/ VENDOR / DEVICE /manifest.xml , mais plusieurs fichiers de fragments peuvent être utilisés. Pour plus de détails, consultez Fragments de manifeste et Générer du DM à partir de fragments .
  • Le manifeste ODM répertorie les HAL spécifiques au produit dans la partition ODM . L'objet VINTF charge le manifeste ODM dans cet ordre :
    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 manifeste du fournisseur répertorie les HAL spécifiques au produit dans la partition du fournisseur. L'objet VINTF charge le manifeste du fournisseur dans cet ordre :
    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 manifeste de périphérique dans cet ordre :
    1. Si le manifeste du fournisseur existe, combinez les éléments suivants :
      1. Le manifeste du vendeur
      2. Fragments de manifeste du fournisseur facultatifs
      3. Manifeste ODM facultatif
      4. Fragments de manifeste ODM facultatifs
    2. Sinon, si le manifeste ODM existe, combinez-le avec les fragments de manifeste ODM facultatifs.
    3. /vendor/manifest.xml (hérité, pas de fragments)

    Noter que:

    • Sur les appareils existants, le manifeste du fournisseur hérité et le manifeste ODM sont utilisés. Le manifeste ODM peut remplacer complètement le manifeste du fournisseur existant.
    • Sur les appareils lancés avec Android 9, le manifeste ODM est combiné avec le manifeste du fournisseur.
    • Lors de la combinaison d'une liste de manifestes, les manifestes qui apparaissent plus tard dans la liste peuvent remplacer les balises des manifestes qui apparaissent plus tôt dans la liste, à condition que les balises du manifeste ultérieur aient l'attribut override="true" . Par exemple, le manifeste ODM peut remplacer certaines balises <hal> du manifeste du fournisseur. Consultez la documentation pour override d'attribut ci-dessous.

Cette configuration permet à plusieurs produits dotés de la même carte de partager la même image de fournisseur (qui fournit des HAL communs) tout en ayant des images ODM différentes (qui spécifient des HAL spécifiques au produit).

Voici un exemple de 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 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 manifeste de périphérique 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 plus de détails, consultez Développement de manifeste de périphérique .

Manifeste du cadre

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

  • Le manifeste système (fourni par Google) est généré manuellement et se trouve dans l'arborescence des sources Android à l'adresse /system/libhidl/manifest.xml .
  • Le manifeste du produit (fourni par l'appareil) répertorie les HAL gérés par les modules installés sur la partition du produit.
  • Le manifeste system_ext (fourni par l’appareil) répertorie les éléments suivants :
    • HAL desservis par les modules installés sur la partition system_ext ;
    • Versions VNDK ;
    • Version du SDK système.

Semblable au manifeste de périphérique, plusieurs fichiers de fragments peuvent être utilisés. Pour plus de détails, consultez Fragments de manifeste .

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

Sous Android 10 et versions ultérieures, vous pouvez associer une entrée de manifeste à un module HAL dans le système de build. Cela facilite l'inclusion conditionnelle du module HAL dans le système de construction.

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

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

Dans un fichier appelé manifest_foo.xml , créez le manifeste pour ce module. Au moment de la construction, ce manifeste est ajouté à l’appareil. Ajouter une entrée ici revient à ajouter une entrée dans le manifeste principal de l'appareil. Cela permet aux clients d'utiliser l'interface et permet à VTS d'identifier quelles implémentations HAL se trouvent sur l'appareil. Tout ce qu'un manifeste régulier fait, ce manifeste le fait également.

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

Schéma du fichier manifeste

Cette section décrit la signification de ces balises XML. Certaines balises "obligatoires" peuvent manquer dans le fichier source dans l'arborescence des sources Android et être écrites par assemble_vintf au moment de la construction. Les balises obligatoires doivent être présentes dans les fichiers correspondants sur l’appareil.

?xml
Facultatif. Fournit uniquement des informations à l'analyseur XML.
manifest.version
Requis. Méta-version de ce manifeste. Décrit les éléments attendus dans le manifeste. Sans rapport avec la version XML.
manifest.type
Requis. Type de ce manifeste. Il a la valeur device pour le fichier manifeste de périphérique et framework pour le fichier manifeste de framework.
manifest.target-level
Obligatoire pour le manifeste de l’appareil. Spécifie la version de la matrice de compatibilité du framework (FCM) avec laquelle ce manifeste de périphérique est censé être compatible. C'est ce qu'on appelle également la version FCM d'expédition de l'appareil.
manifest.hal
Facultatif, peut répéter. Un seul HAL (HIDL ou natif, tel que GL), en fonction de l'attribut format .
manifest.hal.format
Facultatif. La valeur peut être l'une des suivantes :
  • hidl : HIDL HAL. C'est la valeur par défaut.
  • aidl : AIDL HAL . Uniquement valable pour la méta-version 2.0 et supérieure du manifeste.
  • native : HAL natifs.
manifest.hal.max-level
Facultatif. Valable uniquement sur les manifestes de framework. S’ils sont définis, les HAL avec un niveau maximum inférieur à la version cible FCM dans le manifeste du framework sont désactivés.
manifest.hal.override
Facultatif. La valeur peut être l'une des suivantes :
  • true : Remplacez les autres éléments <hal> par le même <name> et la même version majeure. Si aucun <version> ou <fqname> ne se trouve dans cet élément <hal> , alors l'élément <hal> déclare que ce HAL est désactivé.
  • false : Ne remplacez pas les autres éléments <hal> avec le même <name> et la même version majeure.
manifest.hal.name
Requis. Nom de package complet du HAL. Plusieurs entrées HAL peuvent utiliser le même nom. Exemples:
  • android.hardware.camera (HIDL ou AIDL HAL)
  • GLES (HAL natif, nécessite uniquement le nom)
manifest.hal.transport
Obligatoire lorsque manifest.hal.format == "hidl" . Autrement, il ne doit PAS être présent. Indique quel transport est utilisé lorsqu’une interface de ce package est interrogée auprès du gestionnaire de services. La valeur peut être l'une des suivantes :
  • hwbinder : mode binderisé
  • passthrough : mode passthrough
Facultatif lorsque manifest.hal.format == "aidl" . Autrement, il ne doit PAS être présent. Indique quel transport est utilisé lorsqu’une interface est desservie à distance. La valeur doit être :
  • inet : prise Inet
Les manifest.hal.transport.ip et manifest.hal.transport.port doivent être utilisés pour spécifier davantage les informations de connexion Inet.
manifest.hal.transport.arch
Requis pour passthrough et ne doit pas être présent pour hwbinder . Décrit le nombre de bits du service relais fourni. La valeur peut être l'une des suivantes :
  • 32 : mode 32 bits
  • 64 : mode 64 bits
  • 32+64 : Les deux
manifest.hal.transport.ip
Requis pour inet et ne doit PAS être présent autrement. Décrit l'adresse IP à partir de laquelle l'interface distante est servie.
manifest.hal.transport.port
Requis pour inet et ne doit PAS être présent autrement. Décrit le port à partir duquel l'interface distante est servie.
manifest.hal.version
Facultatif, peut répéter. Une version pour les balises hal dans un manifeste.

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

HIDL et HAL natifs peuvent utiliser plusieurs champs de version à condition qu'ils représentent des versions majeures distinctes , avec une seule version mineure par version majeure fournie. Par exemple, 3.1 et 3.2 ne peuvent pas coexister, mais 1.0 et 3.4 le peuvent. Cela s'applique à tous les éléments hal portant le même nom, sauf override="true" . Les valeurs de <version> ne sont pas associées à <fqname> car un <fqname> porte 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 un entier unique sur les appareils exécutant Android 12 et versions ultérieures. Il doit y avoir au plus un <version> pour chaque tuple (package, interface, instance) . S’il n’est pas présent, la valeur par défaut est 1 . La valeur de <version> est associée à tous <fqname> dans le même <hal> car un <fqname> ne porte pas de version.
manifest.hal.interface
Obligatoire, peut être répété sans doublons. Indiquez une interface dans le package qui a un nom d’instance. Il peut y avoir plusieurs éléments <interface> dans un <hal> ; les noms doivent être distincts.
manifest.hal.interface.name
Requis. Nom de l'interface.
manifest.hal.interface.instance
Obligatoire, peut répéter. Nom d'instance de l'interface. Peut avoir plusieurs instances pour une interface mais aucun élément <instance> dupliqué.
manifest.hal.fqname
Facultatif, peut répéter. Une autre façon 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 INTERFACE / INSTANCE .
manifest.sepolicy
Requis. Contient toutes les entrées liées à la politique de sécurité.
manifest.sepolicy.version
Obligatoire pour le manifeste de l’appareil. Déclare la version de SELinux. Il a le format SDK_INT . PLAT_INT .
manifest.vendor-ndk
Obligatoire, peut répéter ; requis pour le manifeste du cadre. Ne doit pas être présent dans le manifeste de l’appareil. Plusieurs entrées <vendor-ndk> doivent avoir des <version> différentes. Décrit un ensemble d'instantanés VNDK fournis par le framework.
manifest.vendor-ndk.version
Requis. Il s'agit d'un entier positif représentant la version de l'instantané VNDK.
manifest.vendor-ndk.library
Facultatif, peut être répété, sans doublons. Décrit un ensemble de bibliothèques VNDK fournies par le framework pour cet instantané du fournisseur VNDK. La valeur est le nom de fichier d'une bibliothèque, par exemple libjpeg.so , incluant le préfixe lib et le suffixe .so . Aucun composant de chemin n'est autorisé.
manifest.system-sdk.version
Facultatif, peut répéter, sans doublons ; utilisé uniquement par le manifeste du framework. Décrit un ensemble de versions du SDK système fourni par le framework aux applications des fournisseurs.
manifest.kernel
Facultatif. Décrit des 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 elle n'est pas présente. Doit être supérieur ou égal à manifest.target-level . Voir les règles de correspondance du noyau pour plus de détails.