Google is committed to advancing racial equity for Black communities. See how.
Esta página foi traduzida pela API Cloud Translation.
Switch to English

Kit de desenvolvimento nativo do fornecedor (VNDK)

O Vendor Native Development Kit (VNDK) é um conjunto de bibliotecas exclusivamente para fornecedores implementarem seus HALs. O VNDK é enviado em system.img e é vinculado dinamicamente ao código do fornecedor no tempo de execução.

Por que VNDK?

O Android 8.0 e superior permite atualizações apenas da estrutura em que a partição do sistema pode ser atualizada para a versão mais recente, enquanto as partições do fornecedor permanecem inalteradas. Isso implica que binários construídos em momentos diferentes devem ser capazes de trabalhar uns com os outros; VNDK cobre mudanças de API / ABI em versões do Android.

As atualizações apenas da estrutura incluem os seguintes desafios:

  • Dependência entre os módulos da estrutura e os módulos do fornecedor . Antes do Android 8.0, os módulos de ambos os lados podiam ser vinculados aos módulos do outro lado. No entanto, as dependências dos módulos do fornecedor impõem restrições indesejadas ao desenvolvimento dos módulos da estrutura.
  • Extensões para bibliotecas AOSP . O Android 8.0 e superior requer que todos os dispositivos Android sejam aprovados no CTS quando a partição do sistema é substituída por uma imagem genérica do sistema (GSI) padrão. No entanto, conforme os fornecedores estendem as bibliotecas AOSP para aumentar o desempenho ou adicionar funcionalidades extras para suas implementações HIDL, atualizar a partição do sistema com um GSI padrão pode quebrar a implementação HIDL de um fornecedor. (Para obter orientações sobre como evitar tais quebras, consulte as extensões VNDK .)

Para lidar com esses desafios, o Android 8.0 apresenta várias técnicas, como VNDK (descrito nesta seção), HIDL , hwbinder, sobreposição de árvore de dispositivo e sobreposição de sepolicy.

Recursos VNDK

Esta seção inclui os seguintes recursos VNDK:

  • Os conceitos de VNDK (abaixo) descrevem bibliotecas compartilhadas de estrutura, HALs de mesmo processo (SP-HALs) e terminologia de VNDK.
  • As extensões VNDK classificam as alterações específicas do fornecedor em categorias. Por exemplo, as bibliotecas com funcionalidades estendidas nas quais os módulos do fornecedor dependem devem ser copiadas para a partição do fornecedor, mas alterações incompatíveis com ABI são proibidas.
  • O suporte ao sistema de construção VNDK descreve as configurações do sistema de construção e as sintaxes de definição de módulo relacionadas ao VNDK.
  • A ferramenta de definição VNDK ajuda a migrar sua árvore de origem para o Android 8.0 e superior.
  • O namespace do vinculador fornece controle refinado sobre as ligações da biblioteca compartilhada.
  • Directories, Rules e sepolicy definem a estrutura de diretório para dispositivos que executam o Android 8.0 e superior, regras VNDK e sepolicy associada.
  • A apresentação do VNDK Design ilustra os conceitos fundamentais do VDNK usados ​​no Android 8.0 e superior.

Conceitos VNDK

Em um Android 8.0 e mundo superior ideal, os processos de estrutura não carregam bibliotecas compartilhadas do fornecedor, todos os processos do fornecedor carregam apenas bibliotecas compartilhadas do fornecedor (e uma parte das bibliotecas compartilhadas da estrutura) e as comunicações entre os processos de estrutura e os processos do fornecedor são regidas por HIDL e hardware encadernador.

Tal mundo inclui a possibilidade de que APIs públicas estáveis ​​de bibliotecas compartilhadas de framework podem não ser suficientes para desenvolvedores de módulos de fornecedores (embora APIs possam mudar entre versões do Android), exigindo que alguma parte das bibliotecas compartilhadas de frameworks sejam acessíveis aos processos de fornecedores. Além disso, como os requisitos de desempenho podem levar a compromissos, alguns HALs críticos para o tempo de resposta devem ser tratados de maneira diferente.

As seções a seguir detalham como VNDK lida com bibliotecas compartilhadas de estrutura para fornecedores e HALs de mesmo processo (SP-HALs).

Bibliotecas compartilhadas de framework para fornecedor

