Ressources supplémentaires

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

Emplacement du code interrogeable

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

Les fichiers manifestes d'écriture manuscrite et les matrices de compatibilité peuvent être difficiles. 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 toutes les HAL enregistrées 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 d'appareil 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é auprès de hwservicemanager et trouvé en tant que HAL de 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 génération et génère un nouveau fichier qui doit être installé sur l'appareil.
  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 structure

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 structure de 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 d'appareil à 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 des fichiers XML de manifeste 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

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

Exemple : générer des fichiers XML de matrice de compatibilité d'appareils à 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é de périphérique :

# 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

Lors de l'exécution, l'objet VINTF utilise la matrice de compatibilité du fournisseur comme matrice de compatibilité du périphérique. Voir Matrice de compatibilité des appareils pour plus de détails.

Exemple : générer des fichiers XML de manifeste 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 construction, modifiées pour omettre les détails d'implémentation) pour générer des fichiers XML de manifeste 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

Lors de l'exécution, l'objet VINTF combine le manifeste système, les fragments de manifeste système, le manifeste de produit et les fragments de manifeste de 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 produit FCM et le FCM système spécifique à l'appareil :

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 des modules Soong ; ne définissez pas DEVICE_PRODUCT_COMPATIBILITY_MATRIX_FILE si cette méthode est utilisée. De plus, plusieurs versions de produit FCM 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 sur 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

Lors 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é de structure. 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 de fournisseur peuvent être regroupés au moment de la génération. 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 (external/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 de 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).