หน้านี้ได้รับการแปลโดย Cloud Translation API

ภาพรวมของ 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, การซ้อนทับแผนผังอุปกรณ์ และการซ้อนทับ sepolicy

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

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

โมดูล อ้างอิงถึงไลบรารีที่ใช้ร่วมกันหรือไฟล์เรียกทำงาน โมดูลสร้างการพึ่งพาเวลาในการสร้าง
กระบวนการ คืองานของระบบปฏิบัติการที่เกิดขึ้นจากไฟล์เรียกทำงาน กระบวนการสร้างการพึ่งพารันไทม์
กรอบ - คำที่มีคุณสมบัติเกี่ยวข้องกับพาร์ติชัน system :

ไฟล์เรียกทำงานของ Framework หมายถึงไฟล์เรียกทำงานใน /system/bin หรือ /system/xbin
ไลบรารีที่ใช้ร่วมกันของ Framework หมายถึงไลบรารีที่ใช้ร่วมกันภายใต้ /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 จัดการกับเฟรมเวิร์กไลบรารีที่ใช้ร่วมกันสำหรับผู้ขายและ Same-Process HAL (SP-HAL)

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

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

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

ทำไมต้อง VNDK?

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

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

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

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

โมดูล อ้างอิงถึงไลบรารีที่ใช้ร่วมกันหรือไฟล์เรียกทำงาน โมดูลสร้างการพึ่งพาเวลาในการสร้าง
กระบวนการ คืองานของระบบปฏิบัติการที่เกิดขึ้นจากไฟล์เรียกทำงาน กระบวนการสร้างการพึ่งพารันไทม์
กรอบ - คำที่มีคุณสมบัติเกี่ยวข้องกับพาร์ติชัน system :

ไฟล์เรียกทำงานของ Framework หมายถึงไฟล์เรียกทำงานใน /system/bin หรือ /system/xbin
ไลบรารีที่ใช้ร่วมกันของ Framework หมายถึงไลบรารีที่ใช้ร่วมกันภายใต้ /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

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

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

ห้องสมุดต่อไปนี้ได้รับการรับรอง 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

ต่อไปนี้คือ ไลบรารีเฟรมเวิร์กเท่านั้นที่มีข้อยกเว้นของ 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)

ทำไมต้อง VNDK?

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

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

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

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

โมดูล อ้างอิงถึงไลบรารีที่ใช้ร่วมกันหรือไฟล์เรียกทำงาน โมดูลสร้างการพึ่งพาเวลาในการสร้าง
กระบวนการ คืองานของระบบปฏิบัติการที่เกิดขึ้นจากไฟล์เรียกทำงาน กระบวนการสร้างการพึ่งพารันไทม์
กรอบ - คำที่มีคุณสมบัติเกี่ยวข้องกับพาร์ติชัน system :

ไฟล์เรียกทำงานของ Framework หมายถึงไฟล์เรียกทำงานใน /system/bin หรือ /system/xbin
ไลบรารีที่ใช้ร่วมกันของ Framework หมายถึงไลบรารีที่ใช้ร่วมกันภายใต้ /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

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

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

ห้องสมุดต่อไปนี้ได้รับการรับรอง 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

ต่อไปนี้คือ ไลบรารีเฟรมเวิร์กเท่านั้นที่มีข้อยกเว้นของ 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)

ทำไมต้อง VNDK?

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

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

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

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

โมดูล อ้างอิงถึงไลบรารีที่ใช้ร่วมกันหรือไฟล์เรียกทำงาน โมดูลสร้างการพึ่งพาเวลาในการสร้าง
กระบวนการ คืองานของระบบปฏิบัติการที่เกิดขึ้นจากไฟล์เรียกทำงาน กระบวนการสร้างการพึ่งพารันไทม์
กรอบ - คำที่มีคุณสมบัติเกี่ยวข้องกับพาร์ติชัน system :

ไฟล์เรียกทำงานของ Framework หมายถึงไฟล์เรียกทำงานใน /system/bin หรือ /system/xbin
ไลบรารีที่ใช้ร่วมกันของ Framework หมายถึงไลบรารีที่ใช้ร่วมกันภายใต้ /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

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

