Namespaces para bibliotecas nativas

O Android 7.0 introduziu namespaces para bibliotecas nativas para limitar a API interna visibilidade e resolver situações em que os aplicativos acidentalmente usam a plataforma em vez de criar bibliotecas próprias. Consulte a página Estabilidade com restrições de símbolo C/C++ particular no Android 7.0 Postagem no blog para desenvolvedores sobre mudanças específicas no app.

Arquitetura

No Android 7.0 e versões mais recentes, as bibliotecas do sistema são separadas das bibliotecas de apps.

Namespaces para bibliotecas nativas

Figura 1. Namespaces para bibliotecas nativas.

os namespaces para bibliotecas nativas impedem que os apps usem o nativo de plataforma privada APIs (da mesma forma que o OpenSSL). Ele também remove situações em que os apps acidentalmente usar bibliotecas de plataforma ao invés de suas próprias (como testemunhado com libpng). É difícil que as bibliotecas de apps usem recursos bibliotecas do sistema por acidente (e vice-versa).

Adicionar outras bibliotecas nativas

Além das bibliotecas nativas públicas padrão, os fornecedores de silício (a partir do Android 7.0) e os fabricantes de dispositivos (a partir do Android 9) podem optar por fornecer bibliotecas nativas adicionais acessíveis aos aplicativos, colocando-os nas respectivas pastas da biblioteca e os listando explicitamente em arquivos .txt.

As pastas da biblioteca são:

  • /vendor/lib (para 32 bits) e /vendor/lib64 (para 64 bits) para bibliotecas de fornecedores de componentes eletrônicos
  • /system/lib (para 32 bits) e /system/lib64 (para 64 bits) para bibliotecas de fabricantes de dispositivos

Os arquivos .txt são:

  • /vendor/etc/public.libraries.txt para bibliotecas de fornecedores de componentes eletrônicos
  • /system/etc/public.libraries-COMPANYNAME.txt para bibliotecas de fabricantes de dispositivos; em que COMPANYNAME se refere ao nome do fabricante (como awesome.company). COMPANYNAME precisa corresponder a [A-Za-z0-9_.-]+ caracteres alfanuméricos, _, . (ponto) e -. É possível Ter vários desses arquivos .txt em um dispositivo se algumas bibliotecas forem de uma solução externa provedores de rede.

Bibliotecas nativas na partição system que são públicas pelos fabricantes de dispositivos PRECISA ter o nome lib*COMPANYNAME.so. Por exemplo, libFoo.awesome.company.so. Em outras palavras, libFoo.so sem o sufixo do nome da empresa NÃO PODE ser definido como público. O COMPANYNAME no nome do arquivo da biblioteca PRECISA corresponder ao COMPANYNAME no txt no qual o nome da biblioteca está listado.

Bibliotecas nativas que fazem parte do AOSP NÃO PODEM ser tornadas públicas (exceto a bibliotecas nativas públicas, que são públicas por padrão). Apenas as bibliotecas adicionais adicionadas pelo fornecedores de silício ou fabricantes de dispositivos podem ser acessíveis aos aplicativos.

A partir do Android 8.0, as bibliotecas públicas de fornecedores têm os seguintes recursos adicionais: restrições e configurações necessárias:

  1. A biblioteca nativa no fornecedor deve ser devidamente rotulada para que possa ser acessíveis para aplicativos. Se o acesso for exigido por apps (incluindo terceiros de terceiros), a biblioteca precisa ser marcada como same_process_hal_file. em um arquivo file_contexts específico do fornecedor desta forma:
    /vendor/lib(64)?/libnative.so u:object_r:same_process_hal_file:s0
    em que libnative.so é o nome da biblioteca nativa.
  2. A biblioteca, direta ou transitivamente por meio das dependências, não pode dependem de bibliotecas do sistema diferentes das bibliotecas VNDK-SP e LLNDK. Localize a lista de Bibliotecas VNDK-SP e LLNDK em development/vndk/tools/definition/tool/datasets/eligible-list-<version>-release.csv:

No Android 15 e versões mais recentes, as bibliotecas públicas dos fornecedores podem ser colocadas em um APEX do fornecedor. Quando empacotado em um APEX de fornecedor, liste as bibliotecas em uma propriedade provideNativeLibs no manifesto APEX.

Atualizar apps para não usar bibliotecas nativas que não são públicas

Esse recurso está ativado somente para apps destinados à versão 24 ou mais recente do SDK. para compatibilidade com versões anteriores, consulte a Tabela 1:o que esperar se o app estiver vinculado a bibliotecas nativas privadas. A lista de bibliotecas nativas do Android acessíveis aos apps (também conhecidas como bibliotecas nativas públicas) está listado na seção 3.1.1 do CDD. Apps destinados a 24 ou e o uso de bibliotecas não públicas precisam ser atualizados. Consulte NDK Apps vinculados a bibliotecas de plataforma para mais detalhes.

Atualizar apps para as dependências da biblioteca nativa

Os apps direcionados à versão 31 (Android 12) ou mais recente do SDK precisam especificar explicitamente as dependências da biblioteca compartilhada nativa usando o tag <uses-native-library> no manifesto do app. Se alguma parte dos recursos não existir no dispositivo, o app não está instalado. Quando os aplicativos são instalados, fornecidos apenas com as bibliotecas compartilhadas nativas solicitadas. Isso significa que Os apps não podem acessar bibliotecas compartilhadas nativas que não aparecem no manifesto do app.