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

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

Previsão de remoção

O NDK do fornecedor foi introduzido no Android 8.0 para fornecer APIs entre o framework e o código do fornecedor. Embora o VNDK seja usado com sucesso há muitos anos, ele tem algumas desvantagens:
  • Armazenamento
    • Um único pacote VNDK APEX inclui todas as bibliotecas VNDK, usadas ou não pelo dispositivo.
    • A GSI contém várias versões de VNDK APEXes para oferecer suporte a várias versões de imagens de fornecedores.
  • Capacidade de atualização
    • É difícil atualizar os APEXs do VNDK separadamente da atualização da plataforma.
    • As imagens do fornecedor são atualizadas com frequência por OTA (over the air), reduzindo os benefícios de ter o VNDK empacotado na imagem do sistema.
Com base nesses problemas, decidimos descontinuar o VNDK a partir do Android 15.

Detalhes sobre a descontinuação do VNDK

Todas as bibliotecas VNDK são empacotadas no APEX do VNDK e instaladas na imagem do sistema (-ext). Com a descontinuação do VNDK, as bibliotecas VNDK anteriores são instaladas na imagem do fornecedor (ou do produto), assim como outras bibliotecas disponíveis para o fornecedor. Esses recursos são removidos com a descontinuação do VNDK:
  • VNDK APEX para Android 15
  • As propriedades do sistema que indicam a versão do VNDK de destino são removidas se as partições do fornecedor ou do produto forem criadas para o Android 15:
    • ro.vndk.version
    • ro.product.vndk.version
  • As otimizações do VNDK não estarão disponíveis porque não há VNDK:
    • TARGET_VNDK_USING_CORE_VARIANT para dispositivos Android Go
    • use_vndk_as_stable para APEXs de fornecedores
  • Snapshot do fornecedor, que depende muito do VNDK

Exceções da suspensão de uso

Estes recursos não vão mudar com a suspensão do uso do VNDK:
  • APEXs do VNDK com a versão 14 ou anterior, que são necessários para oferecer suporte às imagens do fornecedor atuais.
  • O LL-NDK não faz parte do VNDK.

Por que usar o VNDK?

O AOSP permite atualizações somente de framework em que a partição do sistema pode ser atualizada para a versão mais recente do framework, enquanto a partição do fornecedor permanece inalterada. Apesar de serem criados em momentos diferentes, os binários em cada partição precisam funcionar juntos.

As atualizações somente do framework incluem os seguintes desafios:

  • Dependência entre módulos de framework e módulos de fornecedor. Antes do Android 8.0, os módulos nas partições do fornecedor e do sistema podiam ser vinculados uns aos outros. No entanto, as dependências dos módulos do fornecedor impuseram restrições indesejadas ao desenvolvimento de módulos do framework.
  • Extensões para bibliotecas do AOSP. O Android exige que todos os dispositivos Android passem 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 do AOSP para aumentar o desempenho ou adicionar funcionalidades extras às implementações do HIDL, o flash da partição do sistema com uma GSI padrão pode interromper a implementação do HIDL de um fornecedor. Para diretrizes sobre como evitar essas falhas, consulte Extensões do VNDK.

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

Termos específicos do VNDK

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

Conceitos de VNDK

Em um mundo ideal com Android 8.0 e versões mais recentes, os processos do framework não carregam bibliotecas compartilhadas do fornecedor, todos os processos do fornecedor carregam apenas bibliotecas compartilhadas do fornecedor (e uma parte das bibliotecas compartilhadas do framework), e as comunicações entre processos do framework e processos do fornecedor são regidas pelo HIDL e pelo binder de hardware.

Esse mundo inclui a possibilidade de que APIs públicas e estáveis de bibliotecas compartilhadas de framework não sejam suficientes para desenvolvedores de módulos de fornecedores (embora as APIs possam mudar entre versões do Android), exigindo que uma parte das bibliotecas compartilhadas de framework seja acessível aos processos do fornecedor. Além disso, como os requisitos de desempenho podem levar a concessões, algumas HALs críticas para o tempo de resposta precisam ser tratadas de maneira diferente.

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

Bibliotecas compartilhadas de framework para fornecedor

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

  1. Estabilize as ABIs/APIs das bibliotecas compartilhadas do framework. Os módulos de framework novos e antigos podem usar a mesma biblioteca compartilhada para reduzir a ocupação 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 é irrealista estabilizar todas as ABIs/APIs exportadas por todas as bibliotecas compartilhadas de frameworks.
  2. Copie as bibliotecas compartilhadas do framework antigo. Vem com a forte restrição contra canais laterais, definidos como todos os mecanismos para comunicação entre módulos de framework e 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 pode haver comunicação, a menos que o protocolo de comunicação esteja congelado e estável (por exemplo, HIDL via hwbinder). O carregamento duplo de bibliotecas compartilhadas também pode causar problemas. Por exemplo, se um objeto criado pela nova biblioteca for transmitido para as funções da biblioteca antiga, poderá ocorrer um erro, já que essas bibliotecas podem interpretar o objeto de maneira diferente.

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

  • As bibliotecas LL-NDK são bibliotecas compartilhadas do framework conhecidas por serem estáveis. Os desenvolvedores estão comprometidos em manter a estabilidade da API/ABI.
    • O 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.
  • As bibliotecas VNDK qualificadas (VNDK) são bibliotecas compartilhadas de framework que podem ser copiadas duas vezes sem problemas. Os módulos de framework e os módulos de fornecedor podem ser vinculados às próprias cópias. Uma biblioteca compartilhada de framework só pode se tornar uma biblioteca VNDK qualificada se atender aos seguintes critérios:
    • Ele não envia/recebe IPCs para/do framework.
    • Não está relacionado à máquina virtual ART.
    • Ele não lê/grava arquivos/partições com formatos instáveis.
    • Não tem uma licença de software especial que exija análises jurídicas.
    • O proprietário do código não tem objeções ao uso de fornecedores.
  • As bibliotecas somente de framework (FWK-ONLY) são bibliotecas compartilhadas de framework que não pertencem às categorias mencionadas acima. Estas bibliotecas:
    • São considerados detalhes internos de implementação do framework.
    • Não pode ser acessado por módulos de fornecedores.
    • Ter ABIs/APIs instáveis e não ter garantias de compatibilidade de API/ABI.
    • Não são copiados.

HAL do mesmo processo (SP-HAL)

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

O VNDK-SP é um subconjunto predefinido de bibliotecas VNDK qualificadas. As bibliotecas VNDK-SP são revisadas com cuidado para garantir que o carregamento duplo de bibliotecas VNDK-SP em processos de framework não cause problemas. As SP-HALs e os 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 } nos arquivos Android.bp. Se vndk: {private:true} também for especificado, essas bibliotecas serão chamadas de VNDK-SP-Private e ficarão invisíveis para SP-HALS.

As seguintes são bibliotecas somente de framework com exceções de RS (FWK-ONLY-RS):

  • libft2.so (RenderScript)
  • libmediandk.so (RenderScript)

Controle de versões do VNDK

As bibliotecas compartilhadas do VNDK são versionadas:

  • A propriedade do 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).

Teste de fornecedor (VTS)

O Conjunto de teste de fornecedor do Android (VTS) exige uma propriedade ro.vndk.version não vazia. Os dispositivos recém-lançados e os que estão sendo atualizados precisam definir ro.vndk.version. Alguns casos de teste do VNDK (por exemplo, VtsVndkFilesTest e VtsVndkDependencyTest) dependem da propriedade ro.vndk.version para carregar os conjuntos de dados de bibliotecas VNDK correspondentes qualificados.