Vendor Native Development Kit (VNDK) เป็นชุดของไลบรารีสำหรับผู้ขายโดยเฉพาะเพื่อนำ HAL ไปใช้ VNDK จัดส่งใน system.img
และเชื่อมโยงกับรหัสผู้ขายแบบไดนามิกขณะรันไทม์
ทำไมต้อง VNDK?
Android 8.0 และสูงกว่าเปิดใช้งานการอัปเดตเฉพาะเฟรมเวิร์ก ซึ่งพาร์ติชั่นระบบสามารถอัพเกรดเป็นเวอร์ชันล่าสุดได้ในขณะที่พาร์ติชั่นของผู้จำหน่ายไม่เปลี่ยนแปลง นี่หมายความว่าไบนารีที่สร้างขึ้นในเวลาต่างกันจะต้องสามารถทำงานร่วมกันได้ VNDK ครอบคลุมการเปลี่ยนแปลง API/ABI ใน Android รุ่นต่างๆ
การอัปเดตเฉพาะเฟรมเวิร์กรวมถึงความท้าทายต่อไปนี้:
- การพึ่งพาระหว่างโมดูลกรอบงานและโมดูลผู้ขาย ก่อน Android 8.0 โมดูลจากทั้งสองฝ่ายสามารถเชื่อมโยงกับโมดูลจากอีกด้านหนึ่งได้ อย่างไรก็ตาม การขึ้นต่อกันจากโมดูลผู้ขายกำหนดข้อจำกัดที่ไม่ต้องการสำหรับการพัฒนาโมดูลเฟรมเวิร์ก
- ส่วนขยายไปยังไลบรารี AOSP Android 8.0 ขึ้นไปกำหนดให้อุปกรณ์ Android ทั้งหมดต้องผ่าน CTS เมื่อพาร์ติชันระบบถูกแทนที่ด้วย Generic System Image (GSI) มาตรฐาน อย่างไรก็ตาม เนื่องจากผู้จำหน่ายขยายไลบรารี AOSP เพื่อเพิ่มประสิทธิภาพหรือเพิ่มฟังก์ชันพิเศษสำหรับการใช้งาน HIDL การแฟลชพาร์ติชันระบบด้วย GSI มาตรฐานอาจทำให้การใช้งาน HIDL ของผู้ขายเสียหาย (สำหรับแนวทางการป้องกันการแตกหัก โปรดดู ที่ ส่วนขยาย VNDK )
เพื่อจัดการกับความท้าทายเหล่านี้ Android 8.0 ได้แนะนำเทคนิคต่างๆ เช่น VNDK (อธิบายไว้ในส่วนนี้), HIDL , hwbinder, การ ซ้อนทับ แผนผังอุปกรณ์ และการวางซ้อนที่แบ่งแยกดินแดน
ทรัพยากร VNDK
ส่วนนี้ประกอบด้วยทรัพยากร VNDK ต่อไปนี้:
- แนวคิด VNDK (ด้านล่าง) อธิบายเฟรมเวิร์กไลบรารีที่แบ่งใช้ HAL กระบวนการเดียวกัน (SP-HAL) และคำศัพท์ VNDK
- ส่วนขยาย VNDK จัดประเภทการเปลี่ยนแปลงเฉพาะผู้ขายออกเป็นหมวดหมู่ ตัวอย่างเช่น ไลบรารีที่มีฟังก์ชันเพิ่มเติมซึ่งโมดูลผู้ขายพึ่งพาจะต้องถูกคัดลอกลงในพาร์ติชันของผู้จัดจำหน่าย แต่ห้ามการเปลี่ยนแปลงที่เข้ากันไม่ได้ของ ABI
- การสนับสนุนระบบบิลด์ VNDK อธิบายการกำหนดค่าระบบบิลด์และไวยากรณ์คำจำกัดความโมดูลที่เกี่ยวข้องกับ VNDK
- เครื่องมือคำจำกัดความ VNDK ช่วยย้ายโครงสร้างต้นทางของคุณไปยัง Android 8.0 ขึ้นไป
- Linker Namespace ให้การควบคุมแบบละเอียดสำหรับการเชื่อมโยงไลบรารีที่ใช้ร่วมกัน
- ไดเรกทอรี กฎ และ การแยกตัวกำหนดโครงสร้างไดเรกทอรีสำหรับอุปกรณ์ที่ใช้ Android 8.0 ขึ้นไป กฎ VNDK และการแยกตัวออกจากกันที่เกี่ยวข้อง
- การนำเสนอ VNDK Design แสดงให้เห็นแนวคิด VDNK พื้นฐานที่ใช้ใน Android 8.0 ขึ้นไป
แนวคิด VNDK
ในอุดมคติของ Android 8.0 และโลกที่สูงกว่า กระบวนการของเฟรมเวิร์กจะไม่โหลดไลบรารีที่แชร์ของผู้ขาย กระบวนการของผู้ขายทั้งหมดจะโหลดเฉพาะไลบรารีที่แชร์ของผู้ขาย (และส่วนหนึ่งของเฟรมเวิร์กไลบรารีที่แชร์ร่วมกัน) และการสื่อสารระหว่างกระบวนการเฟรมเวิร์กและกระบวนการของผู้ขายถูกควบคุมโดย HIDL และฮาร์ดแวร์ เครื่องผูก
โลกดังกล่าวมีความเป็นไปได้ที่ API สาธารณะที่เสถียรจากไลบรารีที่ใช้ร่วมกันของเฟรมเวิร์กอาจไม่เพียงพอสำหรับนักพัฒนาโมดูลผู้ขาย (แม้ว่า API สามารถเปลี่ยนแปลงระหว่างรุ่น Android ได้) ซึ่งกำหนดให้กระบวนการของผู้จำหน่ายสามารถเข้าถึงบางส่วนของเฟรมเวิร์กไลบรารีที่ใช้ร่วมกันได้ นอกจากนี้ เนื่องจากข้อกำหนดด้านประสิทธิภาพอาจนำไปสู่การประนีประนอม HAL ที่มีความสำคัญต่อเวลาตอบสนองบางอย่างจึงต้องได้รับการปฏิบัติแตกต่างออกไป
ส่วนต่อไปนี้ให้รายละเอียดวิธีที่ VNDK จัดการไลบรารีที่ใช้ร่วมกันของเฟรมเวิร์กสำหรับผู้ขายและ HAL กระบวนการเดียวกัน (SP-HAL)
กรอบงานไลบรารีที่ใช้ร่วมกันสำหรับผู้จำหน่าย
ส่วนนี้อธิบายเกณฑ์สำหรับการจัดประเภทไลบรารีที่ใช้ร่วมกันที่กระบวนการของผู้จัดจำหน่ายสามารถเข้าถึงได้ มีสองวิธีในการสนับสนุนโมดูลผู้ขายใน Android หลายรุ่น:
- ทำให้ ABIs/API ของเฟรมเวิร์กไลบรารีที่แบ่งใช้มีเสถียรภาพ โมดูลเฟรมเวิร์กใหม่และโมดูลผู้ขายเก่าสามารถใช้ไลบรารีที่ใช้ร่วมกันเดียวกันเพื่อลดพื้นที่หน่วยความจำและขนาดหน่วยเก็บข้อมูล ไลบรารีที่ใช้ร่วมกันที่ไม่ซ้ำกันยังช่วยหลีกเลี่ยงปัญหาการโหลดซ้ำหลายครั้งอีกด้วย อย่างไรก็ตาม ต้นทุนในการพัฒนาเพื่อรักษา ABI/API ให้เสถียรนั้นสูง และทำให้ ABI/APIs เสถียรทั้งหมดที่ส่งออกโดยไลบรารีที่ใช้ร่วมกันของเฟรมเวิร์กทุกอันนั้นไม่สมเหตุสมผล
- คัดลอกไลบรารีที่ใช้ร่วมกันของเฟรมเวิร์กเก่า มาพร้อมกับข้อจำกัดที่แข็งแกร่งสำหรับช่องสัญญาณด้านข้าง ซึ่งกำหนดเป็นกลไกทั้งหมดในการสื่อสารระหว่างโมดูลเฟรมเวิร์กและโมดูลผู้ขาย ซึ่งรวมถึง (แต่ไม่จำกัดเพียง) ตัวประสาน ซ็อกเก็ต ไพพ์ หน่วยความจำที่ใช้ร่วมกัน ไฟล์ที่ใช้ร่วมกัน และคุณสมบัติของระบบ ต้องไม่มีการสื่อสารเว้นแต่โปรโตคอลการสื่อสารจะถูกระงับและเสถียร (เช่น HIDL ผ่าน hwbinder) การโหลดไลบรารีที่แบ่งใช้สองครั้งอาจทำให้เกิดปัญหาได้เช่นกัน ตัวอย่างเช่น ถ้าวัตถุที่สร้างโดยไลบรารีใหม่ถูกส่งผ่านไปยังฟังก์ชันจากไลบรารีเก่า ข้อผิดพลาดอาจเกิดขึ้นเนื่องจากไลบรารีเหล่านี้อาจตีความอ็อบเจ็กต์ต่างกัน
มีการใช้วิธีการที่แตกต่างกันขึ้นอยู่กับลักษณะของไลบรารีที่แบ่งใช้ ด้วยเหตุนี้ ไลบรารีที่ใช้ร่วมกันของเฟรมเวิร์กจึงถูกจัดประเภทเป็นสามหมวดย่อย:
- LL-NDK Libraries เป็น Framework Shared Libraries ที่ทราบว่ามีเสถียรภาพ นักพัฒนาของพวกเขามุ่งมั่นที่จะรักษาความเสถียรของ API/ABI
- LL-NDK ประกอบด้วยไลบรารีต่อไปนี้:
libEGL.so
,libGLESv1_CM.so
,libGLESv2.so
,libGLESv3.so
,libandroid_net.so
,libc.so
,libdl.so
,liblog.so
,libm.so
,libnativewindow.so
libneuralnetworks.so
libsync.so
libvndksupport.so
และlibvulkan.so
- LL-NDK ประกอบด้วยไลบรารีต่อไปนี้:
- VNDK Libraries (VNDK) ที่มีสิทธิ์คือ Framework Shared Libraries ที่ปลอดภัยสำหรับการคัดลอกสองครั้ง Framework Modules และ Vendor Modules สามารถเชื่อมโยงกับสำเนาของตนเองได้ ไลบรารีที่ใช้ร่วมกันของเฟรมเวิร์กสามารถกลายเป็นไลบรารี VNDK ที่มีสิทธิ์ได้ก็ต่อเมื่อตรงตามเกณฑ์ต่อไปนี้:
- ไม่ส่ง/รับ IPC ไปยัง/จากเฟรมเวิร์ก
- ไม่เกี่ยวข้องกับเครื่องเสมือน ART
- ไม่อ่าน/เขียนไฟล์/พาร์ติชั่นที่มีรูปแบบไฟล์ไม่เสถียร
- ไม่มีใบอนุญาตซอฟต์แวร์พิเศษซึ่งต้องมีการตรวจสอบทางกฎหมาย
- เจ้าของรหัสไม่มีการคัดค้านการใช้งานของผู้ขาย
- Framework-Only Libraries (FWK-ONLY) คือ Framework Shared Libraries ที่ไม่ได้อยู่ในหมวดหมู่ที่กล่าวถึงข้างต้น ห้องสมุดเหล่านี้:
- ถือเป็นกรอบรายละเอียดการดำเนินการภายใน
- ต้องไม่สามารถเข้าถึงได้โดยโมดูลผู้ขาย
- มี ABI/API ที่ไม่เสถียรและไม่มีการรับประกันความเข้ากันได้ของ API/ABI
- ไม่ถูกคัดลอก
HAL กระบวนการเดียวกัน (SP-HAL)
HAL กระบวนการเดียวกัน ( SP-HAL ) คือชุดของ HAL ที่กำหนดไว้ล่วงหน้าซึ่งนำไปใช้เป็น Vendor Shared Libraries และโหลดเข้าสู่ Framework Processes SP-HAL ถูกแยกโดยเนมสเปซของตัวเชื่อมโยง (ควบคุมไลบรารีและสัญลักษณ์ที่มองเห็นได้ในไลบรารีที่แบ่งใช้) SP-HAL ต้องขึ้นอยู่กับ LL-NDK และ VNDK-SP เท่านั้น
VNDK-SP คือชุดย่อยที่กำหนดไว้ล่วงหน้าของไลบรารี VNDK ที่มีสิทธิ์ ไลบรารี VNDK-SP ได้รับการตรวจสอบอย่างรอบคอบเพื่อให้แน่ใจว่าไลบรารี VNDK-SP โหลดสองครั้งในกระบวนการเฟรมเวิร์กจะไม่ทำให้เกิดปัญหา Google เป็นผู้กำหนดทั้ง SP-HAL และ VNDK-SP
ห้องสมุดต่อไปนี้ได้รับการอนุมัติ SP-HALs:
-
libGLESv1_CM_${driver}.so
-
libGLESv2_${driver}.so
-
libGLESv3_${driver}.so
-
libEGL_${driver}.so
-
vulkan.${driver}.so
-
android.hardware.renderscript@1.0-impl.so
-
android.hardware.graphics.mapper@2.0-impl.so
ไลบรารี VNDK-SP ระบุ vndk: { support_system_process: true }
ในไฟล์ Android.bp หากมี vendor_available: false
ไลบรารีเหล่านี้จะเรียกว่า VNDK-SP-Private และ SP -HALS จะไม่ปรากฏให้เห็น
ต่อไปนี้เป็น ไลบรารีเฉพาะเฟรมเวิร์กที่มีข้อยกเว้น RS (FWK-ONLY-RS) :
-
libft2.so
(Renderscript) -
libmediandk.so
(Renderscript)
คำศัพท์ VNDK
- โมดูล อ้างถึง Shared Libraries หรือ Executables
- กระบวนการ คืองานของระบบปฏิบัติการที่เกิดจาก Executables
- กรอบงาน -ข้อกำหนดที่ผ่านการรับรองหมายถึงแนวคิดที่เกี่ยวข้องกับพาร์ติชัน ระบบ
- เงื่อนไขที่ผ่านการรับรองจาก ผู้จำหน่าย หมายถึงแนวคิดที่เกี่ยวข้องกับพาร์ติชันของ ผู้จัดจำหน่าย
ตัวอย่างเช่น:
- Framework Executables อ้างถึง executables ใน
/system/bin
หรือ/system/xbin
- Framework Shared Libraries อ้างถึงไลบรารีที่แบ่งใช้ภายใต้
/system/lib[64]
- Framework Modules อ้างถึงทั้ง Framework Shared Libraries และ Framework Executables
- Framework Processes เป็นกระบวนการที่เกิดจาก Framework Executables (เช่น
/system/bin/app_process
) - Vendor Executables หมายถึง executables ใน
/vendor/bin
- Vendor Shared Libraries อ้างถึงไลบรารีที่แชร์ภายใต้
/vendor/lib[64]
- โมดูลผู้จำหน่าย อ้างถึงทั้ง Vendor Executables และ Vendor Shared Libraries
- กระบวนการของผู้ขาย เป็นกระบวนการที่เกิดจาก Vendor Executables (เช่น
/vendor/bin/android.hardware.camera.provider@2.4-service
)การกำหนดเวอร์ชัน VNDK
ใน Android 9 ไลบรารีที่แชร์ VNDK มีเวอร์ชัน:
- คุณสมบัติของระบบ
ro.vndk.version
จะถูกเพิ่มโดยอัตโนมัติใน/vendor/default.prop
- ไลบรารีที่ใช้ร่วมกัน VNDK ได้รับการติดตั้งใน
/system/lib[64]/vndk-${ro.vndk.version}
- ไลบรารีที่ใช้ร่วมกัน VNDK-SP ได้รับการติดตั้งใน
/system/lib[64]/vndk-sp-${ro.vndk.version}
- ไฟล์คอนฟิกูเรชันตัวเชื่อมโยงแบบไดนามิกได้รับการติดตั้งใน
/system/etc/ld.config.${ro.vndk.version}.txt
ค่าของ ro.vndk.version
ถูกเลือกโดยอัลกอริทึมด้านล่าง:
- หาก
BOARD_VNDK_VERSION
ไม่เท่ากับcurrent
ให้ใช้BOARD_VNDK_VERSION
- หาก
BOARD_VNDK_VERSION
เท่ากับcurrent
: - หาก
PLATFORM_VERSION_CODENAME
เป็นREL
ให้ใช้PLATFORM_SDK_VERSION
(เช่น28
) - มิฉะนั้น ให้ใช้
PLATFORM_VERSION_CODENAME
(เช่นP
)
อัพเกรดอุปกรณ์
หากอุปกรณ์ Android 8.x ปิดใช้งานการบังคับใช้รันไทม์ VNDK โดยสร้างขึ้นโดยไม่มี BOARD_VNDK_VERSION
อาจเพิ่ม PRODUCT_USE_VNDK_OVERRIDE := false
ไปยัง BoardConfig.mk
ขณะอัปเกรดเป็น Android 9
ถ้า PRODUCT_USE_VNDK_OVERRIDE
เป็น false
คุณสมบัติ ro.vndk.lite
จะถูกเพิ่มโดยอัตโนมัติใน /vendor/default.prop
และค่าของมันจะเป็น true
ดังนั้น ตัวเชื่อมโยงแบบไดนามิกจะโหลดการกำหนดค่าเนมสเปซตัวเชื่อมโยงจาก /system/etc/ld.config.vndk_lite.txt
ซึ่งแยกเฉพาะ SP-HAL และ VNDK-SP
หากต้องการอัปเกรดอุปกรณ์ Android 7.0 หรือต่ำกว่าเป็น Android 9 ให้เพิ่ม PRODUCT_TREBLE_LINKER_NAMESPACES_OVERRIDE := false
ไปยัง BoardConfig.mk
ชุดทดสอบผู้ขาย (VTS)
ชุดทดสอบผู้ขาย Android 9 (VTS) กำหนดให้ใช้คุณสมบัติ ro.vndk.version
ที่ไม่ว่างเปล่า ทั้งอุปกรณ์ที่เพิ่งเปิดตัวและอุปกรณ์อัปเกรดต้องกำหนด ro.vndk.version
กรณีทดสอบ VNDK บางกรณี (เช่น VtsVndkFilesTest
และ VtsVndkDependencyTest
) อาศัยคุณสมบัติ ro.vndk.version
เพื่อโหลดชุดข้อมูลไลบรารี VNDK ที่เข้าคู่กัน
หากคุณสมบัติ ro.product.first_api_level
มากกว่า 27 จะต้องไม่กำหนดคุณสมบัติ ro.vndk.lite
VtsTreblePlatformVersionTest
จะล้มเหลวหากมีการกำหนด ro.vndk.lite
ในอุปกรณ์ Android 9 ที่เพิ่งเปิดตัวใหม่
ประวัติเอกสาร
ส่วนนี้ติดตามการเปลี่ยนแปลงเอกสาร VNDK
Android 9 เปลี่ยนไป
- เพิ่มส่วนการกำหนดเวอร์ชัน VNDK
- เพิ่มส่วน VTS
- มีการเปลี่ยนชื่อหมวดหมู่ VNDK บางประเภท:
- LL-NDK-Indirect ถูกเปลี่ยนชื่อเป็น LL-NDK-Private
- VNDK-ทางอ้อมถูกเปลี่ยนชื่อเป็น VNDK-Private
- VNDK-SP-Indirect-Private ถูกเปลี่ยนชื่อเป็น VNDK-SP-Private
- VNDK-SP-Indirect ถูกลบออก
การเปลี่ยนแปลงของ Android 8.1
- รวมไลบรารี SP-NDK เข้ากับไลบรารี LL-NDK แล้ว
- แทนที่
libui.so
ด้วยlibft2.so
ในส่วนเนมสเปซ RS เกิดข้อผิดพลาดในการรวมlibui.so
- เพิ่ม
libGLESv3.so
และlibandroid_net.so
ลงในไลบรารี LL-NDK - เพิ่ม
libion.so
ให้กับไลบรารี VNDK-SP - ลบ
libstdc++.so
ออกจากไลบรารี LL-NDK ใช้libc++.so
แทน Toolchains แบบสแตนด์อโลนบางเวอร์ชันอาจเพิ่ม-lstdc++
ไปยังแฟล็กตัวเชื่อมโยงเริ่มต้น หากต้องการปิดใช้งานค่าดีฟอลต์ ให้เพิ่ม-nodefaultlibs -lc -lm -ldl
ลงในLDFLAGS
- ย้าย
libz.so
จากไลบรารี LL-NDK ไปยัง VNDK-SP ในการกำหนดค่าบางอย่างlibz.so
อาจยังคงเป็น LL-NDK ต่อไป อย่างไรก็ตาม ไม่ควรมีความแตกต่างที่สังเกตได้