ภาพรวมชุดพัฒนาซอฟต์แวร์แบบเนทีฟ (VNDK) สำหรับผู้ให้บริการ

Vendor Native Development Kit (VNDK) เป็นชุดไลบรารีที่ไลบรารีอื่นๆ ใช้ หรือไบนารีในผู้ให้บริการหรือพาร์ติชันผลิตภัณฑ์ ในรันไทม์สำหรับ dlopen

เหตุใดจึงควรใช้ VNDK

AOSP อนุญาตการอัปเดตเฉพาะเฟรมเวิร์กเท่านั้นที่สามารถอัปเกรดพาร์ติชันระบบเป็นเวอร์ชันล่าสุดได้ เวอร์ชันเฟรมเวิร์กขณะพาร์ติชันผู้ให้บริการไม่เปลี่ยนแปลง แม้จะสร้างขึ้นที่สถานที่อื่น ไบนารีในแต่ละพาร์ติชันต้องทำงานร่วมกันได้

การอัปเดตที่ใช้เฉพาะเฟรมเวิร์กเท่านั้นจะรวมถึงความท้าทายต่อไปนี้

• ความพึ่งพิงระหว่างโมดูลเฟรมเวิร์กและโมดูลของผู้ให้บริการ ก่อน Android 8.0 โมดูลในพาร์ติชันผู้ให้บริการและพาร์ติชันระบบสามารถลิงก์ได้ ระหว่างกัน อย่างไรก็ตาม ทรัพยากร Dependency จากโมดูลของผู้ให้บริการไม่ได้รับการกำหนด ข้อจำกัดในการพัฒนาโมดูลเฟรมเวิร์ก
• ส่วนขยายไปยังไลบรารี AOSP แอนดรอยด์ กำหนดให้อุปกรณ์ Android ทั้งหมดส่ง CTS เมื่อแทนที่พาร์ติชันระบบ ที่มีอิมเมจระบบทั่วไป (GSI) มาตรฐาน แต่เมื่อผู้ให้บริการขยาย AOSP เพื่อเพิ่มประสิทธิภาพหรือเพิ่มฟังก์ชันพิเศษสำหรับ HIDL การเปลี่ยนพาร์ติชันระบบด้วย GSI มาตรฐาน อาจทำให้การใช้งาน HIDL ของผู้ให้บริการขัดข้อง สำหรับหลักเกณฑ์เกี่ยวกับ การป้องกันความเสียหายดังกล่าว โปรดดู ส่วนขยาย VNDK

ในการรับมือกับความท้าทายเหล่านี้ Android จึงมีฟีเจอร์ต่างๆ มากมาย เช่น เป็น VNDK (อธิบายไว้ในส่วนนี้) HIDL, hwbinder, การวางซ้อนแผนผังอุปกรณ์ และ การวางซ้อน Sepolicy

ข้อกำหนดเฉพาะ VNDK

เอกสารที่เกี่ยวข้องกับ VNDK ใช้คำศัพท์ต่อไปนี้

• โมดูลหมายถึงไลบรารีที่ใช้ร่วมกันหรือไฟล์ปฏิบัติการ โมดูลสร้างเวลาบิลด์ ทรัพยากร Dependency
• กระบวนการคืองานของระบบปฏิบัติการที่สร้างจากไฟล์ปฏิบัติการ กระบวนการต่างๆ ทำให้รันไทม์ ทรัพยากร Dependency
• คำที่ตรงตามข้อกำหนดของ Framework เกี่ยวข้องกับพาร์ติชัน system:
• ไฟล์ปฏิบัติการของเฟรมเวิร์กหมายถึงไฟล์ปฏิบัติการใน /system/bin หรือ /system/xbin
• ไลบรารีที่ใช้ร่วมกันของเฟรมเวิร์กหมายถึงไลบรารีที่ใช้ร่วมกันภายใต้ /system/lib[64]
• โมดูลเฟรมเวิร์กหมายถึงไลบรารีที่ใช้ร่วมกันของเฟรมเวิร์กทั้ง 2 แบบ และไฟล์ปฏิบัติการของเฟรมเวิร์ก
• กระบวนการในเฟรมเวิร์กคือกระบวนการที่เกิดจากเฟรมเวิร์ก ไฟล์ปฏิบัติการ เช่น /system/bin/app_process
• คำศัพท์ที่เข้าเกณฑ์ของผู้ให้บริการเกี่ยวข้องกับพาร์ติชัน vendor ดังต่อไปนี้
• ไฟล์ปฏิบัติการของผู้ให้บริการหมายถึงไฟล์ปฏิบัติการใน /vendor/bin
• ไลบรารีที่ใช้ร่วมกันของผู้ให้บริการ หมายถึงไลบรารีที่ใช้ร่วมกันภายใต้ /vendor/lib[64]
• โมดูลของผู้ให้บริการหมายถึงทั้งไฟล์ปฏิบัติการของผู้ให้บริการและไลบรารีที่ใช้ร่วมกันของผู้ให้บริการ
• กระบวนการของผู้ให้บริการ คือกระบวนการที่เกิดจากผู้ให้บริการ ไฟล์ดำเนินการ เช่น /vendor/bin/android.hardware.camera.provider@2.4-service

