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 apps usan accidentalmente bibliotecas de la plataforma en lugar de las propias. Consulta la entrada de blog para desarrolladores de Android Cómo mejorar la estabilidad con restricciones de símbolos C/C++ privados en Android 7.0 para conocer 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 APIs nativas de plataformas privadas (como se hizo con OpenSSL). También quita las situaciones en las que las apps usan bibliotecas de la plataforma por accidente en lugar de las propias (como se ve con libpng). Es difícil que las bibliotecas de apps usen bibliotecas internas del sistema por accidente (y viceversa).

Cómo 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 a las que las apps puedan acceder. Para ello, deben colocarlas en las carpetas de bibliotecas correspondientes y enumerarlas de forma explícita 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

Los archivos .txt son los siguientes:

• /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 a un nombre del fabricante (como awesome.company). COMPANYNAME debe coincidir con [A-Za-z0-9_.-]+ y caracteres alfanuméricos, _, . (punto) y -. Es posible tener varios archivos .txt de este tipo en un dispositivo si algunas bibliotecas son de proveedores de soluciones externos.

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

Las bibliotecas nativas que forman parte del 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 que agregan 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 del proveedor tienen las siguientes restricciones y configuraciones obligatorias adicionales:

1. La biblioteca nativa del proveedor debe estar etiquetada correctamente para que las apps puedan acceder a ella. Si cualquier app (incluidas las de terceros) requiere acceso, 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.
2. La biblioteca, ya sea directa o transitivamente a través de sus dependencias, no debe depender de otras bibliotecas del sistema que no sean VNDK-SP y LLNDK. Busca la lista de bibliotecas 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 APEX de proveedor. Cuando se empaquetan en un APEX de proveedor, enumera las bibliotecas en una propiedad provideNativeLibs en el manifiesto de APEX.

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

Esta función solo está habilitada para apps que se orientan a la versión 24 del SDK o versiones posteriores. Para obtener información sobre la retrocompatibilidad, consulta la Tabla 1. Qué esperar 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 conocidas como bibliotecas nativas públicas) se encuentra en el artículo 3.1.1 del CDD. Se deben actualizar las apps que se segmentan para la versión 24 o versiones posteriores y que usan bibliotecas no públicas. Consulta Cómo vincular apps del NDK 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 la versión 31 del SDK (Android 12) o versiones posteriores deben especificar de forma explícita sus dependencias de bibliotecas compartidas nativas con la etiqueta <uses-native-library> en el manifiesto de la app. Si alguna parte de la biblioteca solicitada no existe en el dispositivo, la app no se instalará. Cuando se instalan las apps, estas solo reciben las bibliotecas nativas compartidas que solicitaron. Esto significa que las apps no pueden acceder a las bibliotecas compartidas nativas que no aparecen en el manifiesto de la app.