Em 2026, para nos alinharmos ao nosso modelo de desenvolvimento estável e garantir a estabilidade da plataforma para o ecossistema, vamos publicar o código-fonte no AOSP no segundo e quarto trimestres. Para criar e contribuir com o AOSP, use android-latest-release. A ramificação de manifesto android-latest-release sempre vai referenciar a versão mais recente enviada ao AOSP. Para mais informações, consulte Mudanças no AOSP.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Outros recursos

Os recursos a seguir fornecem detalhes sobre locais de código, ferramentas, testes e licenciamento.

Local do código consultável

O código do objeto de interface do fornecedor consultável vai para system/libvintf.

Criar arquivos de manifesto e matrizes de compatibilidade à mão pode ser difícil. Use as ferramentas a seguir para gerar um manifesto/matriz de compatibilidade padrão para começar a trabalhar.

LSHAL

O LSHAL é uma ferramenta do lado do dispositivo que lista todas as HALs registradas em hwservicemanager e todas as implementações de transferência direta disponíveis (por exemplo, android.hardware.foo@1.0-impl.so) no dispositivo. Ele também pode gerar um arquivo de manifesto do dispositivo com base na lista:

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

Observe o seguinte:

Se um pacote estiver registrado em hwservicemanager e for encontrado como uma HAL de passagem, <transport> será definido como hwbinder.
Nenhuma versão do SELinux é gravada no manifesto. É recomendável que o elemento seja injetado por assemble_vintf, conforme explicado abaixo.
O arquivo de manifesto HAL gerado pode estar impreciso. É necessário atenção humana para corrigir inconsistências entre o manifesto do dispositivo e o que vendor.img realmente fornece.

ASSEMBLE_VINTF

O assemble_vintf é uma ferramenta do lado do host que:

Verifica se uma matriz de compatibilidade ou um arquivo de manifesto é válido.
Injeta variáveis em manifestos/matrizes de compatibilidade disponíveis no momento do build e gera um novo arquivo que precisa ser instalado no dispositivo.
Verifica a compatibilidade entre o arquivo gerado e o dual.
Se um arquivo de manifesto for fornecido, vai gerar opcionalmente uma matriz de compatibilidade padrão compatível com o arquivo de manifesto.

Exemplo:gerar uma matriz de compatibilidade de dispositivos de um arquivo de manifesto do framework

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

Todos os HALs estão definidos como optional="true".

Exemplo:gerar uma matriz de compatibilidade de framework esqueleto de um arquivo de manifesto do dispositivo

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

Todos os HALs estão definidos como optional="true".

Exemplo:gerar arquivos XML de manifesto do dispositivo com base em variáveis

No tempo de build, se as seguintes variáveis estiverem definidas em 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

Em seguida, os seguintes comandos são executados (no sistema de build, modificados para omitir detalhes de implementação) para gerar arquivos XML de manifesto do dispositivo:

# 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

Em tempo de execução, o objeto VINTF combina manifestos do fornecedor e da ODM como o manifesto do dispositivo. Consulte o manifesto do dispositivo para mais detalhes.

Exemplo:gerar arquivos XML de matriz de compatibilidade de dispositivos com base em variáveis

No tempo de build, se as seguintes variáveis estiverem definidas em 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

Em seguida, os seguintes comandos são executados (no sistema de build, modificados para omitir detalhes de implementação) para gerar arquivos XML da matriz de compatibilidade de dispositivos:

# 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

No momento da execução, o objeto VINTF usa a matriz de compatibilidade do fornecedor como a matriz de compatibilidade do dispositivo. Consulte a matriz de compatibilidade de dispositivos para mais detalhes.

Exemplo:gerar arquivos XML de manifesto do framework com base em variáveis

As variáveis a seguir podem ser definidas em 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

Os comandos a seguir são executados (no sistema de build, modificados para omitir detalhes de implementação) para gerar arquivos XML de manifesto do 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

Em tempo de execução, o objeto VINTF combina o manifesto do sistema, os fragmentos do manifesto do sistema, o manifesto do produto e os fragmentos do manifesto do produto como o manifesto do framework. Consulte o manifesto do framework para mais detalhes.

Exemplo:gerar arquivos XML da matriz de compatibilidade do framework com base em variáveis

As variáveis a seguir podem ser definidas em device/manufacturer/device_name/BoardConfig.mk para definir o FCM do produto e o FCM do sistema específico do dispositivo:

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

O FCM system_ext precisa ser instalado com módulos do Soong. O FCM do produto também pode ser instalado com módulos do Soong. Não defina DEVICE_PRODUCT_COMPATIBILITY_MATRIX_FILE se esse método for usado. Além disso, várias versões do FCM de produtos e do FCM system_ext podem ser instaladas com módulos Soong. Defina o seguinte:

Defina um módulo em device/manufacturer/device_name/Android.bp. Por exemplo, substitua system_ext por product para FCM de produto:

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",
    ],
}

Instale o módulo em device/manufacturer/device_name/device.mk. Exemplo:
```
PRODUCT_PACKAGES += system_ext_compatibility_matrix.xml
```

Os seguintes comandos são executados (no sistema de build, modificados para omitir detalhes de implementação) para gerar arquivos XML da matriz de compatibilidade do 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

Em tempo de execução, o objeto VINTF combina um subconjunto de matrizes de compatibilidade do sistema e do produto como a matriz de compatibilidade do framework. Consulte a matriz de compatibilidade de frameworks para mais detalhes.

Exemplo:Gere o manifesto do fornecedor com base em fragmentos

Vários fragmentos de manifesto do fornecedor podem ser agrupados no tempo de build. Exemplo:

<!-- 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

Em seguida, assemble_vintf adiciona a HAL de IR ao manifesto do fornecedor se BOARD_ENABLE_IR estiver definido e a omite se BOARD_ENABLE_IR não estiver definido. Os comandos a seguir (modificados para omitir detalhes de implementação) são executados para gerar o manifesto do fornecedor:

# 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

Veja mais detalhes em:

assemble_vintf --help

Teste

O projeto platform/system/libvintf usa o GTest para a serialização, a desserialização e a verificação de compatibilidade.

Licenciamento

tinyxml2 (external/tinyxml2) para serializar/desserializar o objeto para/de XML. Licença semelhante à BSD.
libselinux (external/selinux/libselinux) para receber a versão do policydb. Licença de domínio público.
libz (externo/zlib) para descompactar /proc/config.gz. Licença semelhante à BSD.
O projeto libvintf usa a licença Apache 2.0 (com arquivos MODULE_LICENSE_APACHE2 e NOTICE adequados).

Outros recursos Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.