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