ภาพรวมของ 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, 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 หลายรุ่น:

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

,

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 หลายรุ่น:

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