ทำให้ ABIs/API ของเฟรมเวิร์กแชร์ไลบรารีเสถียร โมดูลเฟรมเวิร์กใหม่และโมดูลผู้ขายเก่าสามารถใช้ไลบรารีที่ใช้ร่วมกันเดียวกันเพื่อลดรอยเท้าของหน่วยความจำและขนาดพื้นที่จัดเก็บ ไลบรารีที่ใช้ร่วมกันที่ไม่ซ้ำใครยังช่วยหลีกเลี่ยงปัญหาการโหลดซ้ำหลายครั้งอีกด้วย อย่างไรก็ตาม ค่าใช้จ่ายในการพัฒนาเพื่อรักษา ABI/API ให้เสถียรนั้นสูง และไม่สมจริงที่จะทำให้ ABI/API ทั้งหมดที่ส่งออกโดยไลบรารีที่ใช้ร่วมกันทุกเฟรมเวิร์กนั้นไม่สมจริง
คัดลอกไลบรารีที่ใช้ร่วมกันของเฟรมเวิร์กเก่า มาพร้อมกับข้อจำกัดที่เข้มงวดสำหรับช่องทางด้านข้าง ซึ่งกำหนดเป็นกลไกทั้งหมดในการสื่อสารระหว่างโมดูลเฟรมเวิร์กและโมดูลผู้ขาย รวมถึง (แต่ไม่จำกัดเพียง) ตัวประสาน ซ็อกเก็ต ท่อ หน่วยความจำที่ใช้ร่วมกัน ไฟล์ที่ใช้ร่วมกัน และคุณสมบัติของระบบ จะต้องไม่มีการสื่อสารเว้นแต่ว่าโปรโตคอลการสื่อสารจะถูกหยุดและเสถียร (เช่น 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 สามารถเชื่อมโยงกับสำเนาของตนเองได้ A framework shared library can become an eligible VNDK library only if it satisfies the following criteria:
- It does not send/receive IPCs to/from the framework.
- It is not related to ART virtual machine.
- It does not read/write files/partitions with unstable file formats.
- It does not have special software license which requires legal reviews.
- Its code owner does not have objections to vendor usages.
Framework-Only Libraries (FWK-ONLY) are Framework Shared Libraries that do not belong to the categories mentioned above. These libraries:
- Are considered framework internal implementation details.
- Must not be accessed by vendor modules.
- Have unstable ABIs/APIs and no API/ABI compatibility guarantees.
- Are not copied.

Same-Process HAL (SP-HAL)

Same-Process HAL ( SP-HAL ) is a set of predetermined HALs implemented as Vendor Shared Libraries and loaded into Framework Processes . SP-HALs are isolated by a linker namespace (controls the libraries and symbols that are visible to the shared libraries). SP-HALs must depend only on LL-NDK and VNDK-SP .

VNDK-SP is a predefined subset of eligible VNDK libraries. VNDK-SP libraries are carefully reviewed to ensure double-loading VNDK-SP libraries into framework processes does not cause problems. Both SP-HALs and VNDK-SPs are defined by Google.

The following libraries are approved 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 libraries specify vndk: { support_system_process: true } in their Android.bp files. If vndk: {private:true} is also specified, then these libraries are called VNDK-SP-Private and they are invisible to SP-HALS.

The following are framework-only libraries with RS exceptions (FWK-ONLY-RS) :

libft2.so (Renderscript)
libmediandk.so (Renderscript)

VNDK versioning

VNDK shared libraries are versioned:

The ro.vndk.version system property is automatically added to /vendor/default.prop .
VNDK and VNDK-SP shared libraries are installed as a VNDK apex com.android.vndk.v${ro.vndk.version} and mounted to /apex/com.android.vndk.v${ro.vndk.version} .

The value of ro.vndk.version is chosen by the algorithm below:

If BOARD_VNDK_VERSION is not equal to current , use BOARD_VNDK_VERSION .
If BOARD_VNDK_VERSION is equal to current :

If PLATFORM_VERSION_CODENAME is REL , use PLATFORM_SDK_VERSION (eg 28 ).
Otherwise, use PLATFORM_VERSION_CODENAME (eg P ).

Vendor Test Suite (VTS)

The Android Vendor Test Suite (VTS) mandates a non-empty ro.vndk.version property. Both newly-launched devices and upgrading devices must define ro.vndk.version . Some VNDK test cases (eg VtsVndkFilesTest and VtsVndkDependencyTest ) rely on the ro.vndk.version property to load the matching eligible VNDK libraries data sets.