Extensões VNDK

Os fabricantes de dispositivos Android mudam o código-fonte das bibliotecas do AOSP para por vários motivos. Alguns fornecedores reimplementam funções em bibliotecas do AOSP para melhorar o desempenho enquanto outros fornecedores adicionam novos ganchos, novas APIs ou novas para bibliotecas do AOSP. Esta seção fornece diretrizes para estender bibliotecas AOSP de forma que não corrompa o CTS/VTS.

Substituição com atendimento presencial

Todas as bibliotecas compartilhadas modificadas precisam ser compatíveis com binário (link em inglês), substituições imediatas do correspondente do AOSP. Todas as existentes Os usuários do AOSP precisam conseguir 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 devem ser alteradas se estiverem expostas ao usuários.
• A pré-condição das funções não pode ser fortalecida.
• As funções precisam fornecer funcionalidades equivalentes.
• A pós-condição das funções não pode ser enfraquecida.

Classificações de módulos estendidos

classificar módulos pelas funcionalidades que eles definem e uso.

Observação: as funcionalidades são usadas aqui. em vez de API/ABI porque é possível adicionar funcionalidades sem mudar qualquer API/ABI.

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

• Como definir módulos AOSP somente (DA-Module) não definem novos e funcionalidades que não estavam na versão correspondente do AOSP.
  • Exemplo 1. Uma biblioteca AOSP inalterada e intacta é uma módulo DA.
  • Exemplo 2. Se um fornecedor reescrever as funções libcrypto.so com instruções de chip (sem adicionar um novo) ), o libcrypto.so modificado será um módulo DA.
• Defining-Extension Modules (DX-Module): define novos ou não têm uma contraparte do AOSP.
  • Exemplo 1. Se um fornecedor adicionar uma função auxiliar libjpeg.so para acessar alguns dados internos, depois o arquivo libjpeg.so será um DX-Lib e a função recém-adicionada será a porção estendida da biblioteca.
  • Exemplo 2. Se um fornecedor definir uma biblioteca não AOSP chamada libfoo.so, então libfoo.so será um DX-Lib.

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

• Os módulos do AOSP (UA-Module) só usam funcionalidades do AOSP. nas implementações. Elas não dependem de extensões que não sejam do AOSP.
  • Exemplo 1. Uma biblioteca AOSP inalterada e intacta é uma módulo do UA.
  • Exemplo 2. Se uma biblioteca compartilhada modificada libjpeg.so depender de outras APIs do AOSP, ele será um módulo do UA.
• Usar módulos de extensão (módulo de UX) depende de alguns modelos que não são do AOSP. e funcionalidades nas implementações.
  • Exemplo 1. Se um libjpeg.so modificado depender de outra biblioteca não AOSP chamada libjpeg_turbo2.so, o modificado libjpeg.so será um módulo de UX.
  • Exemplo 2. Se um fornecedor adicionar uma nova função aos libexif.so e o libjpeg.so modificado deles usam o função recém-adicionada de libexif.so, e a respectiva função libjpeg.so será um módulo de UX.

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

Mecanismo de extensão do VNDK

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

As bibliotecas compartilhadas do DAUA podem permanecer na partição do sistema a biblioteca AOSP correspondente pode oferecer a mesma funcionalidade e fornecedor continuam funcionando quando a partição do sistema é substituída por uma Imagem do sistema (GSI).

A substituição simples é importante porque as bibliotecas VNDK não modificadas são a GSI vai criar um link para as bibliotecas compartilhadas modificadas quando houver um conflito de nomes. Se o As bibliotecas do AOSP são modificadas de forma incompatível com a API/ABI, as bibliotecas do AOSP as bibliotecas na GSI podem não vincular ou resultar em comportamentos indefinidos.