ภาพรวมชุดพัฒนาซอฟต์แวร์แบบเนทีฟ (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, การวางซ้อนบนต้นไม้อุปกรณ์ และการวางซ้อน sepolicy

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

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