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 de estrutura nas quais 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.

Atualizações somente de 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 na partição do fornecedor e 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 interromper a implementação HIDL de um fornecedor. Para obter diretrizes sobre como evitar essas interrupções, consulte Extensões do VNDK .

Para enfrentar esses desafios, o Android contém vários recursos, como VNDK (descrito nesta seção), HIDL , hwbinder, sobreposição de árvore de dispositivos e sobreposição de política de segurança.

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 de tempo de construção.
• Processos são tarefas do sistema operacional geradas a partir de executáveis. Os processos criam dependências de tempo de execução.
• Os termos qualificados pela estrutura estão relacionados à partição system :
• Executáveis ​​de estrutura referem-se a executáveis ​​em /system/bin ou /system/xbin .
• Bibliotecas compartilhadas de estrutura referem-se a bibliotecas compartilhadas em /system/lib[64] .
• 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 vendor :
• Os executáveis ​​do fornecedor referem-se aos executáveis ​​em /vendor/bin
• As bibliotecas compartilhadas do fornecedor referem-se às bibliotecas compartilhadas em /vendor/lib[64] .
• Módulos de fornecedores referem-se a executáveis ​​de fornecedores e bibliotecas compartilhadas de fornecedores.
• Os processos do fornecedor são processos gerados a partir dos executáveis ​​do fornecedor, como /vendor/bin/android.hardware.camera.provider@2.4-service .

Conceitos de VNDK

Em um mundo Android 8.0 e 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 regidos por HIDL e hardware encadernador.

Esse mundo inclui a possibilidade de que APIs públicas e estáveis ​​de bibliotecas compartilhadas de estrutura possam não ser suficientes para desenvolvedores de módulos de fornecedores (embora as APIs possam mudar entre as versões do Android), exigindo que alguma parte das bibliotecas compartilhadas de estrutura seja acessível a processos de fornecedores. Além disso, como os requisitos de desempenho podem levar a concessões, 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 HALs de mesmo processo (SP-HALs).

Bibliotecas compartilhadas da estrutura para o 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 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 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 da estrutura antiga . Vem com 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 limitado a) fichário, 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 através do 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 da 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.
  • 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 ,
• Bibliotecas VNDK qualificadas (VNDK) são bibliotecas compartilhadas de estrutura seguras para serem copiadas duas vezes. Módulos de estrutura e módulos de fornecedores podem ser vinculados 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 o framework.
  • 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 exija revisões legais.
  • O proprietário do código não tem objeções aos usos do fornecedor.
• Bibliotecas somente de estrutura (FWK-ONLY) são bibliotecas compartilhadas de estrutura que não pertencem às categorias mencionadas acima. Estas bibliotecas:
  • São considerados detalhes de implementação interna do framework.
  • Não deve ser acessado por módulos do fornecedor.
  • Tenha ABIs/APIs instáveis ​​e nenhuma garantia de compatibilidade de API/ABI.
  • Não são copiados.

HAL de mesmo processo (SP-HAL)

HAL de mesmo processo ( SP-HAL ) é um conjunto de HALs predeterminados implementados como bibliotecas compartilhadas de fornecedores e carregados em processos de estrutura . 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-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. 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 de VNDK-SP-Private e serão invisíveis para SP-HALS.

A seguir estão as bibliotecas somente de estrutura com exceções RS (FWK-ONLY-RS) :

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

versionamento do VNDK

As bibliotecas compartilhadas 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 ao current , use BOARD_VNDK_VERSION .
• Se BOARD_VNDK_VERSION for igual ao current :
• Se PLATFORM_VERSION_CODENAME for REL , use PLATFORM_SDK_VERSION (por exemplo, 28 ).
• Caso contrário, use PLATFORM_VERSION_CODENAME (por exemplo, P ).

Conjunto de teste do fornecedor (VTS)

O Android Vendor Test Suite (VTS) exige uma propriedade ro.vndk.version não vazia. Os dispositivos recém-lançados e os dispositivos atualizados devem definir ro.vndk.version . Alguns casos de teste VNDK (por exemplo VtsVndkFilesTest e VtsVndkDependencyTest ) contam com a propriedade ro.vndk.version para carregar os conjuntos de dados de bibliotecas VNDK elegíveis correspondentes.

,

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 de estrutura nas quais 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.

Atualizações somente de 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 na partição do fornecedor e 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 interromper a implementação HIDL de um fornecedor. Para obter diretrizes sobre como evitar essas interrupções, consulte Extensões do VNDK .

