Visão geral do kit de desenvolvimento nativo do fornecedor (VNDK)

O Vendor Native Development Kit (VNDK) é um conjunto de bibliotecas usadas por outras bibliotecas ou binários, na partição do fornecedor ou do produto, em tempo de execução para dlopen.

Por que VNDK?

O AOSP permite atualizações somente de estrutura nas quais a partição do sistema pode ser atualizada para a versão mais recente da estrutura, enquanto a partição do fornecedor permanece inalterada. Apesar de serem construídos em momentos diferentes, os binários em cada partição devem ser capazes de trabalhar uns com os outros.

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

  • Dependência entre módulos da estrutura e módulos do fornecedor . Antes do Android 8.0, os módulos do fornecedor e da partição do sistema podiam ser vinculados entre si. No entanto, as dependências dos módulos do fornecedor impuseram restrições indesejadas ao desenvolvimento dos módulos da estrutura.
  • Extensões para bibliotecas AOSP . O Android exige 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, à medida que os fornecedores estendem as bibliotecas AOSP para aumentar o desempenho ou adicionar funcionalidades extras às suas implementações de HIDL, atualizar a partição do sistema com um GSI padrão pode interromper a implementação de HIDL de um fornecedor. Para obter diretrizes sobre como evitar tais quebras, consulte Extensões VNDK .

Para enfrentar esses desafios, o Android contém vários recursos, como VNDK (descrito nesta seção), HIDL , hwbinder, sobreposição de árvore de dispositivos e sobreposição de sepolicy.

Termos específicos do VNDK

Os documentos relacionados ao VNDK usam a seguinte terminologia:
  • Módulos referem-se a bibliotecas compartilhadas ou executáveis. Os módulos criam dependências em tempo de construção.
  • Processos são tarefas do sistema operacional geradas a partir de executáveis. Os processos criam dependências em tempo de execução.
  • Os termos qualificados pela estrutura estão relacionados à partição system :
    • Executáveis ​​de estrutura referem-se a executáveis ​​em /system/bin ou /system/xbin .
    • Bibliotecas compartilhadas da estrutura referem-se a bibliotecas compartilhadas em /system/lib[64] .
    • Os módulos da estrutura referem-se às bibliotecas compartilhadas da estrutura e aos executáveis ​​da estrutura.
    • Processos de estrutura são processos gerados a partir de executáveis ​​de estrutura, como /system/bin/app_process .
  • Os termos qualificados do fornecedor estão relacionados às partições vendor :
    • Os executáveis ​​do fornecedor referem-se aos executáveis ​​em /vendor/bin
    • Bibliotecas compartilhadas do fornecedor referem-se a bibliotecas compartilhadas em /vendor/lib[64] .
    • Os módulos do fornecedor referem-se aos executáveis ​​do fornecedor e às bibliotecas compartilhadas do fornecedor.
    • Os processos do fornecedor são processos gerados a partir de executáveis ​​do fornecedor, como /vendor/bin/android.hardware.camera.provider@2.4-service .

Conceitos de VNDK

Em um mundo ideal do Android 8.0 e superior, os processos da 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 da estrutura e os processos do fornecedor são governadas por HIDL e hardware encadernador.

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

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

Bibliotecas compartilhadas de estrutura 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 a módulos de fornecedores em várias versões do Android:

  1. Estabilize as 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 o consumo de 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 todas as ABIs/APIs exportadas por cada biblioteca compartilhada de estrutura.
  2. Copie bibliotecas compartilhadas de estruturas antigas . Vem com forte restrição contra canais laterais, definidos como todos os mecanismos de comunicação entre módulos da estrutura e módulos do fornecedor, incluindo (mas não limitado a) binder, soquete, 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 através de hwbinder). O carregamento duplo de bibliotecas compartilhadas também pode causar problemas; por exemplo, se um objeto criado pela nova biblioteca for passado para as funções da biblioteca antiga, poderá ocorrer um erro, pois essas bibliotecas podem interpretar o objeto de maneira diferente.

Diferentes abordagens são utilizadas dependendo das características das bibliotecas compartilhadas. Como resultado, as bibliotecas compartilhadas da estrutura são classificadas em três subcategorias:

  • Bibliotecas LL-NDK são bibliotecas compartilhadas de estrutura conhecidas por serem estáveis. Seus desenvolvedores estão comprometidos em manter a estabilidade de suas 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. Módulos de estrutura e módulos de fornecedor podem ser vinculados a suas próprias cópias. Uma biblioteca compartilhada de estrutura só poderá se tornar uma biblioteca VNDK qualificada 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 exija revisões legais.
    • O proprietário do código não tem objeções ao uso do fornecedor.
  • Bibliotecas somente de estrutura (SOMENTE FWK) são bibliotecas compartilhadas de estrutura que não pertencem às categorias mencionadas acima. Estas bibliotecas:
    • São considerados detalhes de implementação interna do framework.
    • Não deve ser acessado por módulos do fornecedor.
    • Têm ABIs/APIs instáveis ​​e nenhuma garantia de compatibilidade de API/ABI.
    • Não são copiados.

HAL do mesmo processo (SP-HAL)

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

VNDK-SP é um subconjunto predefinido de bibliotecas VNDK qualificadas. As bibliotecas VNDK-SP são cuidadosamente revisadas para garantir que o carregamento duplo de bibliotecas VNDK-SP nos processos da estrutura não cause problemas. Tanto SP-HALs quanto VNDK-SPs são definidos pelo Google.

As seguintes bibliotecas são SP-HALs aprovadas:

  • 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 vndk: {private:true} 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 bibliotecas somente de estrutura com exceções RS (FWK-ONLY-RS) :

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

Controle de versão VNDK

As bibliotecas compartilhadas do VNDK têm controle de versão:

  • A propriedade de sistema ro.vndk.version é adicionada automaticamente a /vendor/default.prop .
  • As bibliotecas compartilhadas VNDK e VNDK-SP são instaladas como um apex VNDK com.android.vndk.v${ro.vndk.version} e montadas em /apex/com.android.vndk.v${ro.vndk.version} .

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 a current :
    • Se PLATFORM_VERSION_CODENAME for REL , use PLATFORM_SDK_VERSION (por exemplo, 28 ).
    • Caso contrário, use PLATFORM_VERSION_CODENAME (por exemplo, P ).

Conjunto de testes de fornecedores (VTS)

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