Esta seção descreve os critérios para classificar bibliotecas compartilhadas que são acessíveis aos processos do fornecedor. Existem duas abordagens para oferecer suporte aos módulos do fornecedor em várias versões do Android:

  1. Estabilize os ABIs / APIs das bibliotecas compartilhadas da estrutura . Novos módulos de estrutura e módulos de fornecedores antigos podem usar a mesma biblioteca compartilhada para reduzir a área de cobertura da memória e o tamanho do armazenamento. Uma biblioteca compartilhada exclusiva também evita vários problemas de carregamento duplo. No entanto, o custo de desenvolvimento para manter ABIs / APIs estáveis ​​é alto e não é realista estabilizar todos os ABIs / APIs exportados por cada biblioteca compartilhada de estrutura.
  2. Copie as bibliotecas compartilhadas do framework antigo . Vem com a forte restrição contra canais laterais, definidos como todos os mecanismos de comunicação entre os módulos de estrutura e os módulos do fornecedor, incluindo (mas não se limitando a) binder, socket, pipe, memória compartilhada, arquivo compartilhado e propriedades do sistema. Não deve haver comunicação a menos que o protocolo de comunicação esteja congelado e estável (por exemplo, HIDL por meio de hwbinder). Bibliotecas compartilhadas de carregamento duplo também podem causar problemas; por exemplo, se um objeto criado pela nova biblioteca for passado para as funções da biblioteca antiga, pode ocorrer um erro, pois essas bibliotecas podem interpretar o objeto de maneira diferente.

Diferentes abordagens são usadas dependendo das características das bibliotecas compartilhadas. Como resultado, as bibliotecas compartilhadas do framework são classificadas em três subcategorias:

  • Bibliotecas LL-NDK são bibliotecas compartilhadas de estrutura que são conhecidas por serem estáveis. Seus desenvolvedores estão comprometidos em manter suas estabilidades de API / ABI.
    • LL-NDK inclui as seguintes bibliotecas: libEGL.so , libGLESv1_CM.so , libGLESv2.so , libGLESv3.so , libandroid_net.so , libc.so , libdl.so , liblog.so , libm.so , libnativewindow.so , libneuralnetworks.so , libsync.so , libvndksupport.so e libvulkan.so ,
  • Bibliotecas VNDK qualificadas (VNDK) são bibliotecas compartilhadas de estrutura que podem ser copiadas duas vezes com segurança. Os Módulos de estrutura e os Módulos de fornecedor podem ser vinculados às suas próprias cópias. Uma biblioteca compartilhada de estrutura pode se tornar uma biblioteca VNDK elegível apenas se atender aos seguintes critérios:
    • Ele não envia / recebe IPCs de / para a estrutura.
    • Não está relacionado à máquina virtual ART.
    • Ele não lê / grava arquivos / partições com formatos de arquivo instáveis.
    • Não possui licença de software especial que requer revisões legais.
    • Seu proprietário do código não tem objeções aos usos do fornecedor.
  • Bibliotecas somente de estrutura (APENAS FWK) são bibliotecas compartilhadas de estrutura que não pertencem às categorias mencionadas acima. Essas bibliotecas:
    • São considerados detalhes de implementação interna da estrutura.
    • Não deve ser acessado por módulos do fornecedor.
    • Ter ABIs / APIs instáveis ​​e nenhuma garantia de compatibilidade de API / ABI.
    • Não são copiados.

HAL do mesmo processo (SP-HAL)

Same-Process HAL ( SP-HAL ) é um conjunto de HALs predeterminados implementados como Bibliotecas compartilhadas de fornecedores e carregados em processos de estrutura . Os SP-HALs são isolados por um namespace de vinculador (controla as bibliotecas e os símbolos visíveis para as bibliotecas compartilhadas). Os SP-HALs devem depender apenas do LL-NDK e VNDK-SP .

VNDK-SP é um subconjunto predefinido de bibliotecas VNDK elegíveis. As bibliotecas VNDK-SP são revisadas cuidadosamente para garantir que as bibliotecas VNDK-SP de carregamento duplo nos processos da estrutura não causem problemas. Ambos os SP-HALs e VNDK-SPs são definidos pelo Google.

As seguintes bibliotecas são SP-HALs aprovados:

  • libGLESv1_CM_${driver}.so
  • libGLESv2_${driver}.so
  • libGLESv3_${driver}.so
  • libEGL_${driver}.so
  • vulkan.${driver}.so
  • android.hardware.renderscript@1.0-impl.so
  • android.hardware.graphics.mapper@2.0-impl.so

As bibliotecas VNDK-SP especificam vndk: { support_system_process: true } em seus arquivos Android.bp. Se vendor_available: false também for especificado, essas bibliotecas serão chamadas de VNDK-SP-Private e serão invisíveis para SP-HALS .

A seguir estão as bibliotecas apenas de estrutura com exceções RS (FWK-ONLY-RS) :

  • libft2.so (Renderscript)
  • libmediandk.so (Renderscript)

Terminologia VNDK

  • Módulos referem-se a bibliotecas compartilhadas ou executáveis .
  • Processos são tarefas do sistema operacional geradas a partir de Executáveis .
  • Os termos qualificados do framework referem-se aos conceitos relacionados à partição do sistema .
  • Os termos qualificados do fornecedor referem-se aos conceitos relacionados às partições do fornecedor .

