O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

Esta página foi traduzida pela API Cloud Translation.

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 acidentalmente bibliotecas de 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 (em inglês) para saber mais sobre as mudanças específicas do app.

Arquitetura

No Android 7.0 e mais recentes, as bibliotecas do sistema são separadas das bibliotecas do app.

Figura 1. Namespaces para bibliotecas nativas.

Os namespaces para bibliotecas nativas impedem que os apps usem APIs nativas de plataformas privadas (como foi feito com o OpenSSL). Ele também remove situações em que os apps usam acidentalmente bibliotecas da plataforma em vez das próprias (como observado com libpng). É difícil para bibliotecas de apps usarem 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 silício (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 respectivas pastas de biblioteca e listando-as 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 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ção externa.

As bibliotecas nativas na partição system que são publicadas pelos fabricantes de dispositivos PRECISAM ser nomeadas 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 PODEM ser tornadas públicas, exceto as bibliotecas nativas públicas padrão, que são públicas por padrão. Somente as bibliotecas adicionais adicionadas por fornecedores de silício ou fabricantes de dispositivos podem ser acessadas por apps.

No Android 8.0 e versões mais recentes, as bibliotecas públicas do fornecedor têm as restrições e configurações necessárias abaixo:

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 marcada 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.
A biblioteca, diretamente ou transitivamente pelas dependências, não pode depender de outras bibliotecas do sistema além das bibliotecas VNDK-SP e LLNDK. Localize a lista de bibliotecas do VNDK-SP e do 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 de 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 só é ativado para apps direcionados à 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 vinculando a bibliotecas nativas privadas. A lista de bibliotecas nativas do Android acessíveis aos apps, também conhecidas como bibliotecas nativas públicas, está na seção 3.1.1 do CDD. Os apps que segmentam 24 ou mais recentes e usam bibliotecas não públicas precisam ser atualizados. Consulte Vinculação de apps NDK às 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 de biblioteca compartilhada nativa usando a tag <uses-native-library> no manifesto do app. Se qualquer parte da biblioteca solicitada não existir no dispositivo, o app não estará instalado. Quando os apps são instalados, eles vão receber apenas 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.