Namespaces para bibliotecas nativas

O Android 7.0 introduziu namespaces para bibliotecas nativas para limitar a visibilidade da API interna e resolver situações em que os apps usam bibliotecas de plataforma por engano em vez das próprias. Consulte a postagem do blog Android Developers sobre como melhorar a estabilidade com restrições de símbolos C/C++ privados no Android 7.0 para conferir 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 era feito com o OpenSSL). Ele também remove situações em que os apps usam bibliotecas de plataforma por engano em vez das próprias (como testemunhado com libpng). É difícil para as bibliotecas de apps usar bibliotecas internas do sistema por engano (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 optar por fornecer outras bibliotecas nativas acessíveis aos apps, colocando-as nas pastas de biblioteca respectivas e listando-as explicitamente em arquivos .txt.

As pastas de 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 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 nomeadas como 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 disponibilizado. O COMPANYNAME no nome do arquivo de 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 PODEM ser disponibilizadas (exceto as bibliotecas nativas públicas padrão , que são públicas por padrão). Somente as bibliotecas adicionais adicionadas por fornecedores de componentes eletrônicos ou fabricantes de dispositivos podem ser disponibilizadas para apps.

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

  1. A biblioteca nativa no fornecedor precisa ser rotulada corretamente para que possa ser acessada pelos 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, direta ou transitivamente 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 privadas. A lista de bibliotecas nativas do Android acessíveis a apps (também conhecidas como bibliotecas nativas públicas) está listada na seção 3.1.1 do CDD. Os apps direcionados à versão 24 ou mais recente e que usam bibliotecas não públicas precisam ser atualizados. Consulte NDK Vinculação de apps às bibliotecas de plataforma para mais detalhes.

Atualizar apps para as dependências de biblioteca nativa

Os apps direcionados ao SDK versão 31 (Android 12) ou mais recente precisam especificar explicitamente as dependências de biblioteca compartilhada nativa usando a <uses-native-library> tag 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.