Para enfrentar esses desafios, o Android contém vários recursos, como VNDK (descrito nesta seção), HIDL , hwbinder, sobreposição de árvore de dispositivos e sobreposição de política de segurança.

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 de tempo de construção.
• Processos são tarefas do sistema operacional geradas a partir de executáveis. Os processos criam dependências de tempo de execução.
• Os termos qualificados pela estrutura estão relacionados à partição system :
• Executáveis ​​de estrutura referem-se a executáveis ​​em /system/bin ou /system/xbin .
• Bibliotecas compartilhadas de estrutura referem-se a bibliotecas compartilhadas em /system/lib[64] .
• 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 vendor :
• Os executáveis ​​do fornecedor referem-se aos executáveis ​​em /vendor/bin
• As bibliotecas compartilhadas do fornecedor referem-se às bibliotecas compartilhadas em /vendor/lib[64] .
• Módulos de fornecedores referem-se a executáveis ​​de fornecedores e bibliotecas compartilhadas de fornecedores.
• Os processos do fornecedor são processos gerados a partir dos executáveis ​​do fornecedor, como /vendor/bin/android.hardware.camera.provider@2.4-service .

Conceitos de VNDK

Em um mundo Android 8.0 e 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 regidos por HIDL e hardware encadernador.

Esse mundo inclui a possibilidade de que APIs públicas e estáveis ​​de bibliotecas compartilhadas de estrutura possam não ser suficientes para desenvolvedores de módulos de fornecedores (embora as APIs possam mudar entre as versões do Android), exigindo que alguma parte das bibliotecas compartilhadas de estrutura seja acessível a processos de fornecedores. Além disso, como os requisitos de desempenho podem levar a concessões, 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 HALs de mesmo processo (SP-HALs).

Bibliotecas compartilhadas da estrutura para o 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 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 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 da estrutura antiga . Vem com 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 limitado a) fichário, 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 através do 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 da 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.
  • 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 ,
• Bibliotecas VNDK qualificadas (VNDK) são bibliotecas compartilhadas de estrutura seguras para serem copiadas duas vezes. Módulos de estrutura e módulos de fornecedores podem ser vinculados 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 o framework.
  • 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 exija revisões legais.
  • O proprietário do código não tem objeções aos usos do fornecedor.
• Bibliotecas somente de estrutura (FWK-ONLY) são bibliotecas compartilhadas de estrutura que não pertencem às categorias mencionadas acima. Estas bibliotecas:
  • São considerados detalhes de implementação interna do framework.
  • Não deve ser acessado por módulos do fornecedor.
  • Tenha ABIs/APIs instáveis ​​e nenhuma garantia de compatibilidade de API/ABI.
  • Não são copiados.

HAL de mesmo processo (SP-HAL)

HAL de mesmo processo ( SP-HAL ) é um conjunto de HALs predeterminados implementados como bibliotecas compartilhadas de fornecedores e carregados em processos de estrutura . 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-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. 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 de VNDK-SP-Private e serão invisíveis para SP-HALS.

A seguir estão as bibliotecas somente de estrutura com exceções RS (FWK-ONLY-RS) :

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

versionamento do VNDK

As bibliotecas compartilhadas 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 ao current , use BOARD_VNDK_VERSION .
• Se BOARD_VNDK_VERSION for igual ao current :
• Se PLATFORM_VERSION_CODENAME for REL , use PLATFORM_SDK_VERSION (por exemplo, 28 ).
• Caso contrário, use PLATFORM_VERSION_CODENAME (por exemplo, P ).

Conjunto de teste do fornecedor (VTS)

O Android Vendor Test Suite (VTS) exige uma propriedade ro.vndk.version não vazia. Os dispositivos recém-lançados e os dispositivos atualizados devem definir ro.vndk.version . Alguns casos de teste VNDK (por exemplo VtsVndkFilesTest e VtsVndkDependencyTest ) contam com a propriedade ro.vndk.version para carregar os conjuntos de dados de bibliotecas VNDK elegíveis correspondentes.

,

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 de estrutura nas quais 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.

Atualizações somente de 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 na partição do fornecedor e 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 interromper a implementação HIDL de um fornecedor. Para obter diretrizes sobre como evitar essas interrupções, consulte Extensões do VNDK .

