O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

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 da estrutura em que 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 somente do framework incluem os seguintes desafios:

  • Dependência entre módulos de estrutura e módulos de fornecedor . Antes do Android 8.0, os módulos no fornecedor e na 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 do framework.
  • Extensões para bibliotecas AOSP . O Android exige que todos os dispositivos Android passem pelo CTS quando a partição do sistema é substituída por uma imagem de sistema genérica (GSI) padrão. No entanto, como 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 diretrizes sobre como evitar essas quebras, consulte Extensões VNDK .

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

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 compilaçã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 de estrutura estão relacionados à partição do system :
    • Os executáveis ​​do framework referem-se aos executáveis ​​em /system/bin ou /system/xbin .
    • Bibliotecas compartilhadas do framework referem-se a bibliotecas compartilhadas em /system/lib[64] .
    • Os 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, como /system/bin/app_process .
  • Os termos qualificados do fornecedor estão relacionados às partições do vendor :
    • Os executáveis ​​do fornecedor referem-se aos executáveis ​​em /vendor/bin
    • Bibliotecas compartilhadas de fornecedor referem-se a bibliotecas compartilhadas em /vendor/lib[64] .
    • Os módulos do fornecedor referem-se a executáveis ​​do fornecedor e bibliotecas compartilhadas do fornecedor.
    • Processos de fornecedor são processos gerados a partir de executáveis ​​de fornecedor, como /vendor/bin/android.hardware.camera.provider@2.4-service .

Conceitos VNDK

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

Esse mundo inclui a possibilidade de que APIs públicas estáveis ​​de bibliotecas compartilhadas de framework possam não ser 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 frameworks seja acessível aos processos de fornecedores. Além disso, como os requisitos de desempenho podem levar a comprometimentos, alguns HALs de tempo de resposta crítico devem ser tratados de maneira diferente.

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

Bibliotecas compartilhadas de estrutura para fornecedor

Esta seção descreve os critérios para classificar as bibliotecas compartilhadas 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 do framework . Novos módulos de estrutura e módulos de fornecedores antigos podem usar a mesma biblioteca compartilhada para reduzir o espaço ocupado pela 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 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 estrutura e módulos de fornecedores, incluindo (mas não limitado 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 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, 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 de estrutura são classificadas em três subcategorias:

  • As bibliotecas LL-NDK são bibliotecas compartilhadas de estrutura conhecidas por serem estáveis. Seus desenvolvedores estão comprometidos em manter suas estabilidades de 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 elegíveis (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 pode se tornar uma biblioteca VNDK qualificada somente 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.
    • O proprietário do código não tem objeções ao uso do fornecedor.
  • Bibliotecas somente de estrutura (FWK-ONLY) são bibliotecas compartilhadas de estrutura que não pertencem às categorias mencionadas acima. Essas bibliotecas:
    • São considerados detalhes de implementação interna do framework.
    • Não deve ser acessado por módulos de fornecedores.
    • Têm ABIs/APIs instáveis ​​e nenhuma garantia de compatibilidade 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 . SP-HALs são isolados por um namespace de vinculador (controla as bibliotecas e os 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 elegíveis. As bibliotecas VNDK-SP são cuidadosamente revisadas para garantir que o carregamento duplo de bibliotecas VNDK-SP em processos de estrutura não cause problemas. Ambos SP-HALs e 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 VNDK-SP-Private e serão invisíveis para SP-HALS.

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

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

Versão 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 VNDK apex 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 ).

Pacote de teste do fornecedor (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 do VNDK (por exemplo, VtsVndkFilesTest e VtsVndkDependencyTest ) dependem da propriedade ro.vndk.version para carregar os conjuntos de dados de bibliotecas VNDK elegíveis correspondentes.