AOSP มีตัวเลือกต่อไปนี้สำหรับการจัดเก็บข้อมูลการกำหนดค่าในอุปกรณ์
- พร็อพเพอร์ตี้ของระบบ
- การกำหนดค่าอุปกรณ์สำหรับการเปิดเครื่องก่อนกำหนด
- พร็อพเพอร์ตี้ของ Hardware Abstraction Layer (HAL)
- ไฟล์ XML การกำหนดค่าระบบ
- การซ้อนทับทรัพยากร (แบบคงที่และรันไทม์)
พร็อพเพอร์ตี้ของระบบ
พร็อพเพอร์ตี้ของระบบคือคู่คีย์/ค่าสตริงที่จัดเก็บไว้ในbuild.prop
พจนานุกรมส่วนกลาง พร็อพเพอร์ตี้ของระบบคือทรัพยากรทั่วทั้งระบบที่ใช้งานง่ายและมีค่าใช้จ่ายด้านประสิทธิภาพต่ำ
เมื่อใช้พร็อพเพอร์ตี้ของระบบ คุณไม่จำเป็นต้องใช้การสื่อสารระหว่างโปรเซส (IPC) แม้ว่าพร็อพเพอร์ตี้ของระบบจะแชร์ในหลายกระบวนการก็ตาม อย่างไรก็ตาม พร็อพเพอร์ตี้ของระบบคล้ายกับตัวแปรส่วนกลาง
และอาจเป็นอันตรายได้หากใช้ในทางที่ผิด การใช้พร็อพเพอร์ตี้ของระบบในทางที่ผิดอาจ
ส่งผลให้เกิดปัญหาต่างๆ เช่น ช่องโหว่ด้านความปลอดภัย และแอปเข้าถึงไม่ได้
สำหรับผู้ใช้ โปรดพิจารณาตัวเลือกการกำหนดค่าอื่นๆ ก่อนใช้พร็อพเพอร์ตี้ของระบบเพื่อจัดเก็บข้อมูลการกำหนดค่า
ดูข้อมูลเพิ่มเติมเกี่ยวกับพร็อพเพอร์ตี้ของระบบได้ที่ เพิ่มพร็อพเพอร์ตี้ของระบบ
การกำหนดค่าอุปกรณ์สำหรับการเปิดเครื่องก่อนกำหนด
ใน Android 17 ขึ้นไป บริการ init_dev_config จะรองรับ
การกำหนดค่าอุปกรณ์และการเริ่มต้นพร็อพเพอร์ตี้ของระบบ กลไกสถาปัตยกรรมแบบไดนามิกนี้จะทำงานโดยอัตโนมัติเมื่อบูตเครื่องในช่วงแรก
เมื่อรูปภาพระบบหรือรูปภาพของผู้ให้บริการรายเดียวต้องรองรับฮาร์ดแวร์หลายรุ่น
ค่าการกำหนดค่าจะฮาร์ดโค้ดในเวลาบิลด์ไม่ได้เสมอไป บริการ
init_dev_config จะทำงานในระยะearly-init ก่อนapexd-bootstrap
ทันที เพื่อให้ผู้ให้บริการตรวจสอบสถานะฮาร์ดแวร์ (เช่น จาก
อาร์กิวเมนต์ของ Bootloader, พาร์ติชันที่ติดตั้งก่อน หรือตารางการกำหนดค่าฮาร์ดแวร์
) และเริ่มต้นพร็อพเพอร์ตี้ของระบบแบบไดนามิกก่อนที่จะเริ่มต้นบริการและไลบรารีที่ขึ้นต่อกัน
การผสานรวมและวงจรของบริการ
ระบบจะกำหนดบริการ init_dev_config โดยค่าเริ่มต้นในระบบ
init.rc และดำเนินการพร้อมกันในระหว่าง early-init ก่อน apexd-bootstrap ผู้ให้บริการอินเทอร์เกรตไม่จำเป็นต้องประกาศบริการ init ใหม่
แต่บริการที่มีอยู่จะใช้การขยายพร็อพเพอร์ตี้ในเส้นทางที่เรียกใช้งานได้
โดยแยกการประกาศบริการของระบบออกจากไบนารีของผู้ให้บริการ ผู้ผสานรวม
ระบุเส้นทางไปยังไบนารีของผู้ให้บริการโดยใช้พร็อพเพอร์ตี้
ro.vendor.init_dev_config.path และกำหนดค่าด้วย
ป้ายกำกับและสิทธิ์ SELinux ที่จำเป็น
ข้อกำหนดในการใช้งานของผู้ให้บริการ
วิธีผสานรวมกับ init_dev_config
กำหนดค่าเส้นทางไบนารีของผู้ให้บริการในเวลาบิลด์โดยใช้
PRODUCT_VENDOR_PROPERTIESเส้นทางไบนารีที่ระบุต้องเป็นเส้นทางที่ถูกต้องไปยัง ไบนารีที่ติดตั้งในระบบPRODUCT_VENDOR_PROPERTIES += \ ro.vendor.init_dev_config.path=/vendor/bin/init_dev_configหากไม่ได้ตั้งค่าพร็อพเพอร์ตี้นี้
initจะข้ามการดำเนินการบริการและดำเนินการบูตต่อ ตามปกติเนื่องจากบริการทำงานก่อน
apexd-bootstrapไลบรารี Bionic ที่ APEX จัดหาให้ทั้งหมดจึงยังไม่พร้อมใช้งาน ในAndroid.bpให้ตั้งค่าbootstrap: trueดังนี้rust_binary { name: "init_dev_config", vendor: true, srcs: ["src/main.rs"], rustlibs: [ "librustutils", ], bootstrap: true, }เขียนตรรกะของบริการเพื่อตรวจหาสินค้าย่อยของฮาร์ดแวร์และตั้งค่าพร็อพเพอร์ตี้ของระบบที่เหมาะสม
use rustutils::system_properties; fn main() { let hw_sku = read_hardware_sku(); // Dynamically initialize vendor-specific properties: let display_type = match hw_sku { 1 => "oled", _ => "lcd", }; system_properties::write("vendor.display.panel_type", display_type) .expect("Failed to set vendor display property"); }ติดป้ายกำกับไบนารีของผู้ให้บริการด้วย
init_dev_config_exec/vendor/bin/init_dev_config u:object_r:init_dev_config_exec:s0ให้สิทธิ์โดเมน
init_dev_configเพื่อตั้งค่าพร็อพเพอร์ตี้ประเภทที่จำเป็นset_prop(init_dev_config, vendor_my_sku_prop)
ดูข้อมูลเกี่ยวกับการใช้ init_dev_config เพื่อเปิดใช้งานและปิดใช้ APEX ได้ที่การเลือก APEX ของผู้ให้บริการเมื่อเริ่มต้นระบบ
พร็อพเพอร์ตี้ HAL
เมื่อแหล่งข้อมูลที่เชื่อถือได้สำหรับการกำหนดค่ามาจากคอมโพเนนต์ฮาร์ดแวร์ในอุปกรณ์ HAL สำหรับฮาร์ดแวร์ต้องให้ข้อมูลสำหรับคอมโพเนนต์นั้น กำหนดเมธอด HAL ใหม่ใน HAL ที่มีอยู่เพื่อเข้าถึง การกำหนดค่า ดูข้อมูลเพิ่มเติมเกี่ยวกับการพัฒนา HAL ได้ที่ AIDL สำหรับ HAL
ไฟล์ XML การกำหนดค่าระบบ
เมื่อข้อมูลการกำหนดค่าเป็นแบบคงที่แต่ซับซ้อน (มีโครงสร้าง) ให้พิจารณา
ใช้ XML หรือรูปแบบอื่นๆ ที่คล้ายกันสำหรับข้อมูลการกำหนดค่า ตรวจสอบว่าสคีมาไฟล์ยังคงเสถียร สำหรับไฟล์ XML คุณสามารถใช้
xsd_config
เพื่อให้สคีมามีความเสถียร และใช้ประโยชน์จากตัวแยกวิเคราะห์ XML ที่สร้างขึ้นโดยอัตโนมัติ
การซ้อนทับทรัพยากร
คุณสามารถใช้การซ้อนทับทรัพยากรเพื่อปรับแต่งผลิตภัณฑ์ได้ การซ้อนทับทรัพยากรมี 2 ประเภท ได้แก่
การวางซ้อนทรัพยากรมาตรฐานที่ใช้ในการปรับแต่งผลิตภัณฑ์ในเวลาบิลด์ ดูข้อมูลเกี่ยวกับการวางซ้อนทรัพยากรมาตรฐานได้ที่การปรับแต่งบิลด์ด้วยการวางซ้อนทรัพยากร
การซ้อนทับทรัพยากรรันไทม์ (RRO) ใช้เพื่อเปลี่ยนค่าทรัพยากร ของแพ็กเกจเป้าหมายขณะรันไทม์ เช่น แอปที่ติดตั้งในอิมเมจระบบ อาจเปลี่ยนลักษณะการทำงานตามค่าของทรัพยากร RRO ที่ติดตั้งในพาร์ติชันอื่นจะเปลี่ยนค่าของทรัพยากรของแอปในขณะรันไทม์ได้ แทนที่จะ ฮาร์ดโค้ดค่าทรัพยากรในเวลาบิลด์ ดูข้อมูลเพิ่มเติมเกี่ยวกับ RRO ได้ที่เปลี่ยนค่าของทรัพยากรของแอปขณะรันไทม์