自 2025 年 3 月 27 日起，我們建議您使用 android-latest-release 而非 aosp-main 建構及貢獻 AOSP。詳情請參閱「Android 開放原始碼計畫變更」。
原生程式庫的命名空間
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
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。應用程式連結至私人原生資料庫時的預期結果。應用程式可存取的 Android 原生程式庫清單 (也稱為公開原生程式庫) 列於 CDD 的第 3.1.1 節。針對 24 以上版本為目標版本的應用程式，如果使用任何非公開的程式庫，都應進行更新。詳情請參閱「連結至平台程式庫的 NDK 應用程式 」。
更新應用程式，以便使用原生程式庫依附元件
鎖定 SDK 31 (Android 12) 以上版本的應用程式，必須在應用程式資訊清單中使用 <uses-native-library> 標記，明確指定原生共用程式庫依附元件。如果裝置上沒有要求的程式庫的任何部分，應用程式就不會安裝。安裝應用程式時，系統會只提供應用程式要求的原生共用資料庫。也就是說，應用程式無法存取未顯示在應用程式資訊清單中的原生共用程式庫。
這個頁面中的內容和程式碼範例均受《內容授權》中的授權所規範。Java 與 OpenJDK 是 Oracle 和/或其關係企業的商標或註冊商標。
上次更新時間：2025-07-27 (世界標準時間)。
[[["容易理解","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"]],["上次更新時間：2025-07-27 (世界標準時間)。"],[],[],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."]]
