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 é fornecido em system.img e é vinculado dinamicamente ao código do fornecedor em tempo de execução.

Por que VNDK?

O Android 8.0 e superior permite atualizações somente de estrutura nas quais 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 os binários construídos em momentos diferentes devem ser capazes de trabalhar uns com os outros; O VNDK abrange as alterações de API/ABI nas versões do Android.

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 de ambos os lados podiam ser vinculados aos módulos do outro lado. 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 8.0 e superior 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 tais quebras, consulte Extensões VNDK .)

Para enfrentar esses desafios, o Android 8.0 apresenta várias técnicas, como VNDK (descrito nesta seção), HIDL , hwbinder, device tree overlay e sepolicy overlay.

Recursos VNDK

Esta seção inclui os seguintes recursos do VNDK:

• Os conceitos VNDK (abaixo) descrevem bibliotecas compartilhadas de estrutura, HALs de mesmo processo (SP-HALs) e terminologia VNDK.
• As extensões VNDK classificam as alterações específicas do fornecedor em categorias. Por exemplo, bibliotecas com funcionalidades estendidas nas quais os módulos do fornecedor dependem devem ser copiadas na partição do fornecedor, mas alterações incompatíveis com ABI são proibidas.
• O suporte ao sistema de compilação do VNDK descreve as configurações do sistema de compilaçã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.
• Linker Namespace fornece controle refinado sobre os vínculos de bibliotecas compartilhadas.
• Diretórios, regras e sepolicy define a estrutura de diretórios para dispositivos que executam o Android 8.0 e superior, regras VNDK e sepolicy associado.
• A apresentação do VNDK Design ilustra os conceitos fundamentais do VDNK usados ​​no Android 8.0 e superior.

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
• [e-mail]
• [e-mail]

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 .

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

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

Cuidado: a partir do Android 12, as APIs RenderScript estão obsoletas. Eles continuarão a funcionar , mas espera-se que os fabricantes de dispositivos e componentes parem de fornecer suporte de aceleração de hardware ao longo do tempo. Para aproveitar ao máximo a aceleração de GPU, o AOSP recomenda que você Migre do RenderScript .

Terminologia VNDK

• Módulos referem-se a Bibliotecas Compartilhadas ou Executáveis .
• Processos são tarefas do sistema operacional geradas a partir de Executables .
• Os termos qualificados de estrutura 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 ​​do Framework referem-se a executáveis ​​em /system/bin ou /system/xbin .
• Bibliotecas Compartilhadas do Framework referem-se a bibliotecas compartilhadas em /system/lib[64] .
• Os Módulos do Framework referem-se a Bibliotecas Compartilhadas do Framework e Executáveis ​​do Framework .
• Processos de estrutura são processos gerados a partir de executáveis ​​de estrutura (por exemplo /system/bin/app_process ).
• Executáveis ​​de fornecedor referem-se a executáveis ​​em /vendor/bin
• As Bibliotecas Compartilhadas do Fornecedor referem-se a bibliotecas compartilhadas em /vendor/lib[64] .
• Módulos de fornecedor referem-se a executáveis de fornecedor e bibliotecas compartilhadas de fornecedor.
• Processos de fornecedor são processos gerados a partir de executáveis ​​de fornecedor (por exemplo,
/vendor/bin/android.hardware.camera.provider@2.4-service ).

Observação: a imagem genérica do sistema (GSI) significa a imagem padrão do sistema Android criada a partir de ramificações correspondentes (semelhante à ramificação de lançamento, mas com algumas correções de bugs ou algumas generalizações) e lançada pelo Google.

Versão do VNDK

No Android 9, as bibliotecas compartilhadas do VNDK são versionadas:

• A propriedade do sistema ro.vndk.version é adicionada automaticamente a /vendor/default.prop .
• As bibliotecas compartilhadas do VNDK são instaladas em /system/lib[64]/vndk-${ro.vndk.version} .
• As 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 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 ).

Atualizando dispositivos

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

Se PRODUCT_USE_VNDK_OVERRIDE for false , a propriedade ro.vndk.lite será automaticamente adicionada a /vendor/default.prop e seu valor será true . Conseqüentemente, 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 o Android 9, adicione PRODUCT_TREBLE_LINKER_NAMESPACES_OVERRIDE := false a BoardConfig.mk .

Pacote de teste do fornecedor (VTS)

O Android 9 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.

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 estiver definido em um dispositivo Android 9 recém-lançado.

Documento histórico

Esta seção acompanha as alterações na documentação do VNDK.

Mudanças no Android 9

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

Mudanças no Android 8.1

• As bibliotecas SP-NDK foram mescladas nas 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 das bibliotecas LL-NDK. Use libc++.so em vez disso. Algumas versões de cadeias de ferramentas independentes podem adicionar -lstdc++ aos sinalizadores de vinculador padrão. Para desabilitar os padrões, adicione -nodefaultlibs -lc -lm -ldl a LDFLAGS .
• Mova libz.so das bibliotecas LL-NDK para VNDK-SP. Em algumas configurações, libz.so pode continuar sendo LL-NDK. No entanto, não deve haver diferenças observáveis.