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 interna da API e resolver situações em que os aplicativos usam acidentalmente bibliotecas de plataforma em vez das suas próprias. Consulte a postagem do blog Melhorando a estabilidade com restrições de símbolos C/C++ privados no Android 7.0 Android Developers para obter alterações específicas do aplicativo.

Arquitetura

No Android 7.0 e versões posteriores, as bibliotecas do sistema são separadas das bibliotecas de aplicativos.

Figura 1. Namespaces para bibliotecas nativas

Namespaces para bibliotecas nativas evitam que aplicativos usem APIs nativas de plataforma privada (como foi feito com OpenSSL). Ele também remove situações em que os aplicativos usam acidentalmente bibliotecas de plataforma em vez das suas próprias (como testemunhado com libpng ). É difícil para as bibliotecas de aplicativos usarem bibliotecas internas do sistema por acidente (e vice-versa).

Adicionando bibliotecas nativas adicionais

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-as nas respectivas pastas da biblioteca e listando-as explicitamente em .txt arquivos.

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, onde COMPANYNAME se refere ao nome do fabricante (como awesome.company ). COMPANYNAME deve 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 provedores de soluções externos.

As bibliotecas nativas na partição do system que são tornadas públicas pelos fabricantes de dispositivos DEVEM 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 DEVE ser tornado público. O COMPANYNAME no nome do arquivo da biblioteca DEVE corresponder ao COMPANYNAME no nome do arquivo txt no qual o nome da biblioteca está listado.

Bibliotecas nativas que fazem parte do AOSP NÃO DEVEM 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 disponibilizadas para aplicativos.

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

A biblioteca nativa do fornecedor deve ser devidamente rotulada para que possa ser acessível aos aplicativos. Se o acesso for exigido por qualquer aplicativo (incluindo aplicativos de terceiros), a biblioteca deverá ser rotulada como same_process_hal_file em um arquivo file_contexts específico do fornecedor, como segue:
```
/vendor/lib(64)?/libnative.so u:object_r:same_process_hal_file:s0
```
onde libnative.so é o nome da biblioteca nativa.
A biblioteca, direta ou transitivamente por meio de suas dependências, não deve depender de bibliotecas do sistema que não sejam 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 .

A partir do Android 15 (AOSP experimental), as bibliotecas públicas do fornecedor podem ser colocadas em um APEX do fornecedor . Quando empacotado em um APEX de fornecedor, liste as bibliotecas em uma propriedade provideNativeLibs no manifesto do APEX.

Atualizando aplicativos para não usarem bibliotecas nativas não públicas

Este recurso está habilitado apenas para aplicativos direcionados ao SDK versão 24 ou posterior; para compatibilidade com versões anteriores, consulte Tabela 1. O que esperar se seu aplicativo estiver vinculado a bibliotecas nativas privadas . A lista de bibliotecas nativas do Android acessíveis aos aplicativos (também conhecidas como bibliotecas nativas públicas) está listada na seção 3.1.1 do CDD. Os aplicativos destinados à versão 24 ou posterior e que usam bibliotecas não públicas devem ser atualizados. Consulte Aplicativos NDK vinculados a bibliotecas de plataforma para obter mais detalhes.

Atualizando aplicativos para suas dependências de biblioteca nativa

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