Para enfrentar esses desafios, o Android contém vários recursos, como VNDK (descrito nesta seção), HIDL , hwbinder, sobreposição de árvore de dispositivos e sobreposição de política de segurança.

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 de tempo de compilação.
• Processos são tarefas do sistema operacional geradas a partir de executáveis. Os processos criam dependências de tempo de execução.
• Os termos qualificados pela estrutura estão relacionados à partição system :
• Executáveis ​​de estrutura referem-se a executáveis ​​em /system/bin ou /system/xbin .
• Bibliotecas compartilhadas de estrutura referem-se a bibliotecas compartilhadas em /system/lib[64] .
• 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 vendor :
• Os executáveis ​​do fornecedor referem-se aos executáveis ​​em /vendor/bin
• As bibliotecas compartilhadas do fornecedor referem-se às bibliotecas compartilhadas em /vendor/lib[64] .
• Módulos de fornecedores referem-se a executáveis ​​de fornecedores e bibliotecas compartilhadas de fornecedores.
• Os processos do fornecedor são processos gerados a partir dos executáveis ​​do fornecedor, como /vendor/bin/android.hardware.camera.provider@2.4-service .

Conceitos de VNDK

Em um mundo Android 8.0 e 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 regidos por HIDL e hardware encadernador.

Esse mundo inclui a possibilidade de que APIs públicas e estáveis ​​de bibliotecas compartilhadas de estrutura possam não ser suficientes para desenvolvedores de módulos de fornecedores (embora as APIs possam mudar entre as versões do Android), exigindo que alguma parte das bibliotecas compartilhadas de estrutura seja acessível a processos de fornecedores. Além disso, como os requisitos de desempenho podem levar a concessões, 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 HALs de mesmo processo (SP-HALs).

Bibliotecas compartilhadas da estrutura para o 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 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 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 da estrutura antiga . Vem com 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 limitado a) fichário, 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 através do 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 da 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.
  • 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 ,
• Bibliotecas VNDK qualificadas (VNDK) são bibliotecas compartilhadas de estrutura seguras para serem copiadas duas vezes. Módulos de estrutura e módulos de fornecedores podem ser vinculados 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 o framework.
  • 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 exija revisões legais.
  • O proprietário do código não tem objeções aos usos do fornecedor.
• Bibliotecas somente de estrutura (FWK-ONLY) são bibliotecas compartilhadas de estrutura que não pertencem às categorias mencionadas acima. Estas bibliotecas:
  • São considerados detalhes de implementação interna do framework.
  • Não deve ser acessado por módulos do fornecedor.
  • Tenha ABIs/APIs instáveis ​​e nenhuma garantia de compatibilidade de API/ABI.
  • Não são copiados.

HAL de mesmo processo (SP-HAL)

HAL de mesmo processo ( SP-HAL ) é um conjunto de HALs predeterminados implementados como bibliotecas compartilhadas de fornecedores e carregados em processos de estrutura . 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-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. 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 de VNDK-SP-Private e serão invisíveis para SP-HALS.

A seguir estão as bibliotecas somente de estrutura com exceções RS (FWK-ONLY-RS) :

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

versionamento do VNDK

As bibliotecas compartilhadas 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 ao current , use BOARD_VNDK_VERSION .
• Se BOARD_VNDK_VERSION for igual ao current :
• Se PLATFORM_VERSION_CODENAME for REL , use PLATFORM_SDK_VERSION (por exemplo, 28 ).
• Caso contrário, use PLATFORM_VERSION_CODENAME (por exemplo, P ).

Conjunto de teste do fornecedor (VTS)

O Android Vendor Test Suite (VTS) exige uma propriedade ro.vndk.version não vazia. Os dispositivos recém-lançados e os dispositivos atualizados devem definir ro.vndk.version . Alguns casos de teste VNDK (por exemplo VtsVndkFilesTest e VtsVndkDependencyTest ) contam com a propriedade ro.vndk.version para carregar os conjuntos de dados de bibliotecas VNDK elegíveis correspondentes.

,

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 de estrutura nas quais 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.

Atualizações somente de 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 na partição do fornecedor e 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 interromper a implementação HIDL de um fornecedor. Para obter diretrizes sobre como evitar essas interrupções, consulte Extensões do VNDK .

Para enfrentar esses desafios, o Android contém vários recursos, como VNDK (descrito nesta seção), HIDL , hwbinder, sobreposição de árvore de dispositivos e sobreposição de política de segurança.

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 de tempo de construção.
• Processos são tarefas do sistema operacional geradas a partir de executáveis. Os processos criam dependências de tempo de execução.
• Os termos qualificados pela estrutura estão relacionados à partição system :
• Executáveis ​​de estrutura referem-se a executáveis ​​em /system/bin ou /system/xbin .
• Bibliotecas compartilhadas de estrutura referem-se a bibliotecas compartilhadas em /system/lib[64] .
• 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 vendor :
• Os executáveis ​​do fornecedor referem-se aos executáveis ​​em /vendor/bin
• As bibliotecas compartilhadas do fornecedor referem-se às bibliotecas compartilhadas em /vendor/lib[64] .
• Módulos de fornecedores referem-se a executáveis ​​de fornecedores e bibliotecas compartilhadas de fornecedores.
• Os processos do fornecedor são processos gerados a partir dos executáveis ​​do fornecedor, como /vendor/bin/android.hardware.camera.provider@2.4-service .

Conceitos de VNDK

Em um mundo Android 8.0 e 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 regidos por HIDL e hardware encadernador.

Esse mundo inclui a possibilidade de que APIs públicas e estáveis ​​de bibliotecas compartilhadas de estrutura possam não ser suficientes para desenvolvedores de módulos de fornecedores (embora as APIs possam mudar entre as versões do Android), exigindo que alguma parte das bibliotecas compartilhadas de estrutura seja acessível a processos de fornecedores. Além disso, como os requisitos de desempenho podem levar a concessões, 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 HALs de mesmo processo (SP-HALs).

Bibliotecas compartilhadas da estrutura para o 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 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 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 da estrutura antiga . Vem com 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 limitado a) fichário, 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 através do 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 da 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.
  • 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 ,
• Bibliotecas VNDK qualificadas (VNDK) são bibliotecas compartilhadas de estrutura seguras para serem copiadas duas vezes. Módulos de estrutura e módulos de fornecedores podem ser vinculados com suas próprias cópias. A framework shared library can become an eligible VNDK library only if it satisfies the following criteria:
  • It does not send/receive IPCs to/from the framework.
  • It is not related to ART virtual machine.
  • It does not read/write files/partitions with unstable file formats.
  • It does not have special software license which requires legal reviews.
  • Its code owner does not have objections to vendor usages.
• Framework-Only Libraries (FWK-ONLY) are Framework Shared Libraries that do not belong to the categories mentioned above. These libraries:
  • Are considered framework internal implementation details.
  • Must not be accessed by vendor modules.
  • Have unstable ABIs/APIs and no API/ABI compatibility guarantees.
  • Are not copied.

Same-Process HAL (SP-HAL)

Same-Process HAL ( SP-HAL ) is a set of predetermined HALs implemented as Vendor Shared Libraries and loaded into Framework Processes . SP-HALs are isolated by a linker namespace (controls the libraries and symbols that are visible to the shared libraries). SP-HALs must depend only on LL-NDK and VNDK-SP .

VNDK-SP is a predefined subset of eligible VNDK libraries. VNDK-SP libraries are carefully reviewed to ensure double-loading VNDK-SP libraries into framework processes does not cause problems. Both SP-HALs and VNDK-SPs are defined by Google.

The following libraries are approved SP-HALs:

• 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

VNDK-SP libraries specify vndk: { support_system_process: true } in their Android.bp files. If vndk: {private:true} is also specified, then these libraries are called VNDK-SP-Private and they are invisible to SP-HALS.

The following are framework-only libraries with RS exceptions (FWK-ONLY-RS) :

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

VNDK versioning

VNDK shared libraries are versioned:

• The ro.vndk.version system property is automatically added to /vendor/default.prop .
• VNDK and VNDK-SP shared libraries are installed as a VNDK apex com.android.vndk.v${ro.vndk.version} and mounted to /apex/com.android.vndk.v${ro.vndk.version} .

The value of ro.vndk.version is chosen by the algorithm below:

• If BOARD_VNDK_VERSION is not equal to current , use BOARD_VNDK_VERSION .
• If BOARD_VNDK_VERSION is equal to current :
• If PLATFORM_VERSION_CODENAME is REL , use PLATFORM_SDK_VERSION (eg 28 ).
• Otherwise, use PLATFORM_VERSION_CODENAME (eg P ).

Vendor Test Suite (VTS)

The Android Vendor Test Suite (VTS) mandates a non-empty ro.vndk.version property. Both newly-launched devices and upgrading devices must define ro.vndk.version . Some VNDK test cases (eg VtsVndkFilesTest and VtsVndkDependencyTest ) rely on the ro.vndk.version property to load the matching eligible VNDK libraries data sets.