Vendor Native Development Kit (VNDK) คือชุดของไลบรารีที่ใช้โดยไลบรารีหรือไบนารีอื่นในผู้จำหน่ายหรือพาร์ติชันผลิตภัณฑ์บนรันไทม์สำหรับ dlopen
ทำไมต้อง VNDK?
AOSP อนุญาตการอัปเดตเฉพาะเฟรมเวิร์ก โดยพาร์ติชันระบบสามารถอัปเกรดเป็นเวอร์ชันเฟรมเวิร์กล่าสุดได้ ในขณะที่พาร์ติชันของผู้จำหน่ายไม่มีการเปลี่ยนแปลง แม้จะถูกสร้างขึ้นในเวลาที่ต่างกัน แต่ไบนารีในแต่ละพาร์ติชั่นจะต้องสามารถทำงานร่วมกันได้
การอัปเดตเฉพาะเฟรมเวิร์กประกอบด้วยความท้าทายต่อไปนี้:
- การพึ่งพาระหว่างโมดูลกรอบงานและโมดูลผู้ขาย ก่อน Android 8.0 โมดูลในผู้จำหน่ายและพาร์ติชันระบบสามารถเชื่อมโยงถึงกันได้ อย่างไรก็ตาม การขึ้นต่อกันจากโมดูลของผู้ขายทำให้เกิดข้อจำกัดที่ไม่พึงประสงค์ต่อการพัฒนาโมดูลกรอบงาน
- ส่วนขยายไปยังไลบรารี AOSP Android กำหนดให้อุปกรณ์ Android ทั้งหมดผ่าน CTS เมื่อพาร์ติชันระบบถูกแทนที่ด้วย Generic System Image (GSI) มาตรฐาน อย่างไรก็ตาม เนื่องจากผู้จำหน่ายขยายไลบรารี AOSP เพื่อเพิ่มประสิทธิภาพหรือเพิ่มฟังก์ชันพิเศษสำหรับการใช้งาน HIDL การแฟลชพาร์ติชันระบบด้วย GSI มาตรฐานอาจทำให้การใช้งาน HIDL ของผู้จำหน่ายเสียหาย สำหรับแนวทางในการป้องกันการแตกหัก โปรดดูที่ ส่วนขยาย VNDK
เพื่อจัดการกับความท้าทายเหล่านี้ Android มีฟีเจอร์หลายอย่าง เช่น VNDK (อธิบายไว้ในส่วนนี้), HIDL , hwbinder, Device Tree Overlay และ Sepolicy Overlay
ข้อกำหนดเฉพาะของ VNDK
เอกสารที่เกี่ยวข้องกับ VNDK ใช้คำศัพท์ต่อไปนี้:- โมดูล อ้างถึงไลบรารีที่แบ่งใช้หรือโปรแกรมปฏิบัติการ โมดูลสร้างการพึ่งพาเวลาบิลด์
- กระบวนการ คืองานของระบบปฏิบัติการที่เกิดจากไฟล์ปฏิบัติการ กระบวนการสร้างการพึ่งพารันไทม์
- กรอบ -เงื่อนไขที่มีคุณสมบัติเกี่ยวข้องกับพาร์ติชัน
system
: - Framework executables อ้างถึง executables ใน
/system/bin
หรือ/system/xbin
- Framework shared libraries อ้างอิงถึง shared libraries ภายใต้
/system/lib[64]
- โมดูลกรอบงาน อ้างอิงถึงทั้งไลบรารีที่ใช้ร่วมกันของกรอบงานและกรอบปฏิบัติการที่ปฏิบัติการได้
- กระบวนการเฟรมเวิร์ก คือกระบวนการที่สร้างจากไฟล์ปฏิบัติการของเฟรมเวิร์ก เช่น
/system/bin/app_process
- ผู้จัดจำหน่าย - ข้อกำหนดที่มีคุณสมบัติเหมาะสมเกี่ยวข้องกับพาร์ติชัน
vendor
: - ไฟล์ปฏิบัติการของผู้ขาย อ้างถึงไฟล์สั่งการใน
/vendor/bin
- ไลบรารีที่แบ่งใช้ของผู้ขาย อ้างถึงไลบรารีที่แบ่งใช้ภายใต้
/vendor/lib[64]
- โมดูลผู้ขาย อ้างถึงทั้งไฟล์ปฏิบัติการของผู้ขายและไลบรารีที่ใช้ร่วมกันของผู้ขาย
- กระบวนการของผู้จำหน่าย คือกระบวนการที่สร้างจากปฏิบัติการของผู้จำหน่าย เช่น
/vendor/bin/android.hardware.camera.provider@2.4-service
แนวคิดของ VNDK
ในอุดมคติของ Android 8.0 และโลกที่สูงกว่า กระบวนการเฟรมเวิร์กไม่โหลดไลบรารีที่ใช้ร่วมกันของผู้ขาย กระบวนการของผู้ขายทั้งหมดโหลดเฉพาะไลบรารีที่ใช้ร่วมกันของผู้ขาย (และส่วนหนึ่งของไลบรารีที่ใช้ร่วมกันของเฟรมเวิร์ก) และการสื่อสารระหว่างกระบวนการเฟรมเวิร์กและกระบวนการของผู้ขายถูกควบคุมโดย HIDL และฮาร์ดแวร์ เครื่องผูก
โลกดังกล่าวรวมถึงความเป็นไปได้ที่ API สาธารณะที่เสถียรจากไลบรารีที่ใช้ร่วมกันของเฟรมเวิร์กอาจไม่เพียงพอสำหรับนักพัฒนาโมดูลผู้ขาย (แม้ว่า API จะสามารถเปลี่ยนแปลงได้ระหว่าง Android รุ่นต่างๆ) โดยกำหนดให้บางส่วนของไลบรารีที่ใช้ร่วมกันของเฟรมเวิร์กต้องสามารถเข้าถึงได้โดยกระบวนการของผู้ขาย นอกจากนี้ เนื่องจากข้อกำหนดด้านประสิทธิภาพสามารถนำไปสู่การประนีประนอมได้ HAL ที่สำคัญต่อเวลาตอบสนองบางส่วนจึงต้องได้รับการปฏิบัติที่แตกต่างออกไป
ส่วนต่อไปนี้ให้รายละเอียดว่า VNDK จัดการกับ Framework Shared Libraries สำหรับผู้จำหน่ายและ Same-Process HAL (SP-HAL) อย่างไร
กรอบไลบรารีที่แบ่งใช้สำหรับผู้ขาย
ส่วนนี้อธิบายเกณฑ์สำหรับการจัดประเภทไลบรารีแบบแบ่งใช้ที่กระบวนการของผู้จำหน่ายสามารถเข้าถึงได้ มีสองวิธีในการสนับสนุนโมดูลผู้จำหน่ายใน Android หลายรุ่น:
- ทำให้ ABI/API ของไลบรารี่ที่แชร์เฟรมเวิร์กมีความเสถียร โมดูลเฟรมเวิร์กใหม่และโมดูลผู้จำหน่ายเก่าสามารถใช้ไลบรารีที่ใช้ร่วมกันเดียวกันเพื่อลดขนาดหน่วยความจำและขนาดพื้นที่จัดเก็บข้อมูล ไลบรารีที่ใช้ร่วมกันที่ไม่ซ้ำกันยังช่วยหลีกเลี่ยงปัญหาการโหลดซ้ำซ้อนหลายประการ อย่างไรก็ตาม ต้นทุนการพัฒนาเพื่อรักษา ABI/API ที่เสถียรนั้นสูง และทำให้ ABI/API ทั้งหมดที่ส่งออกโดยไลบรารีที่ใช้ร่วมกันทุกเฟรมเวิร์กมีความเสถียรนั้นเป็นไปไม่ได้
- คัดลอกไลบรารี่ที่ใช้ร่วมกันของเฟรมเวิร์กเก่า มาพร้อมกับข้อจำกัดที่เข้มงวดต่อแชนเนลด้านข้าง ซึ่งกำหนดเป็นกลไกทั้งหมดในการสื่อสารระหว่างโมดูลเฟรมเวิร์กและโมดูลผู้จำหน่าย รวมถึง (แต่ไม่จำกัดเพียง) แฟ้มประสาน ซ็อกเก็ต ไปป์ หน่วยความจำที่ใช้ร่วมกัน ไฟล์ที่ใช้ร่วมกัน และคุณสมบัติของระบบ จะต้องไม่มีการสื่อสาร เว้นแต่โปรโตคอลการสื่อสารจะหยุดนิ่งและเสถียร (เช่น HIDL ผ่าน hwbinder) ไลบรารีที่แบ่งใช้การโหลดซ้ำซ้อนอาจทำให้เกิดปัญหาเช่นกัน ตัวอย่างเช่น หากวัตถุที่สร้างโดยไลบรารีใหม่ถูกส่งผ่านไปยังฟังก์ชันจากไลบรารีเก่า ข้อผิดพลาดอาจเกิดขึ้นเนื่องจากไลบรารีเหล่านี้อาจตีความวัตถุแตกต่างออกไป
มีการใช้วิธีการที่แตกต่างกันขึ้นอยู่กับลักษณะของไลบรารีที่แบ่งใช้ ด้วยเหตุนี้ Framework Shared Library จึงถูกแบ่งออกเป็น 3 หมวดหมู่ย่อย:
- 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)
Same-Process 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 หากระบุ vndk: {private:true}
ไว้ด้วย ไลบรารีเหล่านี้จะเรียกว่า VNDK-SP-Private
และ SP-HALS จะมองไม่เห็นไลบรารีเหล่านี้
ต่อไปนี้เป็น ไลบรารีเฉพาะเฟรมเวิร์กที่มีข้อยกเว้น RS (FWK-ONLY-RS) :
-
libft2.so
(เรนเดอร์สคริปต์) -
libmediandk.so
(Renderscript)
การกำหนดเวอร์ชัน VNDK
ไลบรารีที่แบ่งใช้ VNDK มีเวอร์ชัน:
- คุณสมบัติระบบ
ro.vndk.version
จะถูกเพิ่มใน/vendor/default.prop
โดยอัตโนมัติ - ไลบรารีที่ใช้ร่วมกันของ VNDK และ VNDK-SP ได้รับการติดตั้งเป็น VNDK apex
com.android.vndk.v${ro.vndk.version}
และติดตั้งไว้ที่/apex/com.android.vndk.v${ro.vndk.version}
ค่าของ 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
)
ชุดทดสอบผู้ขาย (VTS)
ชุดทดสอบผู้จำหน่าย Android (VTS) กำหนดให้มีคุณสมบัติ ro.vndk.version
ที่ไม่ว่างเปล่า ทั้งอุปกรณ์ที่เพิ่งเปิดตัวและอุปกรณ์อัปเกรดจะต้องกำหนด ro.vndk.version
กรณีทดสอบ VNDK บางกรณี (เช่น VtsVndkFilesTest
และ VtsVndkDependencyTest
) อาศัยคุณสมบัติ ro.vndk.version
เพื่อโหลดชุดข้อมูลไลบรารี VNDK ที่มีสิทธิ์ที่ตรงกัน