Esta página se ha traducido con Cloud Translation API.

Espacios de nombres para bibliotecas nativas

Android 7.0 introdujo espacios de nombres para bibliotecas nativas para limitar la visibilidad de la API interna y resolver situaciones en las que las aplicaciones usan accidentalmente bibliotecas de plataforma en lugar de las suyas propias. Consulte la publicación del blog Mejora de la estabilidad con restricciones de símbolos privados de C/C++ en Android 7.0 para desarrolladores de Android para conocer los cambios específicos de la aplicación.

Arquitectura

En Android 7.0 y versiones posteriores, las bibliotecas del sistema están separadas de las bibliotecas de aplicaciones.

Figura 1. Espacios de nombres para bibliotecas nativas

Los espacios de nombres para bibliotecas nativas impiden que las aplicaciones utilicen API nativas de plataforma privada (como se hizo con OpenSSL). También elimina situaciones en las que las aplicaciones usan accidentalmente bibliotecas de plataforma en lugar de las suyas propias (como se vio con libpng ). Es difícil que las bibliotecas de aplicaciones utilicen bibliotecas internas del sistema por accidente (y viceversa).

Agregar bibliotecas nativas adicionales

Además de las bibliotecas nativas públicas estándar, los proveedores de silicio (a partir de Android 7.0) y los fabricantes de dispositivos (a partir de Android 9) pueden optar por proporcionar bibliotecas nativas adicionales accesibles para las aplicaciones colocándolas en las respectivas carpetas de bibliotecas y enumerándolas explícitamente en .txt. archivos.

Las carpetas de la biblioteca son:

/vendor/lib (para 32 bits) y /vendor/lib64 (para 64 bits) para bibliotecas de proveedores de silicio
/system/lib (para 32 bits) y /system/lib64 (para 64 bits) para bibliotecas de fabricantes de dispositivos

Los archivos .txt son:

/vendor/etc/public.libraries.txt para bibliotecas de proveedores de silicio
/system/etc/public.libraries-COMPANYNAME.txt para bibliotecas de fabricantes de dispositivos, donde COMPANYNAME se refiere al nombre del fabricante (como awesome.company ). COMPANYNAME debe coincidir con [A-Za-z0-9_.-]+ ; caracteres alfanuméricos, _, . (punto) y -. Es posible tener varios archivos .txt de este tipo en un dispositivo si algunas bibliotecas provienen de proveedores de soluciones externos.

Las bibliotecas nativas en la partición system que los fabricantes de dispositivos hacen públicas DEBEN llamarse lib*COMPANYNAME.so , por ejemplo, libFoo.awesome.company.so . En otras palabras, libFoo.so sin el sufijo del nombre de la empresa NO DEBE hacerse público. El COMPANYNAME en el nombre del archivo de la biblioteca DEBE coincidir con el NOMBRE COMPANYNAME en el nombre del archivo de texto en el que aparece el nombre de la biblioteca.

Las bibliotecas nativas que forman parte de AOSP NO DEBEN hacerse públicas (excepto las bibliotecas nativas públicas estándar que son públicas de forma predeterminada). Solo las bibliotecas adicionales agregadas por los proveedores de silicio o los fabricantes de dispositivos pueden ser accesibles para las aplicaciones.

A partir de Android 8.0, las bibliotecas públicas de proveedores tienen las siguientes restricciones adicionales y configuraciones requeridas:

La biblioteca nativa del proveedor debe estar etiquetada correctamente para que las aplicaciones puedan acceder a ella. Si alguna aplicación (incluidas aplicaciones de terceros) requiere acceso, la biblioteca debe etiquetarse como same_process_hal_file en un archivo file_contexts específico del proveedor de la siguiente manera:
```
/vendor/lib(64)?/libnative.so u:object_r:same_process_hal_file:s0
```
donde libnative.so es el nombre de la biblioteca nativa.
La biblioteca, ya sea directa o transitivamente a través de sus dependencias, no debe depender de bibliotecas del sistema distintas de las bibliotecas VNDK-SP y LLNDK. Ubique la lista de bibliotecas VNDK-SP y LLNDK en development/vndk/tools/definition/tool/datasets/eligible-list-<version>-release.csv .

A partir de Android 15 (AOSP experimental), las bibliotecas públicas del proveedor se pueden colocar en un APEX del proveedor . Cuando se empaqueta en un proveedor APEX, enumere las bibliotecas en una propiedad provideNativeLibs en el manifiesto APEX.

Actualización de aplicaciones para que no utilicen bibliotecas nativas no públicas

Esta característica está habilitada solo para aplicaciones destinadas a la versión 24 o posterior del SDK; para obtener compatibilidad con versiones anteriores, consulte la Tabla 1. Qué esperar si su aplicación se vincula con bibliotecas nativas privadas . La lista de bibliotecas nativas de Android a las que pueden acceder las aplicaciones (también conocidas como bibliotecas nativas públicas) se incluye en la sección 3.1.1 de CDD. Las aplicaciones orientadas a 24 años o más y que utilizan bibliotecas no públicas deben actualizarse. Consulte Aplicaciones NDK vinculadas a bibliotecas de plataforma para obtener más detalles.

Actualización de aplicaciones para sus dependencias de biblioteca nativas

Las aplicaciones destinadas a la versión 31 del SDK (Android 12) o superior deben especificar explícitamente sus dependencias de biblioteca compartida nativa mediante la etiqueta <uses-native-library> en el manifiesto de la aplicación. Si alguna parte de la biblioteca solicitada no existe en el dispositivo, la aplicación no está instalada. Cuando se instalan las aplicaciones, solo se les proporcionan las bibliotecas nativas compartidas que han solicitado. Esto significa que las aplicaciones no pueden acceder a bibliotecas compartidas nativas que no aparecen en el manifiesto de la aplicación.