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 em bibliotecas AOSP para aumentar o desempenho, enquanto outros fornecedores 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 imediata

Todas as bibliotecas compartilhadas modificadas devem ser substituições imediatas e compatíveis com binário 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 estiverem expostas aos seus utilizadores.
• 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ódulos estendidos

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 Módulo DA e Módulo DX :

• A definição de módulos apenas AOSP (Módulo DA) não define novas funcionalidades que não estavam na contraparte AOSP.
  • Exemplo 1. Uma biblioteca AOSP intacta e 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), então o libcrypto.so modificado será um Módulo DA.
• Os Módulos de Extensão de Definição (Módulo DX) definem novas funcionalidades ou não possuem contraparte AOSP.
  • Exemplo 1. Se um fornecedor adicionar uma função auxiliar ao libjpeg.so para acessar alguns dados internos, então o libjpeg.so modificado será um 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 utilizadas por um módulo, os módulos podem ser classificados em UA-Module e UX-Module .

• Módulos usando apenas AOSP (Módulo UA) usam apenas funcionalidades AOSP em suas implementações. Eles não dependem de nenhuma extensão que não seja 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 AOSP, então será um Módulo UA.
• Módulos de extensão de uso (Módulo UX) 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 módulo UX.
  • Exemplo 2. Se um fornecedor adicionar uma nova função ao seu libexif.so modificado e seu libjpeg.so modificado usar a função recém-adicionada de libexif.so , então seu libjpeg.so modificado será um módulo UX.

Definições e usos são independentes entre si:

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 deverão 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 contar com as 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 a funcionar quando a partição do sistema for substituída por uma imagem genérica do sistema (GSI).

A substituição imediata é 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.