Ressources supplémentaires

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

Emplacement du code pouvant être interrogé

Le code de l'objet d'interface fournisseur interrogeable est system/libvintf

Les fichiers manifestes d'écriture manuscrite et les matrices de compatibilité peuvent être difficiles. Utilisez les les outils suivants pour générer un fichier manifeste/matrice de compatibilité récurrent pour commencer

LSHAL

LSHAL est un outil côté appareil qui répertorie toutes les HAL enregistrées pour hwservicemanager et toutes les implémentations de passthrough disponibles (par exemple, android.hardware.foo@1.0-impl.so) sur l'appareil. Il peut également Générez un fichier manifeste d'appareil à partir de cette liste:

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

Remarques :

  1. Si un package est à la fois enregistré dans hwservicemanager et trouvé en tant que HAL passthrough, <transport> est défini sur hwbinder
  2. Aucune version de SELinux n'est écrite dans le fichier manifeste. Il est conseillé que est injecté via assemble_vintf, comme expliqué ci-dessous.
  3. Le fichier manifeste HAL généré peut être inexact. L'attention humaine est nécessaires pour corriger les incohérences entre le fichier manifeste de l'appareil et 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 fichiers manifestes/matrices de compatibilité disponibles au moment de la compilation 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 double.
  4. Si un fichier manifeste est fourni, il peut éventuellement générer un code récurrent. de compatibilité qui est compatible avec le fichier manifeste.

Exemple: Générer des appareils compatibles matrix à 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 compatibilité de squelette de framework matrice à partir d'un fichier manifeste d'appareil

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 manifestes d'appareil à partir de variables

Au moment de la compilation, si les variables suivantes sont défini 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 compilation, modifiées pour omettre l'implémentation ) pour générer les fichiers XML manifestes de l'appareil:

# 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 fichiers manifestes de fournisseur et les fichiers manifestes ODM comme le fichier manifeste de l'appareil. Voir Appareil manifeste pour en savoir plus.

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

Au moment de la compilation, si les variables suivantes sont défini 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 compilation, modifiées pour omettre l'implémentation ) pour générer les fichiers XML de la matrice de compatibilité des appareils:

# 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 de compatibilité des appareils. Voir Appareil matrice de compatibilité 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 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 compilation, modifiées pour omettre l'implémentation ) pour générer les fichiers XML manifestes du 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 fichier manifeste système et le fichier manifeste système les fragments, le fichier manifeste de produit et les fragments du fichier manifeste de produit comme fichier manifeste du framework. Voir Cadre manifeste pour en savoir plus.

Exemple:Générer les fichiers XML de la matrice de compatibilité du framework à partir de variables

Les variables suivantes peuvent être définies device/manufacturer/device_name/BoardConfig.mk pour définir les propriétés FCM du produit et FCM du 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 des modules Soong. FCM du produit peut aussi être installé avec les modules Soong, ne définissez pas DEVICE_PRODUCT_COMPATIBILITY_MATRIX_FILE si cette est utilisée. En outre, plusieurs versions FCM et system_ext des versions FCM peuvent être installés avec des modules Soong. Définissez les éléments suivants:

  • Définissez un module dans device/manufacturer/device_name/Android.bp. Par exemple (remplacez system_ext avec le produit pour 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. Exemple : 
    PRODUCT_PACKAGES += system_ext_compatibility_matrix.xml

Les commandes suivantes sont exécutées (dans le système de compilation, modifiées pour omettre l'implémentation ) pour générer les fichiers XML de la matrice de compatibilité des frameworks:

# 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 la compatibilité système et les matrices de compatibilité des produits comme la compatibilité du framework matricielle. Voir Cadre matrice de compatibilité pour plus de détails.

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

Plusieurs fragments de fichier manifeste de fournisseur peuvent être regroupés au moment de la compilation. 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 le HAL infrarouge au fichier manifeste du fournisseur si BOARD_ENABLE_IR est défini et l'omet si BOARD_ENABLE_IR non défini. Les commandes suivantes (modifié pour omettre les détails de l'implémentation) sont exécutés pour générer le fichier 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 d'informations, reportez-vous aux rubriques suivantes :

assemble_vintf --help

Tests

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

Licences

  • tinyxml2 (external/tinyxml2) pour sérialiser/désérialiser le vers/depuis XML. Licence de type BSD.
  • libselinux (external/selinux/libselinux) pour obtenir policydb version. Licence appartenant au domaine public.
  • libz (external/zlib) pour la décompression /proc/config.gz Licence de type BSD.
  • Le projet libvintf utilise une licence Apache 2.0 (avec des autorisations MODULE_LICENSE_APACHE2 et NOTICE).