Namespaces para bibliotecas nativas

O Android 7.0 introduziu namespaces para bibliotecas nativas com o objetivo de limitar a visibilidade da API interna e resolver situações em que os apps usam acidentalmente bibliotecas da plataforma em vez das próprias. Consulte a postagem do blog Como melhorar a estabilidade com restrições de símbolo C/C++ privado no Android 7.0 (link em inglês) para desenvolvedores Android e confira as mudanças específicas do 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 APIs nativas de plataforma privada (como foi feito com o OpenSSL). Também evita situações em que os apps usam acidentalmente bibliotecas da plataforma em vez das próprias (como visto com libpng). É difícil para as bibliotecas de apps usar bibliotecas internas do sistema por acidente (e vice-versa).

Adicionar outras bibliotecas nativas

Além das bibliotecas nativas públicas padrão, os fornecedores de componentes eletrônicos (a partir do Android 7.0) e os fabricantes de dispositivos (a partir do Android 9) podem fornecer bibliotecas nativas adicionais acessíveis aos apps. Para isso, basta colocá-las nas pastas de biblioteca respectivas e listá-las 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 silício
  • /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 silício
  • /system/etc/public.libraries-COMPANYNAME.txt para bibliotecas de fabricantes de dispositivos, em que COMPANYNAME se refere a um nome do fabricante (como awesome.company). COMPANYNAME precisa corresponder a [A-Za-z0-9_.-]+; caracteres alfanuméricos, _, . (ponto) e -. É possível ter vários arquivos .txt em um dispositivo se algumas bibliotecas forem de provedores de soluções externas.

As bibliotecas nativas na partição system que são disponibilizadas pelos fabricantes de dispositivos PRECISAM ser chamadas de 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 divulgado. O COMPANYNAME no nome do arquivo da biblioteca PRECISA corresponder ao COMPANYNAME no nome do arquivo txt em que o nome da biblioteca está listado.

As bibliotecas nativas que fazem parte do AOSP NÃO DEVEM ser disponibilizadas publicamente, exceto as bibliotecas nativas públicas padrão, que são públicas por padrão. Somente as bibliotecas adicionais incluídas por fornecedores de componentes eletrônicos ou fabricantes de dispositivos podem ser acessadas pelos apps.

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

  1. A biblioteca nativa no fornecedor precisa ser rotulada corretamente para que possa ser acessível aos apps. Se o acesso for necessário para qualquer app (incluindo apps de terceiros), a biblioteca precisará ser rotulada como same_process_hal_file em um arquivo file_contexts específico do fornecedor da seguinte maneira: 
    /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, seja diretamente ou de forma transitiva pelas dependências, não pode depender de bibliotecas do sistema que não sejam 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.

A partir do Android 15, as bibliotecas públicas do fornecedor podem ser colocadas em um APEX do fornecedor. Quando empacotadas em um APEX do fornecedor, liste as bibliotecas em uma propriedade provideNativeLibs no manifesto do APEX.

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

Esse recurso está ativado apenas para apps direcionados ao SDK versão 24 ou mais recente. Para compatibilidade com versões anteriores, consulte a Tabela 1. O que esperar se o app estiver vinculado a bibliotecas nativas particulares. A lista de bibliotecas nativas do Android acessíveis a apps (também conhecidas como bibliotecas nativas públicas) está na seção 3.1.1 do CDD. Os apps destinados ao Android 7.0 (nível 24) ou mais recente que usam bibliotecas não públicas precisam ser atualizados. Consulte Vinculação de apps NDK a bibliotecas de plataforma para mais detalhes.

Atualizar apps para as dependências de biblioteca nativa

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