ตั้งแต่วันที่ 27 มีนาคม 2025 เป็นต้นไป เราขอแนะนำให้ใช้ android-latest-release แทน aosp-main เพื่อสร้างและมีส่วนร่วมใน AOSP โปรดดูข้อมูลเพิ่มเติมที่หัวข้อการเปลี่ยนแปลงใน AOSP
เนมสเปซของไลบรารีที่มาพร้อมเครื่อง
จัดทุกอย่างให้เป็นระเบียบอยู่เสมอด้วยคอลเล็กชัน
บันทึกและจัดหมวดหมู่เนื้อหาตามค่ากำหนดของคุณ
Android 7.0 ได้เปิดตัวเนมสเปซสําหรับไลบรารีแบบเนทีฟเพื่อจํากัดระดับการเข้าถึง API ภายในและแก้ไขสถานการณ์ที่แอปใช้ไลบรารีแพลตฟอร์มแทนไลบรารีของตนเองโดยไม่ตั้งใจ ดูการเปลี่ยนแปลงเฉพาะแอปได้ที่บล็อกโพสต์การปรับปรุงความเสถียรด้วยข้อจำกัดสัญลักษณ์ C/C++ ส่วนตัวใน Android 7.0 ของนักพัฒนาแอป 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 ในชื่อไฟล์ไลบรารีต้องตรงกับ COMPANYNAME ในชื่อไฟล์ txt ที่มีชื่อไลบรารีแสดงอยู่
ไลบรารีแบบเนทีฟที่เป็นส่วนหนึ่งของ AOSP ต้องไม่เผยแพร่แบบสาธารณะ (ยกเว้นไลบรารีแบบเนทีฟสาธารณะมาตรฐานที่เผยแพร่แบบสาธารณะโดยค่าเริ่มต้น) เฉพาะไลบรารีเพิ่มเติมที่เพิ่มโดยผู้ให้บริการชิปหรือผู้ผลิตอุปกรณ์เท่านั้นที่จะเข้าถึงได้สำหรับแอป
ตั้งแต่ Android 8.0 เป็นต้นไป ไลบรารีสาธารณะของผู้ให้บริการจะมีข้อจำกัดเพิ่มเติมและการตั้งค่าที่จำเป็นดังต่อไปนี้
- ไลบรารีแบบเนทีฟในผู้ให้บริการต้องมีการติดป้ายกำกับอย่างถูกต้องเพื่อให้แอปเข้าถึงได้ หากแอปใดก็ตาม (รวมถึงแอปของบุคคลที่สาม) จำเป็นต้องมีสิทธิ์เข้าถึง ห้องสมุดต้องติดป้ายกํากับเป็น
same_process_hal_file ในไฟล์ file_contexts เฉพาะผู้ให้บริการ ดังนี้
/vendor/lib(64)?/libnative.so u:object_r:same_process_hal_file:s0
โดยที่ libnative.so คือชื่อของไลบรารีแบบเนทีฟ
- ไลบรารีต้องไม่ขึ้นอยู่กับไลบรารีระบบอื่นๆ นอกเหนือจากไลบรารี VNDK-SP และ LLNDK โดยตรงหรือโดยอ้อมผ่าน Dependency ค้นหารายการของ
ไลบรารี VNDK-SP และ LLNDK ที่
development/vndk/tools/definition/tool/datasets/eligible-list-<version>-release.csv
ตั้งแต่ Android 15 เป็นต้นไป คุณสามารถใส่ไลบรารีสาธารณะของผู้ให้บริการไว้ใน APEX ของผู้ให้บริการ เมื่อแพ็กเกจใน APEX ของผู้ให้บริการ ให้แสดงไลบรารีในพร็อพเพอร์ตี้ provideNativeLibs ในไฟล์ Manifest ของ APEX
อัปเดตแอปเพื่อไม่ให้ใช้ไลบรารีเนทีฟที่ไม่ใช่แบบสาธารณะ
ฟีเจอร์นี้ใช้ได้กับแอปที่กำหนดเป้าหมายเป็น SDK เวอร์ชัน 24 ขึ้นไปเท่านั้น หากต้องการใช้กับเวอร์ชันเก่า โปรดดูตาราง 1 สิ่งที่จะเกิดขึ้นหากแอปของคุณลิงก์กับไลบรารีแบบเนทีฟส่วนตัว
รายการไลบรารี Android ที่เป็นเนทีฟซึ่งแอปเข้าถึงได้ (หรือที่เรียกว่า "ไลบรารีที่เป็นเนทีฟแบบสาธารณะ") แสดงอยู่ในส่วน 3.1.1 ของ CDD แอปที่กำหนดเป้าหมายเป็นเวอร์ชัน 24 ขึ้นไปและใช้ไลบรารีที่ไม่ใช่แบบสาธารณะควรอัปเดต ดูรายละเอียดเพิ่มเติมได้ที่ NDK
การลิงก์แอปกับไลบรารีแพลตฟอร์ม
อัปเดตแอปสำหรับทรัพยากร Dependency ของไลบรารีแบบเนทีฟ
แอปที่กำหนดเป้าหมายเป็น SDK เวอร์ชัน 31 (Android 12) ขึ้นไปต้องระบุอย่างชัดแจ้งทรัพยากร Dependency ของไลบรารีที่แชร์แบบเนทีฟโดยใช้แท็ก <uses-native-library> ในไฟล์ Manifest ของแอป หากไม่มีส่วนใดของไลบรารีที่ขอในอุปกรณ์ ระบบจะไม่ติดตั้งแอป เมื่อติดตั้งแอปแล้ว แอปจะได้รับเฉพาะไลบรารีที่ใช้ร่วมกันแบบเนทีฟที่ขอ ซึ่งหมายความว่าแอปจะเข้าถึงไลบรารีที่ใช้ร่วมกันแบบเนทีฟซึ่งไม่ปรากฏในไฟล์ Manifest ของแอปไม่ได้
ตัวอย่างเนื้อหาและโค้ดในหน้าเว็บนี้ขึ้นอยู่กับใบอนุญาตที่อธิบายไว้ในใบอนุญาตการใช้เนื้อหา Java และ OpenJDK เป็นเครื่องหมายการค้าหรือเครื่องหมายการค้าจดทะเบียนของ Oracle และ/หรือบริษัทในเครือ
อัปเดตล่าสุด 2025-07-27 UTC
[[["เข้าใจง่าย","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 UTC"],[],[],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."]]