Por exemplo:

  • Executáveis ​​da estrutura referem-se a executáveis ​​em /system/bin ou /system/xbin .
  • Bibliotecas compartilhadas do framework referem-se a bibliotecas compartilhadas em /system/lib[64] .
  • Módulos de estrutura referem-se a bibliotecas compartilhadas de estrutura e executáveis ​​de estrutura .
  • Processos de estrutura são processos gerados a partir de executáveis ​​de estrutura (por exemplo, /system/bin/app_process ).
  • Os executáveis ​​do fornecedor referem-se aos executáveis ​​em /vendor/bin
  • Bibliotecas compartilhadas de fornecedores referem-se a bibliotecas compartilhadas em /vendor/lib[64] .
  • Módulos de fornecedores referem-se a executáveis ​​de fornecedores e bibliotecas compartilhadas de fornecedores .
  • Processos do fornecedor são processos gerados a partir de executáveis do fornecedor (por exemplo
  • /vendor/bin/android.hardware.camera.provider@2.4-service ).

Controle de versão VNDK

No Android 9, as bibliotecas compartilhadas VNDK têm controle de versão:

  • A propriedade de sistema ro.vndk.version é adicionada automaticamente a /vendor/default.prop .
  • Bibliotecas compartilhadas VNDK são instaladas em /system/lib[64]/vndk-${ro.vndk.version} .
  • Bibliotecas compartilhadas VNDK-SP são instaladas em /system/lib[64]/vndk-sp-${ro.vndk.version} .
  • O arquivo de configuração do vinculador dinâmico é instalado em /system/etc/ld.config.${ro.vndk.version}.txt .

O valor de ro.vndk.version é escolhido pelo algoritmo abaixo:

  • Se BOARD_VNDK_VERSION não for igual a current , use BOARD_VNDK_VERSION .
  • Se BOARD_VNDK_VERSION for igual ao current :
    • Se PLATFORM_VERSION_CODENAME for REL , use PLATFORM_SDK_VERSION (por exemplo, 28 ).
    • Caso contrário, use PLATFORM_VERSION_CODENAME (por exemplo, P ).

Atualizando dispositivos

Se um dispositivo Android 8.x desabilitou a aplicação de tempo de execução VNDK ao ser construído sem BOARD_VNDK_VERSION , ele pode adicionar PRODUCT_USE_VNDK_OVERRIDE := false a BoardConfig.mk durante a atualização para Android 9.

Se PRODUCT_USE_VNDK_OVERRIDE for false , a propriedade ro.vndk.lite será adicionada automaticamente a /vendor/default.prop e seu valor será true . Consequentemente, o vinculador dinâmico carregará a configuração do namespace do vinculador de /system/etc/ld.config.vndk_lite.txt , que isola apenas SP-HAL e VNDK-SP.

Para atualizar um dispositivo Android 7.0 ou inferior para Android 9, adicione PRODUCT_TREBLE_LINKER_NAMESPACES_OVERRIDE := false a BoardConfig.mk .

Vendor Test Suite (VTS)

O Android 9 Vendor Test Suite (VTS) exige uma propriedade ro.vndk.version não vazia. Os dispositivos recém-lançados e os dispositivos de atualização devem definir ro.vndk.version . Alguns casos de teste VNDK (por exemplo, VtsVndkFilesTest e VtsVndkDependencyTest ) contam com a propriedade ro.vndk.version para carregar os conjuntos de dados de bibliotecas VNDK elegíveis correspondentes.

Se a propriedade ro.product.first_api_level for maior que 27, a propriedade ro.vndk.lite não deve ser definida. VtsTreblePlatformVersionTest falhará se ro.vndk.lite for definido em um dispositivo Android 9 recém-lançado.

Documento histórico

Esta seção rastreia as mudanças na documentação do VNDK.

Android 9 changes

  • Adicionar seção de controle de versão VNDK.
  • Adicionar seção VTS.
  • Algumas categorias VNDK foram renomeadas:
    • LL-NDK-Indirect foi renomeado para LL-NDK-Private.
    • VNDK-Indirect foi renomeado para VNDK-Private.
    • VNDK-SP-Indireto-Privado foi renomeado para VNDK-SP-Privado.
    • VNDK-SP-Indirect foi removido.

Alterações do Android 8.1

  • As bibliotecas SP-NDK foram mescladas com as bibliotecas LL-NDK.
  • Substitua libui.so por libft2.so na seção de namespace RS. Foi um erro incluir libui.so .
  • Adicione libGLESv3.so e libandroid_net.so às bibliotecas LL-NDK.
  • Adicione libion.so às bibliotecas VNDK-SP.
  • Remova libstdc++.so So das bibliotecas LL-NDK. Use libc++.so vez disso. Algumas versões de conjuntos de ferramentas independentes podem adicionar -lstdc++ aos sinalizadores de vinculador padrão. Para desativar os padrões, adicione -nodefaultlibs -lc -lm -ldl ao LDFLAGS .
  • Mova libz.so das libz.so LL-NDK para as bibliotecas VNDK-SP. Em algumas configurações, libz.so pode continuar sendo LL-NDK. No entanto, não deve haver diferenças observáveis.