Namespaces for native libraries

Android 7.0 introduced namespaces for native libraries to limit internal API visibility and resolve situations where apps accidentally use platform libraries instead of their own. See the Improving Stability with Private C/C++ Symbol Restrictions in Android 7.0 Android Developers blog post for app-specific changes.

Architecture

In Android 7.0 and higher, system libraries are separated from app libraries.

Namespaces for native libraries

Figure 1. Namespaces for native libraries.

Namespaces for native libraries prevent apps from using private-platform native APIs (as was done with OpenSSL). It also removes situations where apps accidentally use platform libraries instead of their own (as witnessed with libpng). It's difficult for app libraries to use internal system libraries by accident (and vice versa).

Add additional native libraries

In addition to standard public native libraries, silicon vendors (starting from Android 7.0) and device manufacturers (starting from Android 9) may choose to provide additional native libraries accessible to apps by putting them under the respective library folders and explicitly listing them in .txt files.

The library folders are:

  • /vendor/lib (for 32-bit) and /vendor/lib64 (for 64-bit) for libraries from silicon vendors
  • /system/lib (for 32-bit) and /system/lib64 (for 64-bit) for libraries from device manufacturers

The .txt files are:

  • /vendor/etc/public.libraries.txt for libraries from silicon vendors
  • /system/etc/public.libraries-COMPANYNAME.txt for libraries from device manufacturers, where COMPANYNAME refers to a name of the manufacturer (such as awesome.company). COMPANYNAME must match with [A-Za-z0-9_.-]+; alphanumeric characters, _, . (dot) and -. It is possible to have multiple such .txt files in a device if some libraries are from external solution providers.

Native libraries in the system partition that are made public by device manufacturers MUST be named lib*COMPANYNAME.so, for example, libFoo.awesome.company.so. In other words, libFoo.so without the company name suffix MUST NOT be made public. The COMPANYNAME in the library file name MUST match with the COMPANYNAME in the txt file name in which the library name is listed.

Native libraries that are part of AOSP MUST NOT be made public (except the standard public native libraries which are public by default). Only the additional libraries added by silicon vendors or device manufacturers can be made accessible to apps.

Starting from Android 8.0, vendor public libraries have the following additional restrictions and required setups:

  1. The native library in vendor must be properly labeled so it can be accessible to apps. If access is required by any apps (including third party apps), the library must be labeled as same_process_hal_file in a vendor-specific file_contexts file as follows: 
    /vendor/lib(64)?/libnative.so u:object_r:same_process_hal_file:s0
    where libnative.so is the name of the native library.
  2. The library, either directly or transitively through its dependencies, must not depend on system libraries other than VNDK-SP and LLNDK libraries. Locate the list of VNDK-SP and LLNDK libraries at development/vndk/tools/definition/tool/datasets/eligible-list-<version>-release.csv.

Starting from Android 15, vendor public libraries can be put in a vendor APEX. When packaged in a vendor APEX, list the libraries in a provideNativeLibs property in the APEX manifest.

Update apps to not use nonpublic native libraries

This feature is enabled only for apps targeting SDK version 24 or later; for backward compatibility, see Table 1. What to expect if your app is linking against private native libraries. The list of Android native libraries accessible to apps (also know as public native libraries) is listed in CDD section 3.1.1. Apps targeting 24 or later and using any non-public libraries should be updated. See NDK Apps Linking to Platform Libraries for more details.

Update apps for their native library dependencies

Apps that target SDK version 31 (Android 12) or higher must explicitly specify their native shared library dependencies by using the <uses-native-library> tag in the app manifest. If any part of the requested library doesn't exist on the device, the app isn't installed. When the apps are installed, they're provided with only the native shared libraries that they've requested. This means that apps can't access native shared libraries that don't appear in the app manifest.