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

Kit de desenvolvimento nativo do fornecedor (VNDK)

O Vendor Native Development Kit (VNDK) é um conjunto de bibliotecas exclusivamente para fornecedores implementarem seus HALs. Os navios VNDK em system.img e é dinamicamente ligado ao código de fornecedor em tempo de execução.

Por que VNDK?

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

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

  • Dependência entre módulos de estrutura e módulos de fornecedores. 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 impõem restrições indesejadas ao desenvolvimento dos módulos da estrutura.
  • Extensões para bibliotecas AOSP. O Android 8.0 e superior requer 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, conforme 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 orientações sobre a prevenção de tais rupturas, ver extensões VNDK .)

Para enfrentar esses desafios, o Android 8.0 introduz várias técnicas, tais como VNDK (descrito nesta seção), HIDL , hwbinder, dispositivo de sobreposição de árvore , e sobreposição sepolicy.

Recursos VNDK

Esta seção inclui os seguintes recursos VNDK:

  • Conceitos VNDK (abaixo) descreve bibliotecas estrutura compartilhada, Hals do mesmo processo (SP-HALs), e terminologia VNDK.
  • Extensões VNDK específica do fornecedor classifica muda em categorias. Por exemplo, bibliotecas com funcionalidades estendidas nas quais os módulos do fornecedor dependem devem ser copiadas para a partição do fornecedor, mas alterações incompatíveis com ABI são proibidas.
  • VNDK construir o apoio do sistema descreve as configurações de sistemas de construção e sintaxes definição de módulo que estão relacionados com VNDK.
  • O VNDK Definição Ferramenta ajuda a migrar seu árvore de origem para Android 8.0 e superior.
  • Linker Namespace fornece controle de grão fino sobre ligações de bibliotecas compartilhadas.
  • Diretórios, regras e sepolicy define a estrutura de diretório para dispositivos que executam o Android 8.0 e, regras mais elevados VNDK e sepolicy associado.
  • O VNDK Projeto apresentação ilustra os conceitos VDNK fundamentais usados em Android 8.0 e superior.

Conceitos VNDK

Em um Android 8.0 e mundo superior ideal, os processos de 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 regidas por HIDL e hardware encadernador.

Tal mundo inclui a possibilidade de que APIs públicas estáveis ​​de bibliotecas compartilhadas de estrutura podem não ser suficientes para desenvolvedores de módulos de fornecedores (embora APIs possam mudar entre versões do Android), exigindo que alguma parte das bibliotecas compartilhadas de estruturas sejam acessíveis aos processos do fornecedor. Além disso, como os requisitos de desempenho podem levar a compromissos, alguns HALs críticos para o tempo de resposta devem ser tratados de maneira 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 framework 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. Estabilizar os ABIs / APIs do quadro bibliotecas compartilhadas. Novos módulos de estrutura e módulos de fornecedores antigos podem usar a mesma biblioteca compartilhada para reduzir a área de cobertura da 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 todos os ABIs / APIs exportados por cada biblioteca compartilhada de estrutura.
  2. Copie as bibliotecas compartilhadas quadro de idade. Vem com a forte restrição contra canais laterais, definidos como todos os mecanismos de comunicação entre módulos de estrutura e módulos de fornecedores, incluindo (mas não se limitando 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 por meio de hwbinder). Bibliotecas compartilhadas de carregamento duplo também podem 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 do framework são classificadas em três subcategorias:

  • LL-NDK bibliotecas são Framework bibliotecas compartilhadas que são conhecidos por ser estável. Seus desenvolvedores estão comprometidos em manter suas estabilidades de 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 ,
  • Elegíveis Bibliotecas VNDK (VNDK) são Framework bibliotecas compartilhadas que são seguros para ser copiado duas vezes. Quadro Módulos e Vendor módulos podem vincular com suas próprias cópias. Uma biblioteca compartilhada de estrutura pode se tornar uma biblioteca VNDK elegível apenas 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.
    • Seu proprietário do código não tem objeções aos usos do fornecedor.
  • Quadro-Somente Bibliotecas (FWK-ONLY) estão Framework bibliotecas compartilhadas que não pertencem às categorias mencionadas acima. Essas bibliotecas:
    • São considerados detalhes de implementação interna da estrutura.
    • Não deve ser acessado por módulos do fornecedor.
    • Ter ABIs / APIs instáveis ​​e nenhuma garantia de compatibilidade de API / ABI.
    • Não são copiados.

HAL do mesmo processo (SP-HAL)

-Mesmo processo HAL (SP-HAL) é um conjunto de HALS predeterminados implementadas como bibliotecas compartilhadas fornecedor e carregados em Processos Framework. Os SP-HALs são isolados por um namespace de vinculador (controla as bibliotecas e os símbolos visíveis para as bibliotecas compartilhadas). SP-HAL deve depender somente de LL-NDK e VNDK-SP.

VNDK-SP é um subconjunto predefinido de bibliotecas VNDK elegíveis. As bibliotecas VNDK-SP são revisadas cuidadosamente para garantir que as bibliotecas VNDK-SP de carregamento duplo nos processos da estrutura não causem problemas. Ambos SP-HALs e VNDK-SPs são definidos pelo Google.

As seguintes bibliotecas são SP-HALs aprovados:

  • 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