แนวคิด VNDK

สำหรับ Android 8.0 ขึ้นไปในอุดมคติ กระบวนการของเฟรมเวิร์กจะไม่โหลดขึ้นมา ไลบรารีที่ใช้ร่วมกันของผู้ให้บริการ กระบวนการของผู้ให้บริการทั้งหมดจะโหลดเฉพาะไลบรารีที่ใช้ร่วมกันของผู้ให้บริการ (และส่วนหนึ่งของไลบรารีที่แชร์ร่วมกัน) และการสื่อสารระหว่าง กระบวนการของเฟรมเวิร์กและกระบวนการของผู้ให้บริการได้รับการควบคุมโดย HIDL และฮาร์ดแวร์ Binder

โลกดังกล่าวยังรวมถึง API สาธารณะที่เสถียรจาก ไลบรารีที่ใช้ร่วมกันของเฟรมเวิร์กอาจไม่เพียงพอสำหรับนักพัฒนาโมดูลของผู้ให้บริการ (แต่ API สามารถเปลี่ยนไปมาระหว่าง Android รุ่นต่างๆ ได้) จึงจำเป็นต้องให้บางส่วน ของไลบรารีที่ใช้ร่วมกันของเฟรมเวิร์กสามารถเข้าถึงได้โดยกระบวนการของผู้ให้บริการ นอกจากนี้ ข้อกำหนดด้านประสิทธิภาพอาจทำให้เกิดความเสี่ยง บางส่วนต้องมีเวลาในการตอบกลับมาก HAL ต้องได้รับการปฏิบัติที่ต่างออกไป

ส่วนต่อไปนี้แสดงรายละเอียดเกี่ยวกับวิธีที่ VNDK จัดการไลบรารีที่ใช้ร่วมกันของเฟรมเวิร์กสำหรับ ผู้ให้บริการและ HAL กระบวนการเดียวกัน (SP-HAL)

เฟรมเวิร์กไลบรารีที่ใช้ร่วมกันสำหรับผู้ให้บริการ

ส่วนนี้จะอธิบายเกณฑ์ในการแยกประเภทไลบรารีที่ใช้ร่วมกันที่ เข้าถึงกระบวนการของผู้ให้บริการได้ การสนับสนุนผู้ให้บริการมี 2 วิธี ใน Android หลายรุ่นดังนี้

1. ปรับ ABI/API ของไลบรารีที่ใช้ร่วมกันในเฟรมเวิร์กให้เสถียร โมดูลเฟรมเวิร์กใหม่และโมดูลของผู้ให้บริการเดิมสามารถใช้ไลบรารีที่ใช้ร่วมกันเดียวกันได้เพื่อ ลดรอยเท้าและขนาดของพื้นที่เก็บข้อมูล ไลบรารีที่ใช้ร่วมกันที่ไม่ซ้ำกันยังหลีกเลี่ยง ปัญหาในการโหลดซ้ำซ้อนหลายอย่าง แต่มีค่าใช้จ่ายในการพัฒนาเพื่อให้มีความคงที่ ABI/API มีราคาสูงและไม่สมเหตุสมผลในการรักษาภาพให้คงที่ ABI/API ที่ส่งออกโดย ไลบรารีที่ใช้ร่วมกันของเฟรมเวิร์กทั้งหมด
2. คัดลอกไลบรารีที่ใช้ร่วมกันของเฟรมเวิร์กเก่า มาพร้อมกับฟีเจอร์ การจำกัดช่องด้านข้าง คือกลไกทั้งหมดในการสื่อสาร ในโมดูลเฟรมเวิร์กและโมดูลผู้ให้บริการ ซึ่งรวมถึง (แต่ไม่จำกัดเพียง) Binder, Socket, pipe, หน่วยความจำที่ใช้ร่วมกัน, ไฟล์ที่แชร์ และคุณสมบัติของระบบ มี ต้องไม่มีการสื่อสาร เว้นแต่โปรโตคอลการสื่อสารจะหยุดทำงานและมีความเสถียร (เช่น HIDL ผ่าน hwbinder) การโหลดไลบรารีที่ใช้ร่วมกันซ้ำอาจทำให้ เช่นกัน ตัวอย่างเช่น หากออบเจ็กต์ที่สร้างโดยไลบรารีใหม่มีการส่งผ่าน เข้ากับฟังก์ชันจากไลบรารีเก่า อาจมีข้อผิดพลาดเกิดขึ้นเนื่องจากไลบรารีเหล่านี้ อาจตีความออบเจ็กต์แตกต่างออกไป

