Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

Se usó la API de Cloud Translation para traducir esta página.

Espacios de nombres para bibliotecas nativas

Android 7.0 introdujo espacios de nombres para bibliotecas nativas para limitar la API interna visibilidad y resolución de situaciones en las que las apps usan accidentalmente bibliotecas en lugar de las suyas. Consulta la sección Mejora Estabilidad con restricciones de símbolos C/C++ privados en Android 7.0 en Android Entrada del blog para desarrolladores sobre los cambios específicos de la app.

Arquitectura

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

Figura 1: Espacios de nombres para bibliotecas nativas.

Los espacios de nombres para bibliotecas nativas evitan que las apps usen nativos de plataformas privadas. (como se hizo con OpenSSL). También quita las situaciones en las que las apps usar accidentalmente bibliotecas de plataformas en lugar de las propias (como se observó con libpng). Las bibliotecas de apps tienen dificultades con el uso interno las bibliotecas del sistema por accidente (y viceversa).

Cómo agregar bibliotecas nativas adicionales

Además de las bibliotecas nativas públicas estándares, 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 a las apps colocándolas en las carpetas respectivas de bibliotecas y enumerándolas explícitamente; en archivos .txt.

Las carpetas de la biblioteca son las siguientes:

/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

Estos son los archivos .txt:

/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 hace referencia 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 de este tipo en un dispositivo si algunas bibliotecas son de una solución externa proveedores.

Bibliotecas nativas en la partición system que los fabricantes de dispositivos hacen públicas DEBE 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 ser público. El COMPANYNAME en el nombre del archivo de la biblioteca DEBE coincidir con el COMPANYNAME en el .txt, en el que aparece el nombre de la biblioteca.

Las bibliotecas nativas que forman parte del AOSP NO DEBEN ser públicas (excepto la versión estándar bibliotecas nativas públicas que son públicas de forma predeterminada). Solo las bibliotecas adicionales que agregue los proveedores de silicio o los fabricantes de dispositivos pueden ser accesibles para las apps.

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

La biblioteca nativa del proveedor debe estar etiquetada como corresponde para que se pueda accesibles a las apps. Si alguna aplicación requiere acceso (incluidos los apps de terceros), la biblioteca debe estar etiquetada 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. Ubica la lista de VNDK-SP y LLNDK en development/vndk/tools/definition/tool/datasets/eligible-list-<version>-release.csv

A partir de Android 15, las bibliotecas públicas de proveedores se pueden colocar en un proveedor APEX. Cuando se empaquetan en un APEX de proveedor, se enumeran las bibliotecas En una propiedad provideNativeLibs del manifiesto de APEX.

Actualiza las apps para que no usen bibliotecas nativas no públicas

Esta función solo está habilitada para las apps que se orientan a la versión 24 o versiones posteriores del SDK. para la retrocompatibilidad, consulta la Tabla 1)Qué sucede si tu app se vincula con bibliotecas nativas privadas. La lista de bibliotecas nativas de Android a las que pueden acceder las apps (también conocida como bibliotecas nativas públicas) se incluye en la sección 3.1.1 del CDD. las apps orientadas a la 24 o más adelante y el uso de cualquier biblioteca no pública debería actualizarse. Consulta NDK Apps vinculadas a bibliotecas de la plataforma para obtener más información.

Actualiza las apps para sus dependencias de bibliotecas nativas

Las apps que se orientan a SDK versión 31 (Android 12) o posterior especifican de forma explícita sus dependencias de bibliotecas compartidas nativas con el <uses-native-library> en el manifiesto de la app. Si alguna parte de la solicitud no existe en el dispositivo, la app no está instalada. Cuando las apps se instalan, se se proporcionan solo con las bibliotecas nativas compartidas que solicitaron. Esto significa que Las apps no pueden acceder a bibliotecas compartidas nativas que no aparecen en el manifiesto de la app.