自 2025 年 3 月 27 日起，我们建议您使用 android-latest-release 而非 aosp-main 构建 AOSP 并为其做出贡献。如需了解详情，请参阅 AOSP 的变更。
原生库的命名空间
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
Android 7.0 为原生库引入了命名空间，以限制内部 API 的可见性，并解决应用意外使用平台库（而非它们自己的库）的问题。请参阅通过 Android 7.0 中的私有 C/C++ 符号限制提升稳定性这篇 Android 开发者博文，了解针对应用的更改。
架构
在 Android 7.0 及更高版本中，系统库与应用库是分开的。
图 1. 原生库的命名空间
原生库的命名空间可防止应用使用私有平台的原生 API（例如使用 OpenSSL）。该命名空间还可以避免应用意外使用平台库（而非它们自己的库）的问题（如使用 libpng 时）。应用库很难意外使用内部系统库（反之亦然）。
添加其他原生库
除了标准的公共原生库之外，芯片供应商（从 Android 7.0 起）和设备制造商（从 Android 9 起）还可以选择提供可供应用访问的其他原生库，方法是将它们放在相应的库文件夹中，并在 .txt 文件中显式列出它们。
库文件夹是：
/vendor/lib（对于芯片供应商的 32 位库）和 /vendor/lib64（对于芯片供应商的 64 位库）/system/lib（对于设备制造商的 32 位库）和 /system/lib64（对于设备制造商的 64 位库）
.txt 文件是：
/vendor/etc/public.libraries.txt（对于芯片供应商的库）/system/etc/public.libraries-COMPANYNAME.txt（对于设备制造商的库），其中 COMPANYNAME 指的是制造商的名称（例如 awesome.company）。COMPANYNAME 应符合 [A-Za-z0-9_.-]+ 格式（字母数字字符 , _, .（点）和 -。如果某些库来自外部解决方案提供商，则可以在设备中包含多个此类 .txt 文件。
设备制造商公开的 system 分区中的原生库必须命名为 lib*COMPANYNAME.so，例如 libFoo.awesome.company.so。
换句话说，没有公司名称后缀的 libFoo.so 不得公开。库文件名中的 COMPANYNAME 必须与列出库名称的 txt 文件名称中的 COMPANYNAME 匹配。
作为 AOSP 一部分的原生库不得公开（默认情况下公开的标准公共原生库除外）。只有芯片供应商或设备制造商添加的其他库可供应用访问。
从 Android 8.0 开始，供应商的公共库需要遵循以下额外限制，并且需要进行相应的设置：
- 供应商的原生库必须添加适当的标签，以供应用访问。如有任何应用（包括第三方应用）要求访问原生库，则该库必须在供应商专用的
file_contexts 文件中标记为 same_process_hal_file，具体如下所示：/vendor/lib(64)?/libnative.so u:object_r:same_process_hal_file:s0
其中，libnative.so 为原生库的名称。
- 该库不得依赖（无论是直接依赖，还是通过其依赖关系间接依赖）VNDK-SP 库和 LLNDK 库之外的任何系统库。在
development/vndk/tools/definition/tool/datasets/eligible-list-<version>-release.csv 中找到 VNDK-SP 库和 LLNDK 库的列表。
从 Android 15 开始，供应商公共库可以放入供应商 APEX 中。如果已将库打包到供应商 APEX 中，请在 APEX 清单的 provideNativeLibs 属性中列出这些库。
更新应用，使其不使用非公共原生库
仅针对目标 SDK 版本为 24 或更高的应用启用了此功能；如需了解向后兼容性，请参阅表 1。 当应用关联到私有原生库时会发生什么情况。
CDD 第 3.1.1 节列出了可供应用访问的 Android 原生库（又称为公共原生库）。支持版本 24 或更高版本且使用任何非公共库的应用应进行更新。如需了解详情，请参阅链接到平台库的 NDK 应用。
更新应用以获取其原生库依赖项
以 SDK 版本 31 (Android 12) 或更高版本为目标平台的应用必须在应用清单中使用 <uses-native-library> 标记显式指定其原生共享库依赖项。如果设备上不存在所请求库的任何部分，则未安装应用。应用安装时，系统仅向他们提供已请求的原生共享库。这意味着，应用无法访问应用清单中未显示的原生共享库。
本页面上的内容和代码示例受内容许可部分所述许可的限制。Java 和 OpenJDK 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC)：2025-03-04。
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["没有我需要的信息","missingTheInformationINeed","thumb-down"],["太复杂/步骤太多","tooComplicatedTooManySteps","thumb-down"],["内容需要更新","outOfDate","thumb-down"],["翻译问题","translationIssue","thumb-down"],["示例/代码问题","samplesCodeIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-03-04。"],[],[],null,["# Namespaces for native libraries\n\nAndroid 7.0 introduced namespaces for native libraries to limit internal API\nvisibility and resolve situations where apps accidentally use platform\nlibraries instead of their own. See the [Improving\nStability with Private C/C++ Symbol Restrictions in Android 7.0](http://android-developers.blogspot.com/2016/06/improving-stability-with-private-cc.html) Android\nDevelopers blog post for app-specific changes.\n\nArchitecture\n------------\n\n\nIn Android 7.0 and higher, system libraries are separated from app libraries.\n\n\n**Figure 1.** Namespaces for native libraries.\n\n\nNamespaces for native libraries prevent apps from using private-platform native\nAPIs (as was done with OpenSSL). It also removes situations where apps\naccidentally use platform libraries instead of their own (as witnessed\nwith `libpng`). It's difficult for app libraries to use internal\nsystem libraries by accident (and vice versa).\n\nAdd additional native libraries\n-------------------------------\n\n\nIn addition to standard public native libraries, silicon vendors (starting from Android 7.0) and\ndevice manufacturers (starting from Android 9) may choose to provide additional native libraries\naccessible to apps by putting them under the respective library folders and explicitly listing them\nin .txt files.\n\nThe library folders are:\n\n- `/vendor/lib` (for 32-bit) and `/vendor/lib64` (for 64-bit) for libraries from silicon vendors\n- `/system/lib` (for 32-bit) and `/system/lib64` (for 64-bit) for libraries from device manufacturers\n\nThe .txt files are:\n\n- `/vendor/etc/public.libraries.txt` for libraries from silicon vendors\n- `/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.\n\n\nNative libraries in the `system` partition that are made public by device manufacturers\n**MUST** be named `lib*COMPANYNAME.so`, for example, `libFoo.awesome.company.so`.\nIn other words, `libFoo.so` without the company name suffix MUST NOT be made public.\nThe `COMPANYNAME` in the library file name MUST match with the `COMPANYNAME` in the\ntxt file name in which the library name is listed.\n\n\nNative libraries that are part of AOSP MUST NOT be made public (except the standard\npublic native libraries which are public by default). Only the additional libraries added by\nsilicon vendors or device manufacturers can be made accessible to apps.\n\n\nStarting from Android 8.0, vendor public libraries have the following additional\nrestrictions and required setups:\n\n1. 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: \n\n ```\n /vendor/lib(64)?/libnative.so u:object_r:same_process_hal_file:s0\n ```\n where `libnative.so` is the name of the native library.\n2. 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-\u003cversion\u003e-release.csv`.\n\n\nStarting from Android 15, vendor public libraries can be put in a\n[vendor APEX](/docs/core/ota/vendor-apex). When packaged in a vendor APEX, list the libraries\nin a `provideNativeLibs` property in the APEX manifest.\n\nUpdate apps to not use nonpublic native libraries\n-------------------------------------------------\n\n\nThis feature is enabled only for apps targeting SDK version 24 or later;\nfor backward compatibility, see [Table\n1. What to expect if your app is linking against private native libraries](http://android-developers.blogspot.com/2016/06/improving-stability-with-private-cc.html).\nThe list of Android native libraries accessible to apps (also know as\npublic native libraries) is listed in CDD section 3.1.1. Apps targeting 24 or\nlater and using any non-public libraries should be updated. See [NDK\nApps Linking to Platform Libraries](https://developer.android.com/about/versions/nougat/android-7.0-changes.html#ndk) for more details.\n\nUpdate apps for their native library dependencies\n-------------------------------------------------\n\nApps that target SDK version 31 (Android 12) or higher must\n*explicitly specify* their native shared library dependencies by using the\n`\u003cuses-native-library\u003e` tag in the app manifest. If any part of the requested\nlibrary doesn't exist on the device, the app isn't installed. When the apps are installed, they're\nprovided with *only* the native shared libraries that they've requested. This means that\napps can't access native shared libraries that don't appear in the app manifest."]]
