ชุดพัฒนา Native ของผู้ขาย (VNDK)

Vendor Native Development Kit (VNDK) เป็นชุดของไลบรารีสำหรับผู้ขายโดยเฉพาะเพื่อนำ HAL ไปใช้ VNDK จัดส่งใน system.img และเชื่อมโยงกับรหัสผู้ขายแบบไดนามิกขณะรันไทม์

ทำไมต้อง VNDK?

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

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

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

เพื่อจัดการกับความท้าทายเหล่านี้ Android 8.0 ได้แนะนำเทคนิคต่างๆ เช่น VNDK (อธิบายไว้ในส่วนนี้), HIDL , hwbinder, การ ซ้อนทับ แผนผังอุปกรณ์ และการวางซ้อนที่แบ่งแยกดินแดน

ทรัพยากร VNDK

ส่วนนี้ประกอบด้วยทรัพยากร VNDK ต่อไปนี้:

  • แนวคิด VNDK (ด้านล่าง) อธิบายเฟรมเวิร์กไลบรารีที่แบ่งใช้ HAL กระบวนการเดียวกัน (SP-HAL) และคำศัพท์ VNDK
  • ส่วนขยาย VNDK จัดประเภทการเปลี่ยนแปลงเฉพาะผู้ขายออกเป็นหมวดหมู่ ตัวอย่างเช่น ไลบรารีที่มีฟังก์ชันเพิ่มเติมซึ่งโมดูลผู้ขายพึ่งพาจะต้องถูกคัดลอกลงในพาร์ติชันของผู้จัดจำหน่าย แต่ห้ามการเปลี่ยนแปลงที่เข้ากันไม่ได้ของ ABI
  • การสนับสนุนระบบบิลด์ VNDK อธิบายการกำหนดค่าระบบบิลด์และไวยากรณ์คำจำกัดความโมดูลที่เกี่ยวข้องกับ VNDK
  • เครื่องมือคำจำกัดความ VNDK ช่วยย้ายโครงสร้างต้นทางของคุณไปยัง Android 8.0 ขึ้นไป
  • Linker Namespace ให้การควบคุมแบบละเอียดสำหรับการเชื่อมโยงไลบรารีที่ใช้ร่วมกัน
  • ไดเรกทอรี กฎ และ การแยกตัวกำหนดโครงสร้างไดเรกทอรีสำหรับอุปกรณ์ที่ใช้ Android 8.0 ขึ้นไป กฎ VNDK และการแยกตัวออกจากกันที่เกี่ยวข้อง
  • การนำเสนอ VNDK Design แสดงให้เห็นแนวคิด VDNK พื้นฐานที่ใช้ใน Android 8.0 ขึ้นไป

แนวคิด VNDK

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

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

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

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

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

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

HAL กระบวนการเดียวกัน ( SP-HAL ) คือชุดของ HAL ที่กำหนดไว้ล่วงหน้าซึ่งนำไปใช้เป็น Vendor Shared Libraries และโหลดเข้าสู่ Framework Processes SP-HAL ถูกแยกโดยเนมสเปซของตัวเชื่อมโยง (ควบคุมไลบรารีและสัญลักษณ์ที่มองเห็นได้ในไลบรารีที่แบ่งใช้) SP-HAL ต้องขึ้นอยู่กับ LL-NDK และ VNDK-SP เท่านั้น

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

ห้องสมุดต่อไปนี้ได้รับการอนุมัติ 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 ระบุ vndk: { support_system_process: true } ในไฟล์ Android.bp หากมี vendor_available: false ไลบรารีเหล่านี้จะเรียกว่า VNDK-SP-Private และ SP -HALS จะไม่ปรากฏให้เห็น

ต่อไปนี้เป็น ไลบรารีเฉพาะเฟรมเวิร์กที่มีข้อยกเว้น RS (FWK-ONLY-RS) :

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

คำศัพท์ VNDK

  • โมดูล อ้างถึง Shared Libraries หรือ Executables
  • กระบวนการ คืองานของระบบปฏิบัติการที่เกิดจาก Executables
  • กรอบงาน -ข้อกำหนดที่ผ่านการรับรองหมายถึงแนวคิดที่เกี่ยวข้องกับพาร์ติชัน ระบบ
  • เงื่อนไขที่ผ่านการรับรองจาก ผู้จำหน่าย หมายถึงแนวคิดที่เกี่ยวข้องกับพาร์ติชันของ ผู้จัดจำหน่าย

ตัวอย่างเช่น:

  • Framework Executables อ้างถึง executables ใน /system/bin หรือ /system/xbin
  • Framework Shared Libraries อ้างถึงไลบรารีที่แบ่งใช้ภายใต้ /system/lib[64]
  • Framework Modules อ้างถึงทั้ง Framework Shared Libraries และ Framework Executables
  • Framework Processes เป็นกระบวนการที่เกิดจาก Framework Executables (เช่น /system/bin/app_process )
  • Vendor Executables หมายถึง executables ใน /vendor/bin
  • Vendor Shared Libraries อ้างถึงไลบรารีที่แชร์ภายใต้ /vendor/lib[64]
  • โมดูลผู้จำหน่าย อ้างถึงทั้ง Vendor Executables และ Vendor Shared Libraries
  • กระบวนการของผู้ขาย เป็นกระบวนการที่เกิดจาก Vendor Executables (เช่น
    • /vendor/bin/android.hardware.camera.provider@2.4-service )