Bibliotecas VNDK-SP especificar vndk: { support_system_process: true } em seus arquivos Android.bp. Se vendor_available: false também for especificado, em seguida, essas bibliotecas são chamados-VNDK-SP Privada e eles são invisíveis para o SP-HALS.

A seguir estão as bibliotecas só de quadro com exceções RS (FWK-Somente-RS):

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

Terminologia VNDK

  • Módulos de se referir tanto a bibliotecas compartilhadas ou executáveis.
  • Processos estão operando tarefas do sistema gerado a partir executáveis.
  • Quadro -qualified termos referem-se os conceitos relacionados com a partição do sistema.
  • Vendedor termos -qualified referem-se aos conceitos relacionados com partições de fornecedores.

Por exemplo:

  • Quadro executáveis consulte executáveis em /system/bin ou /system/xbin .
  • Framework bibliotecas compartilhadas referem-se a bibliotecas compartilhadas sob /system/lib[64] .
  • Quadro Módulos referir tanto bibliotecas compartilhadas Framework e Framework executáveis.
  • Processos de enquadramento são geradas a partir de processos Quadro executáveis (por exemplo, /system/bin/app_process ).
  • Executáveis fornecedores referem-se a executáveis em /vendor/bin
  • Vendedor bibliotecas compartilhadas referem-se a bibliotecas compartilhadas sob /vendor/lib[64] .
  • Vendedor Módulos referir tanto Vendor executáveis e fornecedores bibliotecas compartilhadas.
  • Processos de fornecedor são processos gerados a partir do fornecedor executáveis (por exemplo,
  • /vendor/bin/android.hardware.camera.provider@2.4-service ).

Controle de versão VNDK

No Android 9, as bibliotecas compartilhadas VNDK têm controle de versão:

  • O ro.vndk.version propriedade do sistema é automaticamente adicionado ao /vendor/default.prop .
  • VNDK compartilhada bibliotecas são instaladas para /system/lib[64]/vndk-${ro.vndk.version} .
  • VNDK-SP compartilhada bibliotecas são instaladas para /system/lib[64]/vndk-sp-${ro.vndk.version} .
  • O arquivo de configuração vinculador dinâmico é instalado para /system/etc/ld.config.${ro.vndk.version}.txt .

O valor da ro.vndk.version é escolhido pelo algoritmo abaixo:

  • Se BOARD_VNDK_VERSION não é igual a current , o uso BOARD_VNDK_VERSION .
  • Se BOARD_VNDK_VERSION é igual a current :
    • Se PLATFORM_VERSION_CODENAME é REL , o uso PLATFORM_SDK_VERSION (por exemplo 28 ).
    • Caso contrário, o uso PLATFORM_VERSION_CODENAME (por exemplo, P ).

Atualizando dispositivos

Se um desativado VNDK aplicação de tempo de execução do dispositivo 8.x Android por ser construído sem BOARD_VNDK_VERSION , pode adicionar PRODUCT_USE_VNDK_OVERRIDE := false para BoardConfig.mk durante a atualização para Android 9.

Se PRODUCT_USE_VNDK_OVERRIDE é false , o ro.vndk.lite propriedade será automaticamente adicionado ao /vendor/default.prop e seu valor será true . Consequentemente, o ligante dinâmica vai carregar a configuração do ligador espaço de nomes de /system/etc/ld.config.vndk_lite.txt , que isola única SP-HAL e VNDK-SP.

Para atualizar um dispositivo Android 7.0 ou inferior para Android 9, adicione PRODUCT_TREBLE_LINKER_NAMESPACES_OVERRIDE := false para BoardConfig.mk .

Vendor Test Suite (VTS)

O Android 9 Vendor Test Suite (VTS) mandatos que um não-vazia ro.vndk.version propriedade. Ambos os dispositivos recém-lançado e dispositivos de modernização deve definir ro.vndk.version . Alguns casos de teste VNDK (por exemplo VtsVndkFilesTest e VtsVndkDependencyTest ) contam com a ro.vndk.version propriedade para carregar os correspondentes elegíveis bibliotecas VNDK conjuntos de dados.

Se o ro.product.first_api_level propriedade é maior que 27, o ro.vndk.lite propriedade não deve ser definida. VtsTreblePlatformVersionTest falhará se ro.vndk.lite é definida em um dispositivo Android 9 recém-lançado.

Documento histórico

Esta seção rastreia as mudanças na documentação do VNDK.

Android 9 changes

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

Alterações do Android 8.1

  • As bibliotecas SP-NDK foram mescladas com as bibliotecas LL-NDK.
  • Substitua libui.so com libft2.so no RS seção de namespace. Foi um erro de incluir libui.so .
  • Adicionar libGLESv3.so e libandroid_net.so a bibliotecas LL-NDK.
  • Adicionar libion.so a bibliotecas VNDK-SP.
  • Remover libstdc++.so de bibliotecas LL-NDK. Use libc++.so em vez. Algumas versões do toolchains autônomos podem adicionar -lstdc++ para as bandeiras vinculador padrão. Para desativar os padrões, adicionar -nodefaultlibs -lc -lm -ldl para LDFLAGS .
  • Mova libz.so de LL-NDK para bibliotecas VNDK-SP. Em algumas configurações, libz.so pode continuar sendo LL-NDK. No entanto, não deve haver diferenças observáveis.