ผู้จำหน่ายAPEX

คุณสามารถใช้ รูปแบบไฟล์ APEX เพื่อจัดทำแพ็กเกจและติดตั้งโมดูลระบบปฏิบัติการ Android ระดับล่างได้ ช่วยให้สามารถสร้างและติดตั้งส่วนประกอบได้อย่างอิสระ เช่น บริการและไลบรารีแบบเนทีฟ การใช้งาน HAL เฟิร์มแวร์ ไฟล์กำหนดค่า ฯลฯ

APEX ของผู้จำหน่ายได้รับการติดตั้งโดยระบบ build โดยอัตโนมัติในพาร์ติชัน /vendor และเปิดใช้งานเมื่อรันไทม์โดย apexd เช่นเดียวกับ APEX ในพาร์ติชันอื่น

กรณีการใช้งาน

การทำให้เป็นโมดูลของอิมเมจของผู้ขาย

APEX อำนวยความสะดวกในการรวมกลุ่มและการทำให้เป็นโมดูลของการใช้งานฟีเจอร์บนอิมเมจของผู้จำหน่ายอย่างเป็นธรรมชาติ

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

ตัวอย่างเช่น OEM อาจเลือกที่จะเขียนอุปกรณ์ของตนด้วยการใช้ APEX ของ AOSP wifi, การใช้ SoC บลูทูธ APEX และ APEX ของการใช้โทรศัพท์ OEM แบบกำหนดเอง

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

การทำซ้ำของนักพัฒนา

APEX ของผู้จำหน่ายช่วยให้นักพัฒนาทำซ้ำได้เร็วขึ้นในขณะที่พัฒนาโมดูลของผู้จำหน่ายโดยการรวมการใช้งานฟีเจอร์ทั้งหมด เช่น wifi HAL ภายใน APEX ของผู้จำหน่าย นักพัฒนาสามารถสร้างและผลักดันผู้จำหน่าย APEX ทีละรายเพื่อทดสอบการเปลี่ยนแปลง แทนที่จะสร้างอิมเมจของผู้จำหน่ายใหม่ทั้งหมด

สิ่งนี้จะช่วยลดความยุ่งยากและเพิ่มความเร็วรอบการวนซ้ำของนักพัฒนาสำหรับนักพัฒนาที่ทำงานในส่วนฟีเจอร์เดียวเป็นหลักและต้องการวนซ้ำเฉพาะส่วนฟีเจอร์นั้น

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

การรวมพื้นที่คุณลักษณะไว้ใน APEX ยังช่วยลดความยุ่งยากในการดีบักหรือการเปลี่ยนกลับเมื่อสังเกตเห็นพฤติกรรมของอุปกรณ์ที่ไม่ดี ตัวอย่างเช่น หากระบบโทรศัพท์ทำงานได้ไม่ดีในบิลด์ใหม่ นักพัฒนาอาจลองติดตั้ง APEX สำหรับการใช้งานระบบโทรศัพท์รุ่นเก่าบนอุปกรณ์ (โดยไม่จำเป็นต้องแฟลชบิลด์เต็ม) และดูว่าลักษณะการทำงานที่ดีได้รับการกู้คืนหรือไม่

ขั้นตอนการทำงานตัวอย่าง:

# Build the entire device and flash. OR, obtain an already-flashed device.
source build/envsetup.sh && lunch oem_device-userdebug
m
fastboot flashall -w

# Test the device.
... testing ...

# Check previous behavior using a vendor APEX from one week ago, downloaded from
# your continuous integration build.
... download command ...
adb install <path to downloaded APEX>
adb reboot
... testing ...

# Edit and rebuild just the APEX to change and test behavior.
... edit APEX source contents ...
m <apex module name>
adb install out/<path to built APEX>
adb reboot
... testing ...

ตัวอย่าง

พื้นฐาน

ดูหน้า รูปแบบไฟล์ APEX หลักสำหรับข้อมูล APEX ทั่วไป รวมถึงข้อกำหนดของอุปกรณ์ รายละเอียดรูปแบบไฟล์ และขั้นตอนการติดตั้ง

ใน Android.bp การตั้งค่า vendor: true property ทำให้โมดูล APEX เป็นผู้จำหน่าย APEX

apex {
  ..
  vendor: true,
  ..
}

ไบนารีและไลบรารีที่แบ่งใช้

APEX มีการขึ้นต่อกันแบบสกรรมกริยาภายในเพย์โหลดของ APEX เว้นแต่ว่าจะมีอินเทอร์เฟซที่เสถียร

อินเทอร์เฟซดั้งเดิมที่เสถียรสำหรับการพึ่งพา APEX ของผู้ขาย ได้แก่ cc_library พร้อม stubs , ndk_library หรือ llndk_library การขึ้นต่อกันเหล่านี้ไม่รวมอยู่ในแพ็กเกจ และการขึ้นต่อกันจะถูกบันทึกไว้ในรายการ APEX รายการได้รับการประมวลผลโดย linkerconfig เพื่อให้การพึ่งพาเนทีฟภายนอกพร้อมใช้งานในขณะรันไทม์

ต่างจาก APEX ในพาร์ติชัน /system โดยทั่วไป APEX ของผู้จำหน่ายจะเชื่อมโยงกับเวอร์ชัน VNDK ที่ระบุ ไลบรารี VNDK รับประกันความเสถียรของ ABI ภายในรีลีส ดังนั้นเราจึงสามารถถือว่าไลบรารี VNDK มีความเสถียรและลดขนาดของ APEX ของผู้จำหน่ายโดยการแยกไลบรารีเหล่านั้นออกจาก APEX โดยใช้คุณสมบัติ use_vndk_as_stable

ในตัวอย่างด้านล่าง APEX จะมีทั้งไบนารี ( my_service ) และการขึ้นต่อกันที่ไม่เสถียร ( ไฟล์ *.so ) จะไม่มีไลบรารี VNDK แม้ว่า my_service จะถูกสร้างขึ้นด้วยไลบรารี VNDK เช่น libbase ที่รันไทม์ my_service จะใช้ libbase จากไลบรารี VNDK ที่ระบบจัดเตรียมไว้แทน

apex {
  ..
  vendor: true,
  use_vndk_as_stable: true,
  binaries: ["my_service"],
  ..
}

