Espacios de nombres para bibliotecas nativas

Android 7.0 introdujo espacios de nombres para las bibliotecas nativas con el objetivo de 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 del blog para desarrolladores de Android sobre cómo mejorar la estabilidad con restricciones de símbolos C/C++ privados en Android 7.0 para conocer los cambios específicos de las apps.

Arquitectura

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

Espacios de nombres para bibliotecas nativas

Figura 1: Son los espacios de nombres para las bibliotecas nativas.

Los espacios de nombres para las bibliotecas nativas impiden que las apps usen APIs nativas de la plataforma privada (como se hizo con OpenSSL). También elimina situaciones en las que las apps usan accidentalmente bibliotecas de la plataforma en lugar de las propias (como se observó con libpng). Es difícil que las bibliotecas de apps usen bibliotecas internas del sistema por accidente (y viceversa).

Agrega 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 pueden acceder colocándolas en las carpetas de bibliotecas respectivas 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 semiconductores
  • /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 silicona
  • /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_.-]+; 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 biblioteca DEBE coincidir con el COMPANYNAME en el nombre del archivo .txt en el que se indica 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 se puede permitir el acceso a las apps a las bibliotecas adicionales que agreguen los proveedores de silicio o los fabricantes de dispositivos.

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

  1. La biblioteca nativa del proveedor debe estar etiquetada correctamente para que las apps puedan acceder a ella. Si alguna app (incluidas las 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.
  2. La biblioteca, ya sea de forma directa o transitiva a través de sus dependencias, no debe depender de bibliotecas del sistema que no sean bibliotecas de VNDK-SP y LLNDK. Ubica 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 del proveedor se pueden colocar en un APEX del proveedor. Cuando se empaquetan en un APEX del proveedor, se deben enumerar las bibliotecas en una propiedad provideNativeLibs en el manifiesto del APEX.

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

Esta función solo está habilitada para las apps que segmentan el SDK versión 24 o posterior. Para 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 la sección 3.1.1 del CDD. Se deben actualizar las apps que segmenten versiones de API 24 o posteriores y que usen bibliotecas no públicas. Consulta Cómo vincular apps NDK a bibliotecas de la plataforma para obtener más detalles.

Actualiza las apps para sus dependencias de bibliotecas nativas

Las apps que se segmentan para la versión del SDK 31 (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, no se instalará la app. Cuando se instalan las apps, se les proporcionan solo las bibliotecas compartidas nativas que solicitaron. Esto significa que las apps no pueden acceder a las bibliotecas compartidas nativas que no aparecen en el manifiesto de la app.