คุณสามารถใช้ รูปแบบไฟล์ 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 ของผู้จำหน่าย และอื่นๆ อีกมากมายที่กำลังถูกเพิ่มเข้ามา
ตัวอย่าง:
- XML การประกาศคุณลักษณะ
- เซ็นเซอร์มีคุณลักษณะ XML ที่ สร้างไว้ล่วงหน้าใน APEX ผู้จำหน่ายเซ็นเซอร์ HAL
- อินพุตไฟล์กำหนดค่า
- หน้าจอสัมผัสกำหนดค่าเป็น ที่สร้างไว้ล่วงหน้าใน 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 ของผู้จำหน่าย และอื่นๆ อีกมากมายที่กำลังถูกเพิ่มเข้ามา
ตัวอย่าง:
- XML การประกาศคุณลักษณะ
- เซ็นเซอร์มีคุณลักษณะ XML ที่ สร้างไว้ล่วงหน้าใน APEX ผู้จำหน่ายเซ็นเซอร์ HAL
- อินพุตไฟล์กำหนดค่า
- หน้าจอสัมผัสกำหนดค่าเป็น ที่สร้างไว้ล่วงหน้าใน 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 ของผู้จำหน่าย และอื่นๆ อีกมากมายที่กำลังถูกเพิ่มเข้ามา
ตัวอย่าง:
- XML การประกาศคุณลักษณะ
- เซ็นเซอร์มีคุณลักษณะ XML ที่ สร้างไว้ล่วงหน้าใน APEX ผู้จำหน่ายเซ็นเซอร์ HAL
- อินพุตไฟล์กำหนดค่า
- หน้าจอสัมผัสกำหนดค่าเป็น ที่สร้างไว้ล่วงหน้าใน 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";