Fichiers manifestes

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Un objet VINTF agrège les données du manifeste de l' appareil et des fichiers manifestes du cadre (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 à device/ VENDOR / DEVICE /manifest.xml , mais plusieurs fichiers fragmentés peuvent être utilisés. Pour plus de détails, consultez Manifest fragments et Generate DM from 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 l'appareil dans cet ordre :
    1. Si le manifeste du fournisseur existe, combinez les éléments suivants :
      1. Le manifeste du fournisseur
      2. Fragments de manifeste de fournisseur facultatifs
      3. Manifeste ODM facultatif
      4. Fragments de manifeste ODM facultatifs
    2. Sinon, si le manifeste ODM existe, combinez le manifeste ODM avec les fragments de manifeste ODM facultatifs.
    3. /vendor/manifest.xml (héritage, pas de fragments)

    Notez que:

    • Sur les appareils hérités, le manifeste du fournisseur hérité et le manifeste ODM sont utilisés. Le manifeste ODM peut complètement remplacer le manifeste du fournisseur hérité.
    • 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 dernier manifeste aient l'attribut override="true" . Par exemple, le manifeste ODM peut remplacer certaines balises <hal> du manifeste du fournisseur. Voir la documentation pour le override d'attribut ci-dessous.

Cette configuration permet à plusieurs produits avec 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 se compose du manifeste du système, du manifeste du produit et du manifeste system_ext.

  • Le manifeste du système (fourni par Google) est généré manuellement et se trouve dans l'arborescence des sources Android à /system/libhidl/manifest.xml .
  • Le manifeste du produit (fourni par le périphérique) répertorie les HAL desservis 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 des modules installés sur la partition system_ext ;
    • Versions VNDK ;
    • Version du SDK système.

Semblable au manifeste de l'appareil, 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

Dans Android 10 et versions ultérieures, vous pouvez associer une entrée de manifeste à un module HAL dans le système de construction. 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 génération, ce manifeste est ajouté à l'appareil. L'ajout d'une entrée ici revient au même que l'ajout d'une entrée dans le manifeste principal de l'appareil. Cela permet aux clients d'utiliser l'interface et permet à VTS d'identifier les implémentations HAL qui 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 être absentes du fichier source dans l'arborescence source d'Android et écrites par assemble_vintf au moment de la construction. Les balises requises doivent être présentes dans les fichiers correspondants sur l'appareil.

?xml
Optionnel. Fournit uniquement des informations à l'analyseur XML.
manifest.version
Obligatoire. Méta-version de ce manifeste. Décrit les éléments attendus dans le manifeste. Sans rapport avec la version XML.
manifest.type
Obligatoire. Type de ce manifeste. Il a la valeur device pour le fichier manifeste du périphérique et framework pour le fichier manifeste du 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 d'appareil doit être compatible. Ceci est également appelé 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), selon l'attribut de format .
manifest.hal.format
Optionnel. La valeur peut être l'une des suivantes :
  • hidl : HAL HIDL. C'est la valeur par défaut.
  • aidl : AIDL HALs . Valable uniquement avec la méta-version du manifeste 2.0 et supérieure.
  • native : HAL natives.
manifest.hal.max-level
Optionnel. Valable uniquement sur les manifestes de framework. S'il est défini, les HAL avec un niveau maximum inférieur à la version FCM cible dans le manifeste du framework sont désactivés.
manifest.hal.override
Optionnel. La valeur peut être l'une des suivantes :
  • true : remplace les autres éléments <hal> par le même <name> et la même version majeure. S'il n'y a pas de <version> ou <fqname> dans cet élément <hal> , alors l'élément <hal> déclare que cette HAL est désactivée.
  • false : ne remplace pas les autres éléments <hal> par le même <name> et la même version majeure.
manifest.hal.name
Obligatoire. Nom de package complet de la couche 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" . NE DOIT PAS être présent sinon. Indique quel transport est utilisé lorsqu'une interface de ce package est interrogée par le gestionnaire de services. La valeur peut être l'une des suivantes :
  • hwbinder : mode lié
  • passthrough : Mode passthrough
Facultatif lorsque manifest.hal.format == "aidl" . NE DOIT PAS être présent sinon. Indique quel transport est utilisé lorsqu'une interface est desservie à distance. La valeur doit être :
  • inet : socket inet
Le manifest.hal.transport.ip et le 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 de 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 desservie.
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 desservie.
manifest.hal.version
Facultatif, peut répéter. Une version pour les balises hal dans un manifeste.

Pour HIDL et les HAL natifs, le format est MAJOR . MINOR . Pour obtenir 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 tant 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 AIDL HAL, <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 une <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 les <fqname> dans le même <hal> car un <fqname> ne porte pas de version.
manifest.hal.interface
Obligatoire, peut se répéter 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
Obligatoire. Nom de l'interface.
manifest.hal.interface.instance
Requis, peut répéter. Nom d'instance de l'interface. Peut avoir plusieurs instances pour une interface mais pas d'éléments <instance> dupliqués.
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 HIDL HAL, le format est @ MAJOR . MINOR :: INTERFACE / INSTANCE .
  • Pour les AIDL HAL, le format est INTERFACE / INSTANCE .
manifest.sepolicy
Obligatoire. Contient toutes les entrées liées à sepolicy.
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
Requis, 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érents. 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 de l'instantané VNDK.
manifest.vendor-ndk.library
Facultatif, peut se répéter, sans doublons. Décrit un ensemble de bibliothèques VNDK fournies par le framework pour cet instantané de 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 de SDK système fournies par le framework aux applications du fournisseur.
manifest.kernel
Optionnel. Décrit les informations statiques sur le noyau.
manifest.kernel.target-level
Optionnel. Décrit la branche du noyau. Sa valeur par défaut est manifest.target-level s'il n'est pas présent. Doit être supérieur ou égal à manifest.target-level . Voir les règles de correspondance du noyau pour plus de détails.