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

ชุดพัฒนาซอฟต์แวร์แบบเนทีฟสำหรับผู้ให้บริการ (VNDK) คือชุดไลบรารีที่ไลบรารีอื่นๆ หรือไบนารีใช้ในพาร์ติชันของผู้ให้บริการหรือผลิตภัณฑ์ในรันไทม์สำหรับ dlopen

การเลิกใช้งาน

เราได้เปิดตัว NDK ของผู้ให้บริการใน Android 8.0 เพื่อจัดหา API ระหว่าง เฟรมเวิร์กและโค้ดของผู้ให้บริการ แม้ว่า VNDK จะใช้งานได้ดีมาหลายปี แต่ก็มีข้อเสียบางประการ ดังนี้

• พื้นที่เก็บข้อมูล
• แพ็กเกจ VNDK APEX เดียวจะรวมไลบรารี VNDK ทั้งหมด ไม่ว่าจะใช้จากอุปกรณ์หรือไม่ก็ตาม
• GSI มี VNDK APEX หลายเวอร์ชันเพื่อรองรับอิมเมจของผู้ให้บริการหลายเวอร์ชัน
• ความสามารถในการอัปเดต
• การอัปเดต VNDK APEX แยกจากการอัปเดตแพลตฟอร์มเป็นเรื่องยาก
• รูปภาพของผู้ให้บริการจะได้รับการอัปเดตผ่านอากาศ (OTA) บ่อยครั้ง ซึ่งจะลดประโยชน์ของการแพ็กเกจ VNDK ภายในอิมเมจของระบบ

จากปัญหาเหล่านี้ เราจึงตัดสินใจเลิกใช้งาน VNDK โดยเริ่มตั้งแต่ Android 15

รายละเอียดเกี่ยวกับการเลิกใช้งาน VNDK

ระบบจะแพ็กเกจไลบรารี VNDK ทั้งหมดลงใน VNDK APEX และติดตั้งในอิมเมจระบบ (-ext) เมื่อเลิกใช้งาน VNDK ระบบจะติดตั้งไลบรารี VNDK เดิมในอิมเมจของผู้ให้บริการ (หรือผลิตภัณฑ์) เช่นเดียวกับไลบรารีอื่นๆ ที่ผู้ให้บริการมีให้ เราจะนำฟีเจอร์เหล่านี้ออกพร้อมกับการเลิกใช้งาน VNDK

• VNDK APEX สำหรับ Android 15
• ระบบจะนำพร็อพเพอร์ตี้ของระบบที่ระบุเวอร์ชันของ VNDK เป้าหมายออกหากมีการสร้างพาร์ติชันของผู้ให้บริการหรือผลิตภัณฑ์สำหรับ Android 15
  • ro.vndk.version
  • ro.product.vndk.version
• การเพิ่มประสิทธิภาพ VNDK จะไม่พร้อมใช้งานเนื่องจากไม่มี VNDK:
  • TARGET_VNDK_USING_CORE_VARIANT สำหรับอุปกรณ์ Android Go
  • use_vndk_as_stable สำหรับ APEX ของผู้ให้บริการ
• ภาพรวมของผู้ให้บริการซึ่งขึ้นอยู่กับ VNDK เป็นอย่างมาก

ข้อยกเว้นจากการเลิกใช้งาน

ฟีเจอร์ต่อไปนี้จะไม่เปลี่ยนแปลงเมื่อเลิกใช้งาน VNDK

• APEX VNDK ที่มี VNDK เวอร์ชัน 14 หรือต่ำกว่า ซึ่งจำเป็นต่อการรองรับอิมเมจของผู้ให้บริการที่มีอยู่
• LL-NDK ไม่ได้เป็นส่วนหนึ่งของ VNDK

ทำไมต้อง VNDK

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

การอัปเดตเฉพาะเฟรมเวิร์กมีข้อจำกัดต่อไปนี้

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

Android มีฟีเจอร์หลายอย่างเพื่อรับมือกับความท้าทายเหล่านี้ เช่น VNDK (อธิบายไว้ในส่วนนี้), HIDL, hwbinder, device tree overlay และ sepolicy overlay

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

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

• โมดูลหมายถึงไลบรารีที่ใช้ร่วมกันหรือไฟล์ที่เรียกใช้งานได้ โมดูลทำให้เกิดการอ้างอิงในเวลาบิลด์
• กระบวนการคืองานของระบบปฏิบัติการที่สร้างขึ้นจากไฟล์ที่เรียกใช้งานได้ กระบวนการทำให้เกิดการขึ้นต่อกันที่รันไทม์
• คำที่ผ่านการรับรองเฟรมเวิร์กเกี่ยวข้องกับพาร์ติชัน system ดังนี้
• ไฟล์ที่เรียกใช้งานได้ของเฟรมเวิร์กหมายถึงไฟล์ที่เรียกใช้งานได้ใน /system/bin หรือ /system/xbin
• ไลบรารีที่ใช้ร่วมกันของเฟรมเวิร์กหมายถึงไลบรารีที่ใช้ร่วมกันใน /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 และ Hardware Binder

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

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

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

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

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

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

HAL ในกระบวนการเดียวกัน (SP-HAL) คือชุด HAL ที่กำหนดไว้ล่วงหน้า ซึ่งใช้เป็นไลบรารีที่แชร์ของผู้ให้บริการและโหลดลงในกระบวนการ เฟรมเวิร์ก 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-HAL

ไลบรารีที่ใช้เฟรมเวิร์กเท่านั้นที่มีข้อยกเว้น 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 (VTS) กำหนดให้มีพร็อพเพอร์ตี้ ro.vndk.version ที่ไม่ว่างเปล่า ทั้งอุปกรณ์ที่เพิ่งเปิดตัว และอุปกรณ์ที่อัปเกรดต้องกำหนด ro.vndk.version กรณีทดสอบ VNDK บางรายการ (เช่น VtsVndkFilesTest และ VtsVndkDependencyTest) อาศัยพร็อพเพอร์ตี้ ro.vndk.version เพื่อโหลดชุดข้อมูลไลบรารี VNDK ที่มีสิทธิ์ซึ่งตรงกัน