ในตัวอย่างด้านล่าง APEX จะมีไลบรารีที่ใช้ร่วมกัน my_standalone_lib และการขึ้นต่อกันที่ไม่เสถียรใดๆ (ตามที่อธิบายไว้ข้างต้น)

apex {
  ..
  vendor: true,
  use_vndk_as_stable: true,
  native_shared_libs: ["my_standalone_lib"],
  ..
}

การใช้งาน HAL

หากต้องการกำหนดการใช้งาน HAL ให้จัดเตรียมไบนารีและไลบรารีที่เกี่ยวข้องภายใน APEX ของผู้จำหน่ายซึ่งคล้ายกับตัวอย่างต่อไปนี้:

หากต้องการสรุปการใช้งาน HAL อย่างสมบูรณ์ APEX ควรระบุแฟรกเมนต์ VINTF และสคริปต์เริ่มต้นที่เกี่ยวข้องด้วย

ชิ้นส่วนของ VINTF

แฟรกเมนต์ VINTF สามารถให้บริการได้จากผู้จำหน่าย APEX เมื่อแฟรกเมนต์อยู่ใน etc/vintf ของ APEX

ใช้คุณสมบัติ prebuilts เพื่อฝังชิ้นส่วน VINTF ใน APEX

apex {
  ..
  vendor: true,
  prebuilts: ["fragment.xml"],
  ..
}

prebuilt_etc {
  name: "fragment.xml",
  src: "fragment.xml",
  sub_dir: "vintf",
}

สคริปต์เริ่มต้น

APEX สามารถรวมสคริปต์เริ่มต้นได้สองวิธี: (A) ไฟล์ข้อความที่สร้างไว้ล่วงหน้าภายในเพย์โหลดของ APEX หรือ (B) สคริปต์เริ่มต้นปกติใน /vendor/etc คุณสามารถตั้งค่าทั้งคู่สำหรับ APEX เดียวกันได้

สคริปต์เริ่มต้นใน APEX:

prebuilt_etc {
  name: "myinit.rc",
  src: "myinit.rc"
}

apex {
  ..
  vendor: true,
  prebuilts: ["myinit.rc"],
  ..
}

สคริปต์เริ่มต้นภายใน APEX สามารถมีได้เฉพาะคำจำกัดความ service เท่านั้น สคริปต์เริ่มต้นใน Vendor APEXes อาจมีคำสั่ง on <property> ได้เช่นกัน

ระวังเมื่อใช้ on คำสั่ง เนื่องจากสคริปต์เริ่มต้นใน APEX จะถูกแยกวิเคราะห์และดำเนินการ หลังจาก เปิดใช้งาน APEX ดังนั้นจึงไม่สามารถใช้เหตุการณ์หรือคุณสมบัติบางอย่างได้ ใช้ apex.all.ready=true เพื่อเริ่มการดำเนินการโดยเร็วที่สุด

เฟิร์มแวร์

ตัวอย่าง:

ฝังเฟิร์มแวร์ในผู้จำหน่าย APEX ด้วยประเภทโมดูล prebuilt_firmware ดังต่อไปนี้

prebuilt_firmware {
  name: "my.bin",
  src: "path_to_prebuilt_firmware",
  vendor: true,
}

apex {
  ..
  vendor: true,
  prebuilts: ["my.bin"],  // installed inside APEX as /etc/firmware/my.bin
  ..
}

