Autres ressources

Les ressources suivantes fournissent des détails sur les emplacements du code, les outils, les tests et les licences.

Emplacement du code interrogeable

Le code de l'objet d'interface fournisseur interrogeable va à system/libvintf .

L’écriture manuscrite des fichiers manifestes et des matrices de compatibilité peut être difficile. Utilisez les outils suivants pour générer une matrice de manifeste/compatibilité passe-partout à partir de laquelle commencer.

LSHAL

LSHAL est un outil côté appareil qui répertorie tous les HAL enregistrés sur hwservicemanager et toutes les implémentations de relais disponibles (par exemple android.hardware.foo@1.0-impl.so ) sur l'appareil. Il peut également générer un fichier manifeste de périphérique basé sur la liste :

adb shell su 0 /system/bin/lshal --init-vintf

Notez ce qui suit :

  1. Si un package est à la fois enregistré sur hwservicemanager et trouvé en tant que HAL relais, <transport> est défini sur hwbinder .
  2. Aucune version de SELinux n'est écrite dans le manifeste. Il est suggéré que l'élément soit injecté via assemble_vintf comme expliqué ci-dessous.
  3. Le fichier manifeste HAL généré peut être inexact. Une attention humaine est requise pour corriger les incohérences entre le manifeste de l'appareil et ce que vendor.img fournit réellement.

ASSEMBLE_VINTF

assemble_vintf est un outil côté hôte qui :

  1. Vérifie qu’une matrice de compatibilité ou un fichier manifeste est valide.
  2. Injecte des variables dans les manifestes/matrices de compatibilité disponibles au moment de la construction et génère un nouveau fichier qui doit être installé sur le périphérique.
  3. Vérifie la compatibilité entre le fichier généré et son dual.
  4. Si un fichier manifeste est fourni, génère éventuellement une matrice de compatibilité passe-partout compatible avec le fichier manifeste.

Exemple : Générer une matrice de compatibilité des appareils à partir d'un fichier manifeste de framework

assemble_vintf -m --hals-only \
    -i system/libhidl/manifest.xml \
    -o device/manufacturer/device_name/compatibility_matrix.xml

Notez que tous les HAL sont définis sur optional="true" .

Exemple : Générer une matrice de compatibilité de framework squelette à partir d'un fichier manifeste de périphérique

assemble_vintf -m --hals-only \
    -i device/foo/bar/manifest.xml \
    -o path/to/place/output/compatibility_matrix.xml

Notez que tous les HAL sont définis sur optional="true" .

Exemple : Générer des fichiers XML de manifeste de périphérique à partir de variables

Au moment de la construction, si les variables suivantes sont définies dans device/manufacturer/device_name/BoardConfig.mk :

# Vendor manifest is named DEVICE_MANIFEST_FILE for legacy reasons.
DEVICE_MANIFEST_FILE := \
    device/manufacturer/device_name/vendor_manifest.xml
ODM_MANIFEST_FILES := \
    device/manufacturer/device_name/odm_manifest.xml
ODM_MANIFEST_SKUS := sku1 sku2
ODM_MANIFEST_SKU1_FILES := \
    device/manufacturer/device_name/odm_manifest_sku1.xml
ODM_MANIFEST_SKU2_FILES := \
    device/manufacturer/device_name/odm_manifest_sku2.xml

