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

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. Ver la Estabilidad Mejorando con restricciones Privado C / C ++ de símbolos en Android 7.0 Android Desarrolladores entrada de blog para 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.

Espacios de nombres para bibliotecas nativas

Figura 1. Los espacios de nombres para las bibliotecas nativas

Los espacios de nombres para bibliotecas nativas evitan que las aplicaciones utilicen API nativas de plataforma privada (como se hizo con OpenSSL). También elimina las situaciones en las aplicaciones accidentalmente utilizan bibliotecas de la plataforma en lugar de su propio (como lo demuestra con libpng ). Es difícil para las bibliotecas de aplicaciones usar las 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 a las aplicaciones colocándolas en las respectivas carpetas de la biblioteca y enumerándolas explícitamente en .txt archivos.

Las carpetas de la biblioteca son:

  • /vendor/lib (para 32 bits) y /vendor/lib64 (para 64-bit) para las bibliotecas de proveedores de silicio
  • /system/lib (para 32 bits) y /system/lib64 (para 64-bit) para las bibliotecas de los fabricantes de dispositivos

Los archivos .txt son:

  • /vendor/etc/public.libraries.txt para las bibliotecas de proveedores de silicio
  • /system/etc/public.libraries-COMPANYNAME.txt para las bibliotecas de los fabricantes de dispositivos, donde COMPANYNAME se refiere 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 son de proveedores de soluciones externos.

Bibliotecas nativas en el system partición que se hacen públicas por los fabricantes de dispositivos deben ser nombrados lib*COMPANYNAME.so , por ejemplo, libFoo.awesome.company.so . En otras palabras, libFoo.so sin el sufijo de nombre de la empresa NO DEBE hacerse pública. El COMPANYNAME en el nombre de archivo de la biblioteca debe coincidir con el COMPANYNAME en el nombre del archivo txt en la que aparece el nombre de 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 necesarias:

  1. La biblioteca nativa del proveedor debe estar correctamente etiquetada para que las aplicaciones puedan acceder a ella. Si el acceso es requerido por ninguna de las aplicaciones (incluyendo aplicaciones de terceros), la biblioteca debe ser etiquetado como same_process_hal_file en un proveedor específicos file_contexts archivo 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 bibliotecas del sistema distintas de las bibliotecas VNDK-SP y LLNDK. Busque la lista de bibliotecas VNDK-SP y LLNDK en development/vndk/tools/definition/tool/datasets/eligible-list-<version>-release.csv .

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

Esta función está habilitada solo para aplicaciones destinadas a la versión 24 o posterior del SDK; para la compatibilidad con versiones anteriores, véase la Tabla 1. Qué esperar si su aplicación está vinculada con las librerías 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 del CDD. Deben actualizarse las aplicaciones que tengan como objetivo 24 años o más y que utilicen bibliotecas no públicas. Ver NDK Aplicaciones de Enlace de Bibliotecas de la plataforma para obtener más detalles.

Actualización de aplicaciones para sus dependencias de bibliotecas nativas

Las aplicaciones que SDK objetivo versión 31 (androide 12) o superior debe especificar explícitamente las dependencias de bibliotecas compartidas nativas utilizando el <uses-native-library> etiqueta 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, que están provistos con sólo las bibliotecas compartidas nativas que se ha solicitado. Esto significa que las aplicaciones no pueden acceder a bibliotecas compartidas nativas que no aparecen en el manifiesto de la aplicación.