การกำหนดเวอร์ชัน VNDK

ใน Android 9 ไลบรารีที่แชร์ VNDK มีเวอร์ชัน:

  • คุณสมบัติของระบบ ro.vndk.version จะถูกเพิ่มโดยอัตโนมัติใน /vendor/default.prop
  • ไลบรารีที่ใช้ร่วมกัน VNDK ได้รับการติดตั้งใน /system/lib[64]/vndk-${ro.vndk.version}
  • ไลบรารีที่ใช้ร่วมกัน VNDK-SP ได้รับการติดตั้งใน /system/lib[64]/vndk-sp-${ro.vndk.version}
  • ไฟล์คอนฟิกูเรชันตัวเชื่อมโยงแบบไดนามิกได้รับการติดตั้งใน /system/etc/ld.config.${ro.vndk.version}.txt

ค่าของ 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 )

อัพเกรดอุปกรณ์

หากอุปกรณ์ Android 8.x ปิดใช้งานการบังคับใช้รันไทม์ VNDK โดยสร้างขึ้นโดยไม่มี BOARD_VNDK_VERSION อาจเพิ่ม PRODUCT_USE_VNDK_OVERRIDE := false ไปยัง BoardConfig.mk ขณะอัปเกรดเป็น Android 9

ถ้า PRODUCT_USE_VNDK_OVERRIDE เป็น false คุณสมบัติ ro.vndk.lite จะถูกเพิ่มโดยอัตโนมัติใน /vendor/default.prop และค่าของมันจะเป็น true ดังนั้น ตัวเชื่อมโยงแบบไดนามิกจะโหลดการกำหนดค่าเนมสเปซตัวเชื่อมโยงจาก /system/etc/ld.config.vndk_lite.txt ซึ่งแยกเฉพาะ SP-HAL และ VNDK-SP

หากต้องการอัปเกรดอุปกรณ์ Android 7.0 หรือต่ำกว่าเป็น Android 9 ให้เพิ่ม PRODUCT_TREBLE_LINKER_NAMESPACES_OVERRIDE := false ไปยัง BoardConfig.mk

ชุดทดสอบผู้ขาย (VTS)

ชุดทดสอบผู้ขาย Android 9 (VTS) กำหนดให้ใช้คุณสมบัติ ro.vndk.version ที่ไม่ว่างเปล่า ทั้งอุปกรณ์ที่เพิ่งเปิดตัวและอุปกรณ์อัปเกรดต้องกำหนด ro.vndk.version กรณีทดสอบ VNDK บางกรณี (เช่น VtsVndkFilesTest และ VtsVndkDependencyTest ) อาศัยคุณสมบัติ ro.vndk.version เพื่อโหลดชุดข้อมูลไลบรารี VNDK ที่เข้าคู่กัน

หากคุณสมบัติ ro.product.first_api_level มากกว่า 27 จะต้องไม่กำหนดคุณสมบัติ ro.vndk.lite VtsTreblePlatformVersionTest จะล้มเหลวหากมีการกำหนด ro.vndk.lite ในอุปกรณ์ Android 9 ที่เพิ่งเปิดตัวใหม่

ประวัติเอกสาร

ส่วนนี้ติดตามการเปลี่ยนแปลงเอกสาร VNDK

Android 9 เปลี่ยนไป

  • เพิ่มส่วนการกำหนดเวอร์ชัน VNDK
  • เพิ่มส่วน VTS
  • มีการเปลี่ยนชื่อหมวดหมู่ VNDK บางประเภท:
    • LL-NDK-Indirect ถูกเปลี่ยนชื่อเป็น LL-NDK-Private
    • VNDK-ทางอ้อมถูกเปลี่ยนชื่อเป็น VNDK-Private
    • VNDK-SP-Indirect-Private ถูกเปลี่ยนชื่อเป็น VNDK-SP-Private
    • VNDK-SP-Indirect ถูกลบออก

การเปลี่ยนแปลงของ Android 8.1

  • รวมไลบรารี SP-NDK เข้ากับไลบรารี LL-NDK แล้ว
  • แทนที่ libui.so ด้วย libft2.so ในส่วนเนมสเปซ RS เกิดข้อผิดพลาดในการรวม libui.so
  • เพิ่ม libGLESv3.so และ libandroid_net.so ลงในไลบรารี LL-NDK
  • เพิ่ม libion.so ให้กับไลบรารี VNDK-SP
  • ลบ libstdc++.so ออกจากไลบรารี LL-NDK ใช้ libc++.so แทน Toolchains แบบสแตนด์อโลนบางเวอร์ชันอาจเพิ่ม -lstdc++ ไปยังแฟล็กตัวเชื่อมโยงเริ่มต้น หากต้องการปิดใช้งานค่าดีฟอลต์ ให้เพิ่ม -nodefaultlibs -lc -lm -ldl ลงใน LDFLAGS
  • ย้าย libz.so จากไลบรารี LL-NDK ไปยัง VNDK-SP ในการกำหนดค่าบางอย่าง libz.so อาจยังคงเป็น LL-NDK ต่อไป อย่างไรก็ตาม ไม่ควรมีความแตกต่างที่สังเกตได้