มีการใช้แนวทางที่แตกต่างกันโดยขึ้นอยู่กับลักษณะเฉพาะของผู้ที่แชร์ ห้องสมุด ด้วยเหตุนี้ ไลบรารีที่ใช้ร่วมกันของเฟรมเวิร์กจึงแบ่งออกเป็น 3 ประเภท หมวดหมู่ย่อย:

• ไลบรารี LL-NDK คือไลบรารีที่ใช้ร่วมกันของเฟรมเวิร์ก ที่เสถียรแล้ว นักพัฒนาซอฟต์แวร์ของพวกเขามุ่งมั่นที่จะรักษา ความเสถียรของ 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
• ไลบรารี VNDK ที่มีสิทธิ์ (VNDK) เป็นเฟรมเวิร์กที่แชร์ร่วมกัน ไลบรารีที่สามารถคัดลอก 2 ครั้งได้อย่างปลอดภัย โมดูลเฟรมเวิร์ก และ ข้อบังคับของผู้ให้บริการสามารถลิงก์กับสำเนาของตนเอง เฟรมเวิร์กที่แชร์ ไลบรารีดังกล่าวจะกลายเป็นไลบรารี VNDK ที่มีสิทธิ์ก็ต่อเมื่อเป็นไปตามเงื่อนไขต่อไปนี้ เกณฑ์:
  • แต่จะไม่ส่ง/รับ IPC ไปยัง/จากเฟรมเวิร์ก
  • โดยไม่เกี่ยวข้องกับเครื่องเสมือน ART
  • แต่จะไม่อ่าน/เขียนไฟล์/พาร์ติชันที่มีรูปแบบไฟล์ที่ไม่เสถียร
  • แอปไม่มีใบอนุญาตพิเศษของซอฟต์แวร์ซึ่งต้องมีการตรวจสอบทางกฎหมาย
  • เจ้าของโค้ดไม่คัดค้านการใช้งานของผู้ให้บริการ
• Framework-Only Libraries (FWK-ONLY) คือ Framework Shared ไลบรารีที่ไม่อยู่ในหมวดหมู่ที่กล่าวถึงข้างต้น เหล่านี้ ไลบรารี:
  • ถือเป็นรายละเอียดการใช้งานภายในของเฟรมเวิร์ก
  • ต้องไม่เข้าถึงโดยโมดูลผู้ให้บริการ
  • มี ABI/API ที่ไม่เสถียรและไม่มีการรับประกันความเข้ากันได้กับ API/ABI
  • ไม่คัดลอก

HAL กระบวนการเดียวกัน (SP-HAL)

Same-Process HAL (SP-HAL) คือชุด HAL ที่กำหนดไว้ล่วงหน้า มีการใช้งานเป็นไลบรารีที่ใช้ร่วมกันของผู้ให้บริการ และโหลดลงใน Framework กระบวนการ SP-HAL จะถูกแยกออกโดยเนมสเปซ Linker (ควบคุมพารามิเตอร์ ไลบรารีและสัญลักษณ์ที่สามารถมองเห็นได้ในไลบรารีที่ใช้ร่วมกัน) SP-HAL ต้อง ขึ้นอยู่กับ LL-NDK และ VNDK-SP เท่านั้น

VNDK-SP เป็นชุดย่อยของไลบรารี VNDK ที่มีสิทธิ์ซึ่งกำหนดไว้ล่วงหน้า ไลบรารี VNDK-SP ได้รับการตรวจสอบอย่างละเอียดเพื่อให้แน่ใจว่ามีการโหลดไลบรารี VNDK-SP ซ้ำไว้ในเฟรมเวิร์ก กระบวนการต่างๆ ไม่ก่อให้เกิดปัญหา ทั้ง SP-HAL และ VNDK-SP จะกำหนดตาม Google

ไลบรารีต่อไปนี้คือ SP-HAL ที่ได้รับอนุมัติ

• 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 (ตัวแสดงผล)

การกำหนดเวอร์ชัน VNDK

ไลบรารีที่ใช้ร่วมกันของ VNDK มีการกำหนดเวอร์ชันดังนี้

• ระบบจะเพิ่มพร็อพเพอร์ตี้ระบบ ro.vndk.version ลงใน /vendor/default.prop
• ไลบรารีที่ใช้ร่วมกันของ VNDK และ VNDK-SP ได้รับการติดตั้งเป็นเอเพ็กซ์ VNDK 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 Vendor Test Suite (VTS) มีข้อบังคับ พร็อพเพอร์ตี้ ro.vndk.version ที่ไม่ว่างเปล่า อุปกรณ์ทั้ง 2 รุ่นที่เพิ่งเปิดตัวใหม่ และอุปกรณ์ที่อัปเกรดต้องกำหนด ro.vndk.version การทดสอบ VNDK บางส่วน กรณี (เช่น VtsVndkFilesTest และ VtsVndkDependencyTest) ที่ใช้ro.vndk.version เพื่อโหลดชุดข้อมูลไลบรารี VNDK ที่มีสิทธิ์ที่ตรงกัน