โมดูล prebuilt_firmware ได้รับการติดตั้งในไดเร็กทอรี <apex name>/etc/firmware ของ APEX ueventd สแกนไดเร็กทอรี /apex/*/etc/firmware เพื่อค้นหาโมดูลเฟิร์มแวร์

file_contexts ของ APEX ควรติดป้ายกำกับรายการเพย์โหลดเฟิร์มแวร์อย่างถูกต้องเพื่อให้แน่ใจว่าไฟล์เหล่านี้สามารถเข้าถึงได้โดย ueventd ณ รันไทม์ โดยทั่วไปแล้ว ป้ายกำกับ vendor_file ก็เพียงพอแล้ว ตัวอย่างเช่น:

(/.*)? u:object_r:vendor_file:s0

โมดูลเคอร์เนล

ฝังโมดูลเคอร์เนลในผู้จำหน่าย APEX เป็นโมดูลที่สร้างไว้ล่วงหน้า ดังต่อไปนี้

prebuilt_etc {
  name: "my.ko",
  src: "my.ko",
  vendor: true,
  sub_dir: "modules"
}

apex {
  ..
  vendor: true,
  prebuilts: ["my.ko"],  // installed inside APEX as /etc/modules/my.ko
  ..
}

file_contexts ของ APEX ควรติดป้ายกำกับรายการเพย์โหลดโมดูลเคอร์เนลอย่างถูกต้อง ตัวอย่างเช่น:

/etc/modules(/.*)? u:object_r:vendor_kernel_modules:s0

โมดูลเคอร์เนลต้องได้รับการติดตั้งอย่างชัดเจน สคริปต์เริ่มต้นตัวอย่างต่อไปนี้ในพาร์ติชันผู้ขายแสดงการติดตั้งผ่าน insmod :

my_init.rc :

on early-boot
  insmod /apex/myapex/etc/modules/my.ko
  ..

การซ้อนทับทรัพยากรรันไทม์

ตัวอย่าง:

ฝังการ ซ้อนทับทรัพยากรรันไทม์ ใน APEX ของผู้ขายโดยใช้คุณสมบัติ rros

runtime_resource_overlay {
    name: "my_rro",
    soc_specific: true,
}


apex {
  ..
  vendor: true,
  rros: ["my_rro"],  // installed inside APEX as /overlay/my_rro.apk
  ..
}

ไฟล์ปรับแต่งอื่นๆ

APEX ของผู้จำหน่ายรองรับไฟล์กำหนดค่าอื่นๆ ที่มักพบในพาร์ติชันของผู้จำหน่ายตามที่สร้างไว้ล่วงหน้าภายใน APEX ของผู้จำหน่าย และอื่นๆ อีกมากมายที่กำลังถูกเพิ่มเข้ามา

ตัวอย่าง:

คุณสมบัติการพัฒนาพิเศษ

การเลือก APEX เมื่อบูตเครื่อง

ตัวอย่าง:

นักพัฒนายังสามารถติดตั้ง APEX ของผู้จำหน่ายหลายเวอร์ชันที่ใช้ชื่อและคีย์ APEX เดียวกัน จากนั้นเลือกเวอร์ชันที่จะเปิดใช้งานในระหว่างการบูตแต่ละครั้งโดยใช้ sysprops แบบถาวร สำหรับกรณีการใช้งานของนักพัฒนาซอฟต์แวร์บางราย การดำเนินการนี้อาจง่ายกว่าการติดตั้งสำเนาใหม่ของ APEX โดยใช้ adb install

กรณีการใช้งานตัวอย่าง:

  • ติดตั้ง APEX ผู้จำหน่าย wifi HAL 3 เวอร์ชัน: ทีม QA สามารถเรียกใช้การทดสอบด้วยตนเองหรืออัตโนมัติโดยใช้เวอร์ชันหนึ่ง จากนั้นรีบูตเป็นเวอร์ชันอื่นและรันการทดสอบอีกครั้ง จากนั้นเปรียบเทียบผลลัพธ์สุดท้าย
  • ติดตั้งกล้อง HAL ผู้จำหน่าย APEX 2 เวอร์ชัน เวอร์ชัน ปัจจุบัน และ เวอร์ชันทดลอง : ผู้ Dogfood สามารถใช้เวอร์ชันทดลองได้โดยไม่ต้องดาวน์โหลดและติดตั้งไฟล์เพิ่มเติม ดังนั้นจึงสามารถสลับกลับได้อย่างง่ายดาย

ในระหว่างการบูทเครื่อง apexd จะค้นหา sysprops ที่เป็นไปตามรูปแบบเฉพาะเพื่อเปิดใช้งานเวอร์ชัน APEX ที่ถูกต้อง

รูปแบบที่คาดหวังสำหรับคีย์คุณสมบัติคือ:

  • บูตคอนฟิก
    • ใช้เพื่อตั้งค่าเริ่มต้นใน BoardConfig.mk
    • androidboot.vendor.apex.<apex name>
  • ระบบซิสพรอพแบบถาวร
    • ใช้เพื่อเปลี่ยนค่าเริ่มต้น ตั้งค่าบนอุปกรณ์ที่บู๊ตแล้ว
    • แทนที่ค่า bootconfig หากมี
    • persist.vendor.apex.<apex name>

ค่าของคุณสมบัติควรเป็นชื่อไฟล์ของ APEX ที่ควรเปิดใช้งาน

// Default version.
apex {
  name: "com.oem.camera.hal.my_apex_default",
  vendor: true,
  ..
}

// Non-default version.
apex {
  name: "com.oem.camera.hal.my_apex_experimental",
  vendor: true,
  ..
}

ควรกำหนดค่าเวอร์ชันเริ่มต้นโดยใช้ bootconfig ใน BoardConfig.mk :

# Example for APEX "com.oem.camera.hal" with the default above:
BOARD_BOOTCONFIG += \
    androidboot.vendor.apex.com.oem.camera.hal=com.oem.camera.hal.my_apex_default

หลังจากบูตอุปกรณ์แล้ว ให้เปลี่ยนเวอร์ชันที่เปิดใช้งานโดยการตั้งค่า sysprop แบบถาวร:

$ adb root;
$ adb shell setprop \
    persist.vendor.apex.com.oem.camera.hal \
    com.oem.camera.hal.my_apex_experimental;
$ adb reboot;

หากอุปกรณ์รองรับการอัปเดต bootconfig หลังจากแฟลช (เช่น ผ่านคำสั่ง fastboot oem ) การเปลี่ยนคุณสมบัติ bootconfig สำหรับ APEX ที่ติดตั้งหลายตัวจะเปลี่ยนเวอร์ชันที่เปิดใช้งานขณะบู๊ตเครื่องด้วย

สำหรับอุปกรณ์อ้างอิงเสมือนที่ใช้ Cuttlefish คุณสามารถใช้คำสั่ง --extra_bootconfig_args เพื่อตั้งค่าคุณสมบัติ bootconfig ได้โดยตรงในขณะที่เปิดใช้งาน ตัวอย่างเช่น:

launch_cvd --noresume \
  --extra_bootconfig_args "androidboot.vendor.apex.com.oem.camera.hal:=com.oem.camera.hal.my_apex_experimental";
,

คุณสามารถใช้ รูปแบบไฟล์ APEX เพื่อจัดทำแพ็กเกจและติดตั้งโมดูลระบบปฏิบัติการ Android ระดับล่างได้ ช่วยให้สามารถสร้างและติดตั้งส่วนประกอบได้อย่างอิสระ เช่น บริการและไลบรารีแบบเนทีฟ การใช้งาน HAL เฟิร์มแวร์ ไฟล์กำหนดค่า ฯลฯ

APEX ของผู้จำหน่ายได้รับการติดตั้งโดยระบบ build โดยอัตโนมัติในพาร์ติชัน /vendor และเปิดใช้งานเมื่อรันไทม์โดย apexd เช่นเดียวกับ APEX ในพาร์ติชันอื่น

กรณีการใช้งาน

การทำให้เป็นโมดูลของอิมเมจของผู้ขาย

APEX อำนวยความสะดวกในการรวมกลุ่มและการทำให้เป็นโมดูลของการใช้งานฟีเจอร์บนอิมเมจของผู้จำหน่ายอย่างเป็นธรรมชาติ

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

ตัวอย่างเช่น OEM อาจเลือกที่จะเขียนอุปกรณ์ของตนด้วยการใช้ APEX ของ AOSP wifi, การใช้ SoC บลูทูธ APEX และ APEX ของการใช้โทรศัพท์ OEM แบบกำหนดเอง

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

การทำซ้ำของนักพัฒนา

APEX ของผู้จำหน่ายช่วยให้นักพัฒนาทำซ้ำได้เร็วขึ้นในขณะที่พัฒนาโมดูลของผู้จำหน่ายโดยการรวมการใช้งานฟีเจอร์ทั้งหมด เช่น wifi HAL ภายใน APEX ของผู้จำหน่าย นักพัฒนาสามารถสร้างและผลักดันผู้จำหน่าย APEX ทีละรายเพื่อทดสอบการเปลี่ยนแปลง แทนที่จะสร้างอิมเมจของผู้จำหน่ายใหม่ทั้งหมด

สิ่งนี้จะช่วยลดความยุ่งยากและเพิ่มความเร็วรอบการวนซ้ำของนักพัฒนาสำหรับนักพัฒนาที่ทำงานในส่วนฟีเจอร์เดียวเป็นหลักและต้องการวนซ้ำเฉพาะส่วนฟีเจอร์นั้น

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

การรวมพื้นที่คุณลักษณะไว้ใน APEX ยังช่วยลดความยุ่งยากในการดีบักหรือการเปลี่ยนกลับเมื่อสังเกตเห็นพฤติกรรมของอุปกรณ์ที่ไม่ดี ตัวอย่างเช่น หากระบบโทรศัพท์ทำงานได้ไม่ดีในบิลด์ใหม่ นักพัฒนาอาจลองติดตั้ง APEX สำหรับการใช้งานระบบโทรศัพท์รุ่นเก่าบนอุปกรณ์ (โดยไม่จำเป็นต้องแฟลชบิลด์เต็ม) และดูว่าลักษณะการทำงานที่ดีได้รับการกู้คืนหรือไม่

ขั้นตอนการทำงานตัวอย่าง:

# Build the entire device and flash. OR, obtain an already-flashed device.
source build/envsetup.sh && lunch oem_device-userdebug
m
fastboot flashall -w

# Test the device.
... testing ...

# Check previous behavior using a vendor APEX from one week ago, downloaded from
# your continuous integration build.
... download command ...
adb install <path to downloaded APEX>
adb reboot
... testing ...

# Edit and rebuild just the APEX to change and test behavior.
... edit APEX source contents ...
m <apex module name>
adb install out/<path to built APEX>
adb reboot
... testing ...

ตัวอย่าง

พื้นฐาน

ดูหน้า รูปแบบไฟล์ APEX หลักสำหรับข้อมูล APEX ทั่วไป รวมถึงข้อกำหนดของอุปกรณ์ รายละเอียดรูปแบบไฟล์ และขั้นตอนการติดตั้ง

ใน Android.bp การตั้งค่า vendor: true property ทำให้โมดูล APEX เป็นผู้จำหน่าย APEX

apex {
  ..
  vendor: true,
  ..
}

ไบนารีและไลบรารีที่แบ่งใช้

APEX มีการขึ้นต่อกันแบบสกรรมกริยาภายในเพย์โหลดของ APEX เว้นแต่ว่าจะมีอินเทอร์เฟซที่เสถียร

อินเทอร์เฟซดั้งเดิมที่เสถียรสำหรับการพึ่งพา APEX ของผู้ขาย ได้แก่ cc_library พร้อม stubs , ndk_library หรือ llndk_library การขึ้นต่อกันเหล่านี้ไม่รวมอยู่ในแพ็กเกจ และการขึ้นต่อกันจะถูกบันทึกไว้ในรายการ APEX รายการได้รับการประมวลผลโดย linkerconfig เพื่อให้การพึ่งพาเนทีฟภายนอกพร้อมใช้งานในขณะรันไทม์

ต่างจาก APEX ในพาร์ติชัน /system โดยทั่วไป APEX ของผู้จำหน่ายจะเชื่อมโยงกับเวอร์ชัน VNDK ที่ระบุ ไลบรารี VNDK รับประกันความเสถียรของ ABI ภายในรีลีส ดังนั้นเราจึงสามารถถือว่าไลบรารี VNDK มีความเสถียรและลดขนาดของ APEX ของผู้จำหน่ายโดยการแยกไลบรารีเหล่านั้นออกจาก APEX โดยใช้คุณสมบัติ use_vndk_as_stable

ในตัวอย่างด้านล่าง APEX จะมีทั้งไบนารี ( my_service ) และการขึ้นต่อกันที่ไม่เสถียร ( ไฟล์ *.so ) จะไม่มีไลบรารี VNDK แม้ว่า my_service จะถูกสร้างขึ้นด้วยไลบรารี VNDK เช่น libbase ที่รันไทม์ my_service จะใช้ libbase จากไลบรารี VNDK ที่ระบบจัดเตรียมไว้แทน

apex {
  ..
  vendor: true,
  use_vndk_as_stable: true,
  binaries: ["my_service"],
  ..
}

ในตัวอย่างด้านล่าง APEX จะมีไลบรารีที่ใช้ร่วมกัน my_standalone_lib และการขึ้นต่อกันที่ไม่เสถียรใดๆ (ตามที่อธิบายไว้ข้างต้น)

apex {
  ..
  vendor: true,
  use_vndk_as_stable: true,
  native_shared_libs: ["my_standalone_lib"],
  ..
}

การใช้งาน HAL

หากต้องการกำหนดการใช้งาน HAL ให้จัดเตรียมไบนารีและไลบรารีที่เกี่ยวข้องภายใน APEX ของผู้จำหน่ายซึ่งคล้ายกับตัวอย่างต่อไปนี้:

หากต้องการสรุปการใช้งาน HAL อย่างสมบูรณ์ APEX ควรระบุแฟรกเมนต์ VINTF และสคริปต์เริ่มต้นที่เกี่ยวข้องด้วย

ชิ้นส่วนของ VINTF

แฟรกเมนต์ VINTF สามารถให้บริการได้จากผู้จำหน่าย APEX เมื่อแฟรกเมนต์อยู่ใน etc/vintf ของ APEX

ใช้คุณสมบัติ prebuilts เพื่อฝังชิ้นส่วน VINTF ใน APEX

apex {
  ..
  vendor: true,
  prebuilts: ["fragment.xml"],
  ..
}

prebuilt_etc {
  name: "fragment.xml",
  src: "fragment.xml",
  sub_dir: "vintf",
}

สคริปต์เริ่มต้น

APEX สามารถรวมสคริปต์เริ่มต้นได้สองวิธี: (A) ไฟล์ข้อความที่สร้างไว้ล่วงหน้าภายในเพย์โหลดของ APEX หรือ (B) สคริปต์เริ่มต้นปกติใน /vendor/etc คุณสามารถตั้งค่าทั้งคู่สำหรับ APEX เดียวกันได้

สคริปต์เริ่มต้นใน APEX:

prebuilt_etc {
  name: "myinit.rc",
  src: "myinit.rc"
}

apex {
  ..
  vendor: true,
  prebuilts: ["myinit.rc"],
  ..
}

สคริปต์เริ่มต้นภายใน APEX สามารถมีได้เฉพาะคำจำกัดความ service เท่านั้น สคริปต์เริ่มต้นใน Vendor APEXes อาจมีคำสั่ง on <property> ได้เช่นกัน

ระวังเมื่อใช้ on คำสั่ง เนื่องจากสคริปต์เริ่มต้นใน APEX จะถูกแยกวิเคราะห์และดำเนินการ หลังจาก เปิดใช้งาน APEX ดังนั้นจึงไม่สามารถใช้เหตุการณ์หรือคุณสมบัติบางอย่างได้ ใช้ apex.all.ready=true เพื่อเริ่มการดำเนินการโดยเร็วที่สุด

เฟิร์มแวร์

ตัวอย่าง:

ฝังเฟิร์มแวร์ในผู้จำหน่าย APEX ด้วยประเภทโมดูล prebuilt_firmware ดังต่อไปนี้

prebuilt_firmware {
  name: "my.bin",
  src: "path_to_prebuilt_firmware",
  vendor: true,
}

apex {
  ..
  vendor: true,
  prebuilts: ["my.bin"],  // installed inside APEX as /etc/firmware/my.bin
  ..
}

โมดูล prebuilt_firmware ได้รับการติดตั้งในไดเร็กทอรี <apex name>/etc/firmware ของ APEX ueventd สแกนไดเร็กทอรี /apex/*/etc/firmware เพื่อค้นหาโมดูลเฟิร์มแวร์

