ภาพรวมของ Vendor Native Development Kit (VNDK)

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, การ วางโครงสร้างอุปกรณ์ และการวางซ้อนที่แบ่งแยกดินแดน

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

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

แนวคิด VNDK

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

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

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

กรอบงานไลบรารีที่ใช้ร่วมกันสำหรับผู้จำหน่าย

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

  1. ทำให้ ABIs/API ของเฟรมเวิร์กไลบรารีที่แบ่งใช้มีเสถียรภาพ โมดูลเฟรมเวิร์กใหม่และโมดูลผู้ขายเก่าสามารถใช้ไลบรารีที่ใช้ร่วมกันเดียวกันเพื่อลดพื้นที่หน่วยความจำและขนาดหน่วยเก็บข้อมูล ไลบรารีที่ใช้ร่วมกันที่ไม่ซ้ำกันยังช่วยหลีกเลี่ยงปัญหาการโหลดซ้ำหลายครั้งอีกด้วย อย่างไรก็ตาม ต้นทุนในการพัฒนาเพื่อรักษา ABI/API ให้เสถียรนั้นสูง และทำให้ ABI/APIs เสถียรทั้งหมดที่ส่งออกโดยไลบรารีที่ใช้ร่วมกันของเฟรมเวิร์กทุกอันนั้นไม่สมเหตุสมผล
  2. คัดลอกไลบรารีที่ใช้ร่วมกันของเฟรมเวิร์กเก่า มาพร้อมกับข้อจำกัดที่แข็งแกร่งสำหรับช่องสัญญาณด้านข้าง ซึ่งกำหนดเป็นกลไกทั้งหมดในการสื่อสารระหว่างโมดูลเฟรมเวิร์กและโมดูลผู้ขาย ซึ่งรวมถึง (แต่ไม่จำกัดเพียง) ตัวประสาน ซ็อกเก็ต ไพพ์ หน่วยความจำที่ใช้ร่วมกัน ไฟล์ที่ใช้ร่วมกัน และคุณสมบัติของระบบ ต้องไม่มีการสื่อสารเว้นแต่โปรโตคอลการสื่อสารจะถูกระงับและเสถียร (เช่น 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
  • ไลบรารี VNDK ที่มีสิทธิ์ (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 (Renderscript)
  • 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 Vendor Test Suite (VTS) กำหนดให้ใช้คุณสมบัติ ro.vndk.version ที่ไม่ว่างเปล่า ทั้งอุปกรณ์ที่เพิ่งเปิดตัวและอุปกรณ์อัปเกรดต้องกำหนด ro.vndk.version กรณีทดสอบ VNDK บางกรณี (เช่น VtsVndkFilesTest และ VtsVndkDependencyTest ) อาศัยคุณสมบัติ ro.vndk.version เพื่อโหลดชุดข้อมูลไลบรารี VNDK ที่เข้าคู่กัน