ภาพรวมชุดพัฒนาซอฟต์แวร์แบบเนทีฟสำหรับผู้ให้บริการ (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

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

เหตุผลที่ควรใช้ VNDK

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

การอัปเดตเฟรมเวิร์กเท่านั้นจะพบปัญหาต่อไปนี้

• การพึ่งพาระหว่างโมดูลเฟรมเวิร์กกับโมดูลของผู้ให้บริการ ก่อน Android 8.0 โมดูลในพาร์ติชันระบบและพาร์ติชันของผู้ให้บริการจะลิงก์กันได้ อย่างไรก็ตาม โมดูลของผู้ให้บริการจะทำให้เกิดข้อจำกัดที่ไม่พึงประสงค์ในการพัฒนาโมดูลเฟรมเวิร์ก
• ส่วนขยายสำหรับไลบรารี AOSP Android กำหนดให้อุปกรณ์ Android ทั้งหมดต้องผ่าน CTS เมื่อมีการแทนที่พาร์ติชันระบบด้วยอิมเมจระบบทั่วไป (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/bin/android.hardware.camera.provider@2.4-service

แนวคิดของ VNDK

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

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

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

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

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

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

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

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