Extensões do VNDK

Os fabricantes de dispositivos Android mudam o código-fonte das bibliotecas do AOSP por vários motivos. Alguns fornecedores reimplementam funções nas bibliotecas do AOSP para melhorar a performance, enquanto outros fornecedores adicionam novos hooks, novas APIs ou novas funcionalidades às bibliotecas do AOSP. Esta seção fornece diretrizes para ampliar as bibliotecas do AOSP de uma maneira que não quebre o CTS/VTS.

Substituição

Todas as bibliotecas compartilhadas modificadas precisam ser compatíveis com o binário, substituições de substituição da contraparte do AOSP. Todos os usuários do AOSP precisam poder usar a biblioteca compartilhada modificada sem recompilações. Esse requisito implica o seguinte:

  • As funções do AOSP não podem ser removidas.
  • As estruturas não podem ser alteradas se estiverem expostas aos usuários.
  • A pré-condição das funções não pode ser reforçada.
  • As funções precisam oferecer funcionalidades equivalentes.
  • A condição pós-regra das funções não pode ser enfraquecida.

Classificações de módulos estendidas

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

Observação: o termo funcionalidades é usado aqui em vez de API/ABI porque é possível adicionar funcionalidades sem mudar nenhuma API/ABI.

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

  • Os módulos de definição exclusiva do AOSP (DA-Module) não definem novas funcionalidades que não estavam na contraparte do AOSP.
    • Exemplo 1. Uma biblioteca AOSP intacta não modificada é um módulo DA.
    • Exemplo 2. Se um fornecedor reescrever as funções em libcrypto.so com instruções SIMD (sem adicionar novas funções), o libcrypto.so modificado será um módulo DA.
  • Os módulos de definição de extensão (DX-Module) definem novas funcionalidades ou não têm uma contraparte do AOSP.
    • Exemplo 1. Se um fornecedor adicionar uma função auxiliar a libjpeg.so para acessar alguns dados internos, o libjpeg.so modificado 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 que não seja do AOSP com o nome libfoo.so, libfoo.so será uma DX-Lib.

Dependendo das funcionalidades usadas por um módulo, eles podem ser classificados em módulo de UA e módulo de UX.

  • O Uso-somente-módulos-AOSP (UA-Module) usa apenas as funcionalidades do AOSP nas implementações. Eles não dependem de extensões que não são do AOSP.
    • Exemplo 1. Uma biblioteca AOSP intacta e não modificada é um módulo UA.
    • Exemplo 2. Se uma biblioteca compartilhada modificada libjpeg.so depender apenas de outras APIs do AOSP, ela será um UA-Module.
  • Os módulos de uso de extensões (UX-Module) dependem de algumas funcionalidades que não são do AOSP nas implementações.
    • Exemplo 1. Se um libjpeg.so modificado depender de outra biblioteca que não seja do AOSP chamada libjpeg_turbo2.so, o libjpeg.so modificado será um módulo de UX.
    • Exemplo 2. Se um fornecedor adicionar uma nova função ao libexif.so modificado e o libjpeg.so modificado usar a função recém-adicionada de libexif.so, o libjpeg.so modificado será um módulo de UX.

As definições e os usos são independentes:

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

Mecanismo de extensão do VNDK

Módulos do fornecedor que dependem de funcionalidades estendidas não funcionam porque a biblioteca AOSP com o mesmo nome não tem a funcionalidade estendida. Se os módulos do fornecedor dependerem diretamente ou indiretamente de funcionalidades estendidas, os fornecedores vão precisar 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 podem ser copiadas. Portanto, os módulos do fornecedor não podem depender das funcionalidades estendidas definidas pelas bibliotecas modificadas do LL-NDK.

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 de drop-in é importante porque as bibliotecas VNDK não modificadas na GSI vão ser vinculadas às bibliotecas compartilhadas modificadas em caso de colisão de nome. Se as bibliotecas do AOSP forem modificadas de maneira incompatível com a API/ABI, as bibliotecas do AOSP no GSI poderão não ser vinculadas ou resultar em comportamentos indefinidos.