Ensuite, les commandes suivantes sont exécutées (dans le système de construction, modifiées pour omettre les détails d'implémentation) pour générer les fichiers XML manifestes de périphérique :

# vendor manifest; only when DEVICE_MANIFEST_FILE is set
BOARD_SEPOLICY_VERS=$(BOARD_SEPOLICY_VERS) assemble_vintf \
    $(addprefix,-i ,$(DEVICE_MANIFEST_FILE)) \
    -o $(TARGET_OUT_VENDOR)/etc/vintf/manifest.xml

# ODM manifests
assemble_vintf \
    $(addprefix,-i ,$(ODM_MANIFEST_FILES)) \
    -o $(TARGET_OUT_ODM)/etc/vintf/manifest.xml

# ODM manifests for each sku
assemble_vintf \
    $(addprefix,-i ,$(ODM_MANIFEST_SKU1_FILES)) \
    -o $(TARGET_OUT_ODM)/etc/vintf/manifest_sku1.xml
assemble_vintf \
    $(addprefix,-i ,$(ODM_MANIFEST_SKU2_FILES)) \
    -o $(TARGET_OUT_ODM)/etc/vintf/manifest_sku2.xml

Au moment de l'exécution, l'objet VINTF combine les manifestes du fournisseur et les manifestes ODM en tant que manifeste de périphérique. Voir Manifeste de l’appareil pour plus de détails.

Exemple : Générer des fichiers XML de matrice de compatibilité de périphérique à partir de variables

Au moment de la construction, si les variables suivantes sont définies dans device/manufacturer/device_name/BoardConfig.mk :

# vendor compatibility matrix is named DEVICE_MATRIX_FILE for legacy reasons.
DEVICE_MATRIX_FILE := \
    device/manufacturer/device_name/vendor_compatibility_matrix.xml \
    device/manufacturer/device_name/vendor_compatibility_matrix_additional.xml

Ensuite, les commandes suivantes sont exécutées (dans le système de construction, modifiées pour omettre les détails d'implémentation) pour générer des fichiers XML de matrice de compatibilité des périphériques :

# vendor compatibility matrix; only when DEVICE_MATRIX_FILE is set
assemble_vintf \
    $(addprefix,-i ,$(DEVICE_MATRIX_FILE)) \
    -o $(TARGET_OUT_VENDOR)/etc/vintf/compatibility_matrix.xml

Au moment de l'exécution, l'objet VINTF utilise la matrice de compatibilité des fournisseurs comme matrice de compatibilité des périphériques. Voir Matrice de compatibilité des appareils pour plus de détails.

Exemple : Générer des fichiers XML manifestes de framework à partir de variables

Les variables suivantes peuvent être définies dans device/manufacturer/device_name/BoardConfig.mk :

# Device-specific system manifest is named DEVICE_FRAMEWORK_MANIFEST_FILE for legacy reasons
DEVICE_FRAMEWORK_MANIFEST_FILE := \
    device/manufacturer/device_name/device_system_manifest.xml

# Product manifest
PRODUCT_MANIFEST_FILES := \
    device/manufacturer/device_name/product_manifest.xml

Les commandes suivantes sont exécutées (dans le système de build, modifiées pour omettre les détails d'implémentation) pour générer des fichiers XML manifestes de framework :

# system manifest
assemble_vintf \
    -i system/libhidl/vintfdata/manifest.xml \
    $(addprefix,-i ,$(DEVICE_FRAMEWORK_MANIFEST_FILE)) \
    -o $(TARGET_OUT)/etc/vintf/manifest.xml

# product manifest
assemble_vintf \
    $(addprefix,-i ,$(PRODUCT_MANIFEST_FILES)) \
    -o $(TARGET_OUT_PRODUCT)/etc/vintf/manifest.xml

Au moment de l'exécution, l'objet VINTF combine le manifeste système, les fragments du manifeste système, le manifeste du produit et les fragments du manifeste du produit en tant que manifeste de structure. Voir Manifeste du framework pour plus de détails.

Exemple : Générer des fichiers XML de matrice de compatibilité de framework à partir de variables

Les variables suivantes peuvent être définies dans device/manufacturer/device_name/BoardConfig.mk pour définir le FCM du produit et le FCM du système spécifique au périphérique :

DEVICE_PRODUCT_COMPATIBILITY_MATRIX_FILE := \
    device/manufacturer/device_name/product_compatibility_matrix.xml
# Device-specific system compatibility matrix is named
# DEVICE_FRAMEWORK_COMPATIBILITY_MATRIX_FILE for legacy reasons.
DEVICE_FRAMEWORK_COMPATIBILITY_MATRIX_FILE := \
    device/manufacturer/device_name/device_system_compatibility_matrix.xml

Le FCM system_ext doit être installé avec les modules Soong. Le produit FCM peut également être installé avec les modules Soong ; ne définissez pas DEVICE_PRODUCT_COMPATIBILITY_MATRIX_FILE si cette méthode est utilisée. De plus, plusieurs versions FCM du produit et versions system_ext FCM peuvent être installées avec les modules Soong. Définir ce qui suit:

  • Définissez un module dans device/manufacturer/device_name/Android.bp . Par exemple (remplacez system_ext par product pour le produit FCM) :
    vintf_compatibility_matrix {
        name: "system_ext_compatibility_matrix.xml",
        stem: "compatibility_matrix.xml",
        system_ext_specific: true,
        // product_specific: true, // for product FCM
        srcs: [
            "system_ext_compatibility_matrix.xml",
        ],
    }
    
  • Installez le module dans device/manufacturer/device_name/device.mk . Par exemple :
    PRODUCT_PACKAGES += system_ext_compatibility_matrix.xml
    

Les commandes suivantes sont exécutées (dans le système de construction, modifiées pour omettre les détails d'implémentation) pour générer des fichiers XML de matrice de compatibilité du framework :

# common system compatibility matrix for each FCM version
BOARD_SEPOLICY_VERS=$(BOARD_SEPOLICY_VERS) \
POLICYVERS=$(POLICYVERS) \
BOARD_AVB_VBMETA_VERSION=$(BOARD_AVB_VBMETA_VERSION)
assemble_vintf \
    -i hardware/interfaces/compatibility_matrices/compatibility_matrix.empty.xml
    $(addprefix,-i ,$(DEVICE_FRAMEWORK_COMPATIBILITY_MATRIX_FILE)) \
    -o $(TARGET_OUT)/etc/vintf/compatibility_matrix.device.xml

# framework compatibility matrixes at each FCM version
assemble_vintf
    -i hardware/interfaces/compatibility_matrices/compatibility_matrix.{level}.xml \
    -o $(TARGET_OUT)/etc/vintf/compatibility_matrix.{level}.xml \
    --kernel=...

# product framework compatibility matrix; only when
# DEVICE_PRODUCT_COMPATIBILITY_MATRIX_FILE is set or when the Soong module for
# product FCM is defined
assemble_vintf
    -i $(DEVICE_PRODUCT_COMPATIBILITY_MATRIX_FILE)
    -o $(TARGET_OUT_PRODUCT)/etc/vintf/compatibility_matrix.xml

# system_ext framework compatibility matrix; only when the Soong module for
# system_ext FCM is defined
assemble_vintf
    -i <srcs for the soong module>
    -o $(TARGET_OUT_SYSTEM_EXT)/etc/vintf/compatibility_matrix.xml

Au moment de l'exécution, l'objet VINTF combine un sous-ensemble de matrices de compatibilité système et de matrices de compatibilité produit en tant que matrice de compatibilité du framework. Voir Matrice de compatibilité du framework pour plus de détails.

Exemple : générer le manifeste du fournisseur à partir de fragments

Plusieurs fragments de manifeste du fournisseur peuvent être regroupés au moment de la construction. Par exemple:

<!-- device/manufacturer/device_name/manifest_common.xml -->
<manifest version="1.0" type="device">
    <!-- common HALs here -->
</manifest>
<!-- device/manufacturer/device_name/ir.xml -->
<manifest version="1.0" type="device">
    <hal>
        <name>android.hardware.ir</name>
        <version>1.0</version>
        <!-- other fields -->
    </hal>
</manifest>
# device/manufacturer/device_name/BoardConfig.mk
DEVICE_MANIFEST_FILE := device/manufacturer/device_name/manifest_common.xml
ifdef BOARD_ENABLE_IR
    DEVICE_MANIFEST_FILE += device/manufacturer/device_name/ir.xml
endif

Ensuite, assemble_vintf ajoute l'IR HAL au manifeste du fournisseur si BOARD_ENABLE_IR est défini, et l'omet si BOARD_ENABLE_IR n'est pas défini. Les commandes suivantes (modifiées pour omettre les détails d'implémentation) sont exécutées pour générer le manifeste du fournisseur :

# if BOARD_ENABLE_IR is defined
BOARD_SEPOLICY_VERS=10000.0 assemble_vintf \
    -i device/manufacturer/device_name/manifest_common.xml:device/manufacturer/device_name/ir.xml \
    -o $(TARGET_OUT_VENDOR)/manifest.xml

# if BOARD_ENABLE_IR is not defined
BOARD_SEPOLICY_VERS=10000.0 assemble_vintf \
    -i device/manufacturer/device_name/manifest_common.xml \
    -o $(TARGET_OUT_VENDOR)/manifest.xml

Pour plus de détails, voir :

assemble_vintf --help

Essai

Le projet platform/system/libvintf utilise GTest pour la sérialisation, la désérialisation et la vérification de compatibilité.

Licence

  • tinyxml2 (externe/tinyxml2) pour sérialiser/désérialiser l'objet vers/depuis XML. Licence de type BSD.
  • libselinux (external/selinux/libselinux) pour obtenir la version de Policydb. Licence du domaine public.
  • libz (external/zlib) pour décompresser /proc/config.gz . Licence de type BSD.
  • Le projet libvintf utilise la licence Apache 2.0 (avec les fichiers MODULE_LICENSE_APACHE2 et NOTICE appropriés).