file_contexts ของ APEX ควรติดป้ายกำกับรายการเพย์โหลดเฟิร์มแวร์อย่างถูกต้องเพื่อให้แน่ใจว่าไฟล์เหล่านี้สามารถเข้าถึงได้โดย ueventd ณ รันไทม์ โดยทั่วไปแล้ว ป้ายกำกับ vendor_file ก็เพียงพอแล้ว ตัวอย่างเช่น:

(/.*)? u:object_r:vendor_file:s0

โมดูลเคอร์เนล

ฝังโมดูลเคอร์เนลในผู้จำหน่าย APEX เป็นโมดูลที่สร้างไว้ล่วงหน้า ดังต่อไปนี้

prebuilt_etc {
  name: "my.ko",
  src: "my.ko",
  vendor: true,
  sub_dir: "modules"
}

apex {
  ..
  vendor: true,
  prebuilts: ["my.ko"],  // installed inside APEX as /etc/modules/my.ko
  ..
}

file_contexts ของ APEX ควรติดป้ายกำกับรายการเพย์โหลดโมดูลเคอร์เนลอย่างถูกต้อง ตัวอย่างเช่น:

/etc/modules(/.*)? u:object_r:vendor_kernel_modules:s0

โมดูลเคอร์เนลต้องได้รับการติดตั้งอย่างชัดเจน สคริปต์เริ่มต้นตัวอย่างต่อไปนี้ในพาร์ติชันผู้ขายแสดงการติดตั้งผ่าน insmod :

my_init.rc :

on early-boot
  insmod /apex/myapex/etc/modules/my.ko
  ..

การซ้อนทับทรัพยากรรันไทม์

ตัวอย่าง:

ฝังการ ซ้อนทับทรัพยากรรันไทม์ ใน APEX ของผู้ขายโดยใช้คุณสมบัติ rros

runtime_resource_overlay {
    name: "my_rro",
    soc_specific: true,
}


apex {
  ..
  vendor: true,
  rros: ["my_rro"],  // installed inside APEX as /overlay/my_rro.apk
  ..
}

ไฟล์ปรับแต่งอื่นๆ

APEX ของผู้จำหน่ายรองรับไฟล์กำหนดค่าอื่นๆ ที่มักพบในพาร์ติชันของผู้จำหน่ายตามที่สร้างไว้ล่วงหน้าภายใน APEX ของผู้จำหน่าย และอื่นๆ อีกมากมายที่กำลังถูกเพิ่มเข้ามา

ตัวอย่าง:

คุณสมบัติการพัฒนาพิเศษ

การเลือก APEX เมื่อบูตเครื่อง

ตัวอย่าง:

นักพัฒนายังสามารถติดตั้ง APEX ของผู้จำหน่ายหลายเวอร์ชันที่ใช้ชื่อและคีย์ APEX เดียวกัน จากนั้นเลือกเวอร์ชันที่จะเปิดใช้งานในระหว่างการบูตแต่ละครั้งโดยใช้ sysprops แบบถาวร สำหรับกรณีการใช้งานของนักพัฒนาซอฟต์แวร์บางราย การดำเนินการนี้อาจง่ายกว่าการติดตั้งสำเนาใหม่ของ APEX โดยใช้ adb install

กรณีการใช้งานตัวอย่าง:

  • ติดตั้ง APEX ผู้จำหน่าย wifi HAL 3 เวอร์ชัน: ทีม QA สามารถเรียกใช้การทดสอบด้วยตนเองหรืออัตโนมัติโดยใช้เวอร์ชันหนึ่ง จากนั้นรีบูตเป็นเวอร์ชันอื่นและรันการทดสอบอีกครั้ง จากนั้นเปรียบเทียบผลลัพธ์สุดท้าย
  • ติดตั้งกล้อง HAL ผู้จำหน่าย APEX 2 เวอร์ชัน เวอร์ชัน ปัจจุบัน และ เวอร์ชันทดลอง : ผู้ Dogfood สามารถใช้เวอร์ชันทดลองได้โดยไม่ต้องดาวน์โหลดและติดตั้งไฟล์เพิ่มเติม ดังนั้นจึงสามารถสลับกลับได้อย่างง่ายดาย

ในระหว่างการบูทเครื่อง apexd จะค้นหา sysprops ที่เป็นไปตามรูปแบบเฉพาะเพื่อเปิดใช้งานเวอร์ชัน APEX ที่ถูกต้อง

รูปแบบที่คาดหวังสำหรับคีย์คุณสมบัติคือ:

  • บูตคอนฟิก
    • ใช้เพื่อตั้งค่าเริ่มต้นใน BoardConfig.mk
    • androidboot.vendor.apex.<apex name>
  • ระบบซิสพรอพแบบถาวร
    • ใช้เพื่อเปลี่ยนค่าเริ่มต้น ตั้งค่าบนอุปกรณ์ที่บู๊ตแล้ว
    • แทนที่ค่า bootconfig หากมี
    • persist.vendor.apex.<apex name>

ค่าของคุณสมบัติควรเป็นชื่อไฟล์ของ APEX ที่ควรเปิดใช้งาน

// Default version.
apex {
  name: "com.oem.camera.hal.my_apex_default",
  vendor: true,
  ..
}

// Non-default version.
apex {
  name: "com.oem.camera.hal.my_apex_experimental",
  vendor: true,
  ..
}

ควรกำหนดค่าเวอร์ชันเริ่มต้นโดยใช้ bootconfig ใน BoardConfig.mk :

# Example for APEX "com.oem.camera.hal" with the default above:
BOARD_BOOTCONFIG += \
    androidboot.vendor.apex.com.oem.camera.hal=com.oem.camera.hal.my_apex_default

หลังจากบูตอุปกรณ์แล้ว ให้เปลี่ยนเวอร์ชันที่เปิดใช้งานโดยการตั้งค่า sysprop แบบถาวร:

$ adb root;
$ adb shell setprop \
    persist.vendor.apex.com.oem.camera.hal \
    com.oem.camera.hal.my_apex_experimental;
$ adb reboot;

หากอุปกรณ์รองรับการอัปเดต bootconfig หลังจากแฟลช (เช่น ผ่านคำสั่ง fastboot oem ) การเปลี่ยนคุณสมบัติ bootconfig สำหรับ APEX ที่ติดตั้งหลายตัวจะเปลี่ยนเวอร์ชันที่เปิดใช้งานขณะบู๊ตเครื่องด้วย

สำหรับอุปกรณ์อ้างอิงเสมือนที่ใช้ Cuttlefish คุณสามารถใช้คำสั่ง --extra_bootconfig_args เพื่อตั้งค่าคุณสมบัติ bootconfig ได้โดยตรงในขณะที่เปิดใช้งาน ตัวอย่างเช่น:

launch_cvd --noresume \
  --extra_bootconfig_args "androidboot.vendor.apex.com.oem.camera.hal:=com.oem.camera.hal.my_apex_experimental";
,

คุณสามารถใช้ รูปแบบไฟล์ APEX เพื่อจัดทำแพ็กเกจและติดตั้งโมดูลระบบปฏิบัติการ Android ระดับล่างได้ ช่วยให้สามารถสร้างและติดตั้งส่วนประกอบได้อย่างอิสระ เช่น บริการและไลบรารีแบบเนทีฟ การใช้งาน HAL เฟิร์มแวร์ ไฟล์กำหนดค่า ฯลฯ

APEX ของผู้จำหน่ายได้รับการติดตั้งโดยระบบ build โดยอัตโนมัติในพาร์ติชัน /vendor และเปิดใช้งานเมื่อรันไทม์โดย apexd เช่นเดียวกับ APEX ในพาร์ติชันอื่น

กรณีการใช้งาน

การทำให้เป็นโมดูลของอิมเมจของผู้ขาย

APEX อำนวยความสะดวกในการรวมกลุ่มและการทำให้เป็นโมดูลของการใช้งานฟีเจอร์บนอิมเมจของผู้จำหน่ายอย่างเป็นธรรมชาติ

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

ตัวอย่างเช่น OEM อาจเลือกที่จะเขียนอุปกรณ์ของตนด้วยการใช้ APEX ของ AOSP wifi, การใช้ SoC บลูทูธ APEX และ APEX ของการใช้โทรศัพท์ OEM แบบกำหนดเอง

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

การทำซ้ำของนักพัฒนา

APEX ของผู้จำหน่ายช่วยให้นักพัฒนาทำซ้ำได้เร็วขึ้นในขณะที่พัฒนาโมดูลของผู้จำหน่ายโดยการรวมการใช้งานฟีเจอร์ทั้งหมด เช่น wifi HAL ภายใน APEX ของผู้จำหน่าย นักพัฒนาสามารถสร้างและผลักดันผู้จำหน่าย APEX ทีละรายเพื่อทดสอบการเปลี่ยนแปลง แทนที่จะสร้างอิมเมจของผู้จำหน่ายใหม่ทั้งหมด

สิ่งนี้จะช่วยลดความยุ่งยากและเพิ่มความเร็วรอบการวนซ้ำของนักพัฒนาสำหรับนักพัฒนาที่ทำงานในส่วนฟีเจอร์เดียวเป็นหลักและต้องการวนซ้ำเฉพาะส่วนฟีเจอร์นั้น

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

การรวมพื้นที่คุณลักษณะไว้ใน APEX ยังช่วยลดความยุ่งยากในการดีบักหรือการเปลี่ยนกลับเมื่อสังเกตเห็นพฤติกรรมของอุปกรณ์ที่ไม่ดี ตัวอย่างเช่น หากระบบโทรศัพท์ทำงานได้ไม่ดีในบิลด์ใหม่ นักพัฒนาอาจลองติดตั้ง APEX สำหรับการใช้งานระบบโทรศัพท์รุ่นเก่าบนอุปกรณ์ (โดยไม่จำเป็นต้องแฟลชบิลด์เต็ม) และดูว่าลักษณะการทำงานที่ดีได้รับการกู้คืนหรือไม่

ขั้นตอนการทำงานตัวอย่าง:

# Build the entire device and flash. OR, obtain an already-flashed device.
source build/envsetup.sh && lunch oem_device-userdebug
m
fastboot flashall -w

# Test the device.
... testing ...

# Check previous behavior using a vendor APEX from one week ago, downloaded from
# your continuous integration build.
... download command ...
adb install <path to downloaded APEX>
adb reboot
... testing ...

# Edit and rebuild just the APEX to change and test behavior.
... edit APEX source contents ...
m <apex module name>
adb install out/<path to built APEX>
adb reboot
... testing ...

ตัวอย่าง

พื้นฐาน

ดูหน้า รูปแบบไฟล์ APEX หลักสำหรับข้อมูล APEX ทั่วไป รวมถึงข้อกำหนดของอุปกรณ์ รายละเอียดรูปแบบไฟล์ และขั้นตอนการติดตั้ง

ใน Android.bp การตั้งค่า vendor: true property ทำให้โมดูล APEX เป็นผู้จำหน่าย APEX

apex {
  ..
  vendor: true,
  ..
}

ไบนารีและไลบรารีที่แบ่งใช้

APEX มีการขึ้นต่อกันแบบสกรรมกริยาภายในเพย์โหลดของ APEX เว้นแต่ว่าจะมีอินเทอร์เฟซที่เสถียร

อินเทอร์เฟซดั้งเดิมที่เสถียรสำหรับการพึ่งพา APEX ของผู้ขาย ได้แก่ cc_library พร้อม stubs , ndk_library หรือ llndk_library การขึ้นต่อกันเหล่านี้ไม่รวมอยู่ในแพ็กเกจ และการขึ้นต่อกันจะถูกบันทึกไว้ในรายการ APEX รายการได้รับการประมวลผลโดย linkerconfig เพื่อให้การพึ่งพาเนทีฟภายนอกพร้อมใช้งานในขณะรันไทม์

ต่างจาก APEX ในพาร์ติชัน /system โดยทั่วไป APEX ของผู้จำหน่ายจะเชื่อมโยงกับเวอร์ชัน VNDK ที่ระบุ ไลบรารี VNDK รับประกันความเสถียรของ ABI ภายในรีลีส ดังนั้นเราจึงสามารถถือว่าไลบรารี VNDK มีความเสถียรและลดขนาดของ APEX ของผู้จำหน่ายโดยการแยกไลบรารีเหล่านั้นออกจาก APEX โดยใช้คุณสมบัติ use_vndk_as_stable

ในตัวอย่างด้านล่าง APEX จะมีทั้งไบนารี ( my_service ) และการขึ้นต่อกันที่ไม่เสถียร ( ไฟล์ *.so ) จะไม่มีไลบรารี VNDK แม้ว่า my_service จะถูกสร้างขึ้นด้วยไลบรารี VNDK เช่น libbase ที่รันไทม์ my_service จะใช้ libbase จากไลบรารี VNDK ที่ระบบจัดเตรียมไว้แทน

apex {
  ..
  vendor: true,
  use_vndk_as_stable: true,
  binaries: ["my_service"],
  ..
}

ในตัวอย่างด้านล่าง APEX จะมีไลบรารีที่ใช้ร่วมกัน my_standalone_lib และการขึ้นต่อกันที่ไม่เสถียรใดๆ (ตามที่อธิบายไว้ข้างต้น)

apex {
  ..
  vendor: true,
  use_vndk_as_stable: true,
  native_shared_libs: ["my_standalone_lib"],
  ..
}

การใช้งาน HAL

หากต้องการกำหนดการใช้งาน HAL ให้จัดเตรียมไบนารีและไลบรารีที่เกี่ยวข้องภายใน APEX ของผู้จำหน่ายซึ่งคล้ายกับตัวอย่างต่อไปนี้:

หากต้องการสรุปการใช้งาน HAL อย่างสมบูรณ์ APEX ควรระบุแฟรกเมนต์ VINTF และสคริปต์เริ่มต้นที่เกี่ยวข้องด้วย

ชิ้นส่วนของ VINTF

แฟรกเมนต์ VINTF สามารถให้บริการได้จากผู้จำหน่าย APEX เมื่อแฟรกเมนต์อยู่ใน etc/vintf ของ APEX

ใช้คุณสมบัติ prebuilts เพื่อฝังชิ้นส่วน VINTF ใน APEX

apex {
  ..
  vendor: true,
  prebuilts: ["fragment.xml"],
  ..
}

prebuilt_etc {
  name: "fragment.xml",
  src: "fragment.xml",
  sub_dir: "vintf",
}

สคริปต์เริ่มต้น

APEX สามารถรวมสคริปต์เริ่มต้นได้สองวิธี: (A) ไฟล์ข้อความที่สร้างไว้ล่วงหน้าภายในเพย์โหลดของ APEX หรือ (B) สคริปต์เริ่มต้นปกติใน /vendor/etc คุณสามารถตั้งค่าทั้งคู่สำหรับ APEX เดียวกันได้

สคริปต์เริ่มต้นใน APEX:

prebuilt_etc {
  name: "myinit.rc",
  src: "myinit.rc"
}

apex {
  ..
  vendor: true,
  prebuilts: ["myinit.rc"],
  ..
}

สคริปต์เริ่มต้นภายใน APEX สามารถมีได้เฉพาะคำจำกัดความ service เท่านั้น สคริปต์เริ่มต้นใน Vendor APEXes อาจมีคำสั่ง on <property> ได้เช่นกัน

ระวังเมื่อใช้ on คำสั่ง เนื่องจากสคริปต์เริ่มต้นใน APEX จะถูกแยกวิเคราะห์และดำเนินการ หลังจาก เปิดใช้งาน APEX ดังนั้นจึงไม่สามารถใช้เหตุการณ์หรือคุณสมบัติบางอย่างได้ ใช้ apex.all.ready=true เพื่อเริ่มการดำเนินการโดยเร็วที่สุด

เฟิร์มแวร์

ตัวอย่าง:

ฝังเฟิร์มแวร์ในผู้จำหน่าย APEX ด้วยประเภทโมดูล prebuilt_firmware ดังต่อไปนี้

prebuilt_firmware {
  name: "my.bin",
  src: "path_to_prebuilt_firmware",
  vendor: true,
}

apex {
  ..
  vendor: true,
  prebuilts: ["my.bin"],  // installed inside APEX as /etc/firmware/my.bin
  ..
}

โมดูล prebuilt_firmware ได้รับการติดตั้งในไดเร็กทอรี <apex name>/etc/firmware ของ APEX ueventd สแกนไดเร็กทอรี /apex/*/etc/firmware เพื่อค้นหาโมดูลเฟิร์มแวร์

file_contexts ของ APEX ควรติดป้ายกำกับรายการเพย์โหลดเฟิร์มแวร์อย่างถูกต้องเพื่อให้แน่ใจว่าไฟล์เหล่านี้สามารถเข้าถึงได้โดย ueventd ณ รันไทม์ โดยทั่วไปแล้ว ป้ายกำกับ vendor_file ก็เพียงพอแล้ว ตัวอย่างเช่น:

(/.*)? u:object_r:vendor_file:s0

โมดูลเคอร์เนล

ฝังโมดูลเคอร์เนลในผู้จำหน่าย APEX เป็นโมดูลที่สร้างไว้ล่วงหน้า ดังต่อไปนี้

prebuilt_etc {
  name: "my.ko",
  src: "my.ko",
  vendor: true,
  sub_dir: "modules"
}

apex {
  ..
  vendor: true,
  prebuilts: ["my.ko"],  // installed inside APEX as /etc/modules/my.ko
  ..
}

file_contexts ของ APEX ควรติดป้ายกำกับรายการเพย์โหลดโมดูลเคอร์เนลอย่างถูกต้อง ตัวอย่างเช่น:

/etc/modules(/.*)? u:object_r:vendor_kernel_modules:s0

โมดูลเคอร์เนลต้องได้รับการติดตั้งอย่างชัดเจน สคริปต์เริ่มต้นตัวอย่างต่อไปนี้ในพาร์ติชันผู้ขายแสดงการติดตั้งผ่าน insmod :

my_init.rc :

on early-boot
  insmod /apex/myapex/etc/modules/my.ko
  ..

การซ้อนทับทรัพยากรรันไทม์

ตัวอย่าง:

ฝังการ ซ้อนทับทรัพยากรรันไทม์ ใน APEX ของผู้ขายโดยใช้คุณสมบัติ rros

runtime_resource_overlay {
    name: "my_rro",
    soc_specific: true,
}


apex {
  ..
  vendor: true,
  rros: ["my_rro"],  // installed inside APEX as /overlay/my_rro.apk
  ..
}

ไฟล์ปรับแต่งอื่นๆ

APEX ของผู้จำหน่ายรองรับไฟล์กำหนดค่าอื่นๆ ที่มักพบในพาร์ติชันของผู้จำหน่ายตามที่สร้างไว้ล่วงหน้าภายใน APEX ของผู้จำหน่าย และอื่นๆ อีกมากมายที่กำลังถูกเพิ่มเข้ามา

ตัวอย่าง:

คุณสมบัติการพัฒนาพิเศษ

การเลือก APEX เมื่อบูตเครื่อง

ตัวอย่าง:

นักพัฒนายังสามารถติดตั้ง APEX ของผู้จำหน่ายหลายเวอร์ชันที่ใช้ชื่อและคีย์ APEX เดียวกัน จากนั้นเลือกเวอร์ชันที่จะเปิดใช้งานในระหว่างการบูตแต่ละครั้งโดยใช้ sysprops แบบถาวร สำหรับกรณีการใช้งานของนักพัฒนาซอฟต์แวร์บางราย การดำเนินการนี้อาจง่ายกว่าการติดตั้งสำเนาใหม่ของ APEX โดยใช้ adb install

กรณีการใช้งานตัวอย่าง:

  • ติดตั้ง APEX ผู้จำหน่าย wifi HAL 3 เวอร์ชัน: ทีม QA สามารถเรียกใช้การทดสอบด้วยตนเองหรืออัตโนมัติโดยใช้เวอร์ชันหนึ่ง จากนั้นรีบูตเป็นเวอร์ชันอื่นและรันการทดสอบอีกครั้ง จากนั้นเปรียบเทียบผลลัพธ์สุดท้าย
  • ติดตั้งกล้อง HAL ผู้จำหน่าย APEX 2 เวอร์ชัน เวอร์ชัน ปัจจุบัน และ เวอร์ชันทดลอง : ผู้ Dogfood สามารถใช้เวอร์ชันทดลองได้โดยไม่ต้องดาวน์โหลดและติดตั้งไฟล์เพิ่มเติม ดังนั้นจึงสามารถสลับกลับได้อย่างง่ายดาย

ในระหว่างการบูทเครื่อง apexd จะค้นหา sysprops ที่เป็นไปตามรูปแบบเฉพาะเพื่อเปิดใช้งานเวอร์ชัน APEX ที่ถูกต้อง

รูปแบบที่คาดหวังสำหรับคีย์คุณสมบัติคือ:

  • บูตคอนฟิก
    • ใช้เพื่อตั้งค่าเริ่มต้นใน BoardConfig.mk
    • androidboot.vendor.apex.<apex name>
  • ระบบซิสพรอพแบบถาวร
    • ใช้เพื่อเปลี่ยนค่าเริ่มต้น ตั้งค่าบนอุปกรณ์ที่บู๊ตแล้ว
    • แทนที่ค่า bootconfig หากมี
    • persist.vendor.apex.<apex name>

ค่าของคุณสมบัติควรเป็นชื่อไฟล์ของ APEX ที่ควรเปิดใช้งาน

// Default version.
apex {
  name: "com.oem.camera.hal.my_apex_default",
  vendor: true,
  ..
}

// Non-default version.
apex {
  name: "com.oem.camera.hal.my_apex_experimental",
  vendor: true,
  ..
}

ควรกำหนดค่าเวอร์ชันเริ่มต้นโดยใช้ bootconfig ใน BoardConfig.mk :

# Example for APEX "com.oem.camera.hal" with the default above:
BOARD_BOOTCONFIG += \
    androidboot.vendor.apex.com.oem.camera.hal=com.oem.camera.hal.my_apex_default

หลังจากบูตอุปกรณ์แล้ว ให้เปลี่ยนเวอร์ชันที่เปิดใช้งานโดยการตั้งค่า sysprop แบบถาวร:

$ adb root;
$ adb shell setprop \
    persist.vendor.apex.com.oem.camera.hal \
    com.oem.camera.hal.my_apex_experimental;
$ adb reboot;

หากอุปกรณ์รองรับการอัปเดต bootconfig หลังจากแฟลช (เช่น ผ่านคำสั่ง fastboot oem ) การเปลี่ยนคุณสมบัติ bootconfig สำหรับ APEX ที่ติดตั้งหลายตัวจะเปลี่ยนเวอร์ชันที่เปิดใช้งานขณะบู๊ตเครื่องด้วย

สำหรับอุปกรณ์อ้างอิงเสมือนที่ใช้ Cuttlefish คุณสามารถใช้คำสั่ง --extra_bootconfig_args เพื่อตั้งค่าคุณสมบัติ bootconfig ได้โดยตรงในขณะที่เปิดใช้งาน ตัวอย่างเช่น:

launch_cvd --noresume \
  --extra_bootconfig_args "androidboot.vendor.apex.com.oem.camera.hal:=com.oem.camera.hal.my_apex_experimental";