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:

Funcionalidades usadas
Somente AOSP (UA) Estendido (UX)
Funcionalidades definidas Somente 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 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.