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

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

Por que usar o VNDK?

O AOSP permite atualizações apenas do framework, em que é possível fazer upgrade da partição do sistema para a versão mais recente. versão do framework, enquanto a partição do fornecedor não é alterada. Apesar de terem sido criadas vezes, os binários em cada partição devem ser capazes de trabalhar entre si.

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

  • Dependência entre módulos do framework e módulos do fornecedor. Antes do Android 8.0, os módulos na partição do fornecedor e do sistema podiam ser vinculados e se relacionam entre si. No entanto, as dependências dos módulos do fornecedor impuseram restrições ao desenvolvimento de módulos do framework.
  • Extensões para bibliotecas AOSP. Android exige que todos os dispositivos Android passem no CTS quando a partição do sistema é substituída. com uma imagem genérica do sistema (GSI) padrão. No entanto, à medida que os fornecedores estendem os recursos do AOSP para melhorar o desempenho ou adicionar mais funcionalidades ao HIDL implementar uma atualização flash na partição do sistema com uma GSI padrão corromper a implementação de HIDL de um fornecedor. Para orientações sobre evitar essas falhas, consulte Extensões VNDK.

Para enfrentar esses desafios, o Android contém vários recursos, como como o VNDK (descrito nesta seção), HIDL, hwbinder, sobreposição da árvore de dispositivos 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 tornam o tempo de build dependências.
  • Processos são tarefas do sistema operacional geradas de executáveis. Os processos tornam o ambiente de execução dependências.
  • Os termos qualificados pelo framework estão relacionados à partição system:
    • Os executáveis de framework se referem aos executáveis em /system/bin ou /system/xbin.
    • Framework de bibliotecas compartilhadas se referem a bibliotecas compartilhadas em /system/lib[64]
    • Os módulos de framework se referem às duas bibliotecas compartilhadas de framework. e executáveis de framework.
    • Os processos de framework são gerados do framework. executáveis, como /system/bin/app_process.
  • Os termos qualificados de fornecedor estão relacionados às partições vendor:
    • Os executáveis de fornecedores se referem aos executáveis no /vendor/bin.
    • Bibliotecas compartilhadas do fornecedor são as bibliotecas compartilhadas em /vendor/lib[64]
    • Os módulos de fornecedor se referem aos executáveis do fornecedor e às bibliotecas compartilhadas do fornecedor.
    • Os processos do fornecedor são gerados pelo Fornecedor. Executáveis, como /vendor/bin/android.hardware.camera.provider@2.4-service.
    .
.

Conceitos do VNDK

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

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

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

Bibliotecas compartilhadas de framework para fornecedores

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

  1. Estabilizar as ABIs/APIs das bibliotecas compartilhadas do framework. Novos módulos de framework e módulos antigos de fornecedor 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 a estabilidade ABIs/APIs são altas e não é realista estabilizar todas as ABIs/APIs exportadas por todas as bibliotecas compartilhadas do framework.
  2. Copie as bibliotecas compartilhadas do framework antigo. Vem com a força restrição contra canais secundários, definida como todos os mecanismos de comunicação entre módulos de framework e módulos de fornecedor, incluindo, mas não se limitando 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 por hwbinder). O carregamento duplo de bibliotecas compartilhadas pode fazer problemas de dados em nuvem. por exemplo, se um objeto criado pela nova biblioteca for passado às 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 do compartilhamento bibliotecas. Por isso, as bibliotecas compartilhadas do framework são classificadas em três subcategorias:

  • As bibliotecas do LL-NDK são bibliotecas compartilhadas do framework que são conhecidas por serem estáveis. Os desenvolvedores da empresa estão comprometidos em manter Estabilidade 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 e libnativewindow.so, libneuralnetworks.so, libsync.so libvndksupport.so e libvulkan.so,
  • As bibliotecas do VNDK qualificadas (VNDK) são compartilhadas pelo framework Bibliotecas que podem ser copiadas com segurança duas vezes. Módulos de framework e Os módulos de fornecedores podem ser vinculados a cópias próprias. Uma estrutura compartilhada só poderá se tornar uma biblioteca VNDK qualificada se atender aos seguintes critérios:
    • Ele não envia nem recebe IPCs da estrutura.
    • Ele não está relacionado à máquina virtual ART.
    • Ele não lê/grava arquivos/partições com formatos de arquivo instáveis.
    • Ele não tem uma licença de software especial, o que requer análises legais.
    • O proprietário do código não tem objeções ao uso do fornecedor.
  • As bibliotecas somente de framework (FWK-ONLY) são compartilhadas de framework Bibliotecas que não pertencem às categorias mencionadas acima. Esses bibliotecas:
    • São considerados detalhes de implementação internos do framework.
    • Não pode ser acessado por módulos de fornecedores.
    • têm ABIs/APIs instáveis e não há garantia de compatibilidade com elas.
    • Não são copiados.

HAL de mesmo processo (SP-HAL)

HAL de mesmo processo (SP-HAL) é um conjunto de HALs predeterminadas implementados como bibliotecas compartilhadas de fornecedores e carregados no Framework Processos. SP-HALs são isoladas por um namespace de vinculador (controla a bibliotecas e símbolos que são visíveis para as bibliotecas compartilhadas). SP-HALs devem dependem apenas de LL-NDK e VNDK-SP.

O VNDK-SP é um subconjunto predefinido de bibliotecas do VNDK qualificadas. Bibliotecas VNDK-SP são cuidadosamente revisados para garantir o carregamento duplo de bibliotecas VNDK-SP na estrutura e processos não causa problemas. Os SP-HALs e VNDK-SPs são definidos por 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 especificadas, essas bibliotecas são chamadas de VNDK-SP-Private e são invisível para SP-HALS.

Confira a seguir bibliotecas somente de framework com exceções de RS (FWK-ONLY-RS):

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

Controle de versão do VNDK

As bibliotecas compartilhadas do VNDK têm controle de versões:

  • 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 do VNDK. com.android.vndk.v${ro.vndk.version} e montado 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 Pacote de testes de fornecedor do Android (VTS, na sigla em inglês) exige uma propriedade ro.vndk.version não vazia. Ambos os dispositivos recém-lançados e dispositivos em upgrade precisam definir ro.vndk.version. Algum teste de VNDK casos (por exemplo, VtsVndkFilesTest e VtsVndkDependencyTest) dependem do ro.vndk.version para carregar os conjuntos de dados das bibliotecas VNDK qualificadas correspondentes.