Extensões VNDK

Os fabricantes de dispositivos Android alteram o código-fonte das bibliotecas AOSP por vários motivos. Alguns fornecedores reimplementam funções nas bibliotecas AOSP para aumentar o desempenho, enquanto outros adicionam novos ganchos, novas APIs ou novas funcionalidades às bibliotecas AOSP. Esta seção fornece diretrizes para estender as bibliotecas AOSP de uma forma que não quebre o CTS/VTS.

Substituição de encaixe

Todas as bibliotecas compartilhadas modificadas devem ser compatíveis com binários , substituições imediatas de sua contraparte AOSP. Todos os usuários AOSP existentes devem poder usar a biblioteca compartilhada modificada sem recompilações. Este requisito implica o seguinte:

  • As funções AOSP não devem ser removidas.
  • As estruturas não devem ser alteradas se tais estruturas forem expostas aos seus usuários.
  • A pré-condição das funções não deve ser reforçada.
  • As funções devem fornecer funcionalidades equivalentes.
  • A pós-condição das funções não deve ser enfraquecida.

Classificações de módulo estendidas

Classifique os módulos pelas funcionalidades que eles definem e usam .

Nota : Funcionalidades são usadas aqui em vez de API/ABI porque é possível adicionar funcionalidade sem alterar nenhuma API/ABI.

Dependendo das funcionalidades definidas em um módulo, os módulos podem ser classificados em DA-Module e DX-Module :

  • Módulos Definindo somente AOSP (DA-Module) não definem novas funcionalidades que não estavam na contraparte AOSP.
    • Exemplo 1. Uma biblioteca AOSP não modificada intacta é um DA-Module.
    • Exemplo 2. Se um fornecedor reescrever as funções em libcrypto.so com instruções SIMD (sem adicionar novas funções), então o libcrypto.so modificado será um módulo DA.
  • Módulos de extensão de definição (DX-Module) definem novas funcionalidades ou não têm uma contraparte AOSP.
    • Exemplo 1. Se um fornecedor adiciona uma função auxiliar a libjpeg.so para acessar alguns dados internos, então a libjpeg.so modificada será uma DX-Lib e a função recém-adicionada será a parte estendida da biblioteca.
    • Exemplo 2. Se um fornecedor definir uma biblioteca não AOSP chamada libfoo.so , então libfoo.so será uma DX-Lib.

Dependendo das funcionalidades usadas por um módulo, os módulos podem ser classificados em UA-Module e UX-Module .

  • Módulos Using-only-AOSP (UA-Module) usam apenas funcionalidades AOSP em suas implementações. Eles não dependem de nenhuma extensão não AOSP.
    • Exemplo 1. Uma biblioteca AOSP não modificada intacta é um UA-Module.
    • Exemplo 2. Se uma biblioteca compartilhada modificada libjpeg.so apenas de outras APIs AOSP, ela será um módulo UA.
  • Os Módulos de Extensão (UX-Module) contam com algumas funcionalidades não AOSP em suas implementações.
    • Exemplo 1. Se um libjpeg.so modificado depende de outra biblioteca não AOSP chamada libjpeg_turbo2.so , então o libjpeg.so modificado será um UX-Module.
    • Exemplo 2. Se um fornecedor adiciona uma nova função ao seu libexif.so modificado e seu libjpeg.so modificado usa a função recém-adicionada de libexif.so , então seu libjpeg.so modificado será um UX-Module.

Definições e usos são independentes um do outro:

Funcionalidades usadas
Apenas AOSP (UA) Estendido (UX)
Funcionalidades definidas Apenas AOSP (DA) DAUA DAUX
Estendido (DX) DXUA DXUX

Mecanismo de extensão VNDK

Os módulos do fornecedor que dependem de funcionalidades estendidas não funcionarão porque a biblioteca AOSP com o mesmo nome não possui a funcionalidade estendida. Se os módulos do fornecedor dependerem direta ou indiretamente de funcionalidades estendidas, os fornecedores devem copiar as bibliotecas compartilhadas DAUX, DXUA e DXUX para a partição do fornecedor (os processos do fornecedor sempre procuram primeiro as bibliotecas compartilhadas na partição do fornecedor). No entanto, as bibliotecas LL-NDK não devem ser copiadas, portanto, os módulos do fornecedor não devem depender das funcionalidades estendidas definidas pelas bibliotecas LL-NDK modificadas.

As bibliotecas compartilhadas DAUA podem permanecer na partição do sistema se a biblioteca AOSP correspondente puder fornecer a mesma funcionalidade e os módulos do fornecedor continuarem funcionando quando a partição do sistema for substituída por uma imagem genérica do sistema (GSI).

A substituição drop-in é importante porque as bibliotecas VNDK não modificadas no GSI serão vinculadas às bibliotecas compartilhadas modificadas na colisão de nomes. Se as bibliotecas AOSP forem modificadas de maneira incompatível com API/ABI, as bibliotecas AOSP no GSI poderão falhar ao vincular ou resultar em comportamentos indefinidos.