Android 7.0 introduced namespaces for native libraries to limit internal API visibility and resolve situations when apps accidentally end up using 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 application-specific changes.
Architecture
The change separates system libraries from application libraries and makes it hard to use internal system libraries by accident (and vice versa).

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 end up using platform libraries instead of their own (as witnessed
with libpng
).
Adding additional native libraries
In addition to standard public native libraries, silicon vendors (starting from Android 7.0) and device manufactures (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, whereCOMPANYNAME
refers to a name of the manufacturer (such asawesome.company
).COMPANYNAME
should 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
, e.g., 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:
- 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-specificfile_contexts
file as follows:/vendor/lib(64)?/libnative.so u:object_r:same_process_hal_file:s0
wherelibnative.so
is the name of the native library. - The library, either directly or transitively via its dependencies, must not
depend on system libraries other than VNDK-SP and LLNDK libraries. The list of
VNDK-SP and LLNDK libraries can be found at
development/vndk/tools/definition/tool/datasets/eligible-list-<version>-release.csv
.
Updating apps to not use non-public native libraries
This feature is enabled only for applications 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.