ใน Android 10 นั้น ConfigStore HAL จะใช้ Flag การสร้างเพื่อจัดเก็บค่าการกําหนดค่าในพาร์ติชัน vendor และบริการในพาร์ติชัน system จะเข้าถึงค่าเหล่านั้นโดยใช้ HIDL (ซึ่งใน Android 9 ก็ใช้วิธีเดียวกันนี้) อย่างไรก็ตาม HAL ของ ConfigStore ถูกเลิกใช้งานแล้วเนื่องจากมีการใช้หน่วยความจําสูงและใช้งานยาก
ConfigStore HAL จะยังคงอยู่ใน AOSP เพื่อรองรับพาร์ติชันเดิมของผู้ให้บริการ ในอุปกรณ์ที่ใช้ Android 10 ขึ้นไป surfaceflingerจะอ่านพร็อพเพอร์ตี้ของระบบก่อน หากไม่ได้กำหนดพร็อพเพอร์ตี้ของระบบสำหรับรายการการกําหนดค่าใน `SurfaceFlingerProperties.sysprop` ไว้ `surfaceflinger` จะกลับไปใช้ ConfigStore HAL
Android 8.0 แบ่งระบบปฏิบัติการ Android แบบโมโนลิธเป็นพาร์ติชันทั่วไป (system.img) และพาร์ติชันเฉพาะฮาร์ดแวร์ (vendor.img และ odm.img) การเปลี่ยนแปลงนี้ส่งผลให้ต้องนําการคอมไพล์แบบมีเงื่อนไขออกจากโมดูลที่ติดตั้งลงในพาร์ติชันระบบ และโมดูลดังกล่าวต้องกําหนดการกําหนดค่าของระบบขณะรันไทม์ (และทํางานแตกต่างกันไปตามการกําหนดค่านั้น)
ConfigStore HAL มีชุด API สำหรับเข้าถึงรายการการกำหนดค่าแบบอ่านอย่างเดียวที่ใช้ในการกำหนดค่าเฟรมเวิร์ก Android หน้านี้อธิบายการออกแบบ ConfigStore HAL (และเหตุผลที่ไม่ได้ใช้พร็อพเพอร์ตี้ของระบบเพื่อวัตถุประสงค์นี้) ส่วนหน้าอื่นๆ ในส่วนนี้จะอธิบายรายละเอียดเกี่ยวกับอินเทอร์เฟซ HAL, การติดตั้งใช้งานบริการ และการใช้งานฝั่งไคลเอ็นต์ โดยทั้งหมดนี้ใช้ surfaceflinger เป็นตัวอย่าง หากต้องการความช่วยเหลือเกี่ยวกับคลาสอินเทอร์เฟซ ConfigStore โปรดดูการเพิ่มคลาสและรายการอินเทอร์เฟซ
เหตุผลที่ไม่ควรใช้พร็อพเพอร์ตี้ของระบบ
เราพิจารณาใช้พร็อพเพอร์ตี้ของระบบ แต่พบปัญหาพื้นฐานหลายประการ ซึ่งรวมถึงปัญหาต่อไปนี้
- ขีดจํากัดความยาวของค่า พร็อพเพอร์ตี้ของระบบมีขีดจํากัดที่เข้มงวดเกี่ยวกับความยาวของค่า (92 ไบต์) นอกจากนี้ เนื่องจากขีดจํากัดเหล่านี้แสดงในแอป Android โดยตรงในรูปแบบมาโคร C การเพิ่มความยาวอาจทําให้เกิดปัญหาความเข้ากันได้ย้อนหลัง
- ไม่รองรับประเภท โดยพื้นฐานแล้ว ค่าทั้งหมดคือสตริง และ API จะแยกวิเคราะห์สตริงเป็น
intหรือboolประเภทข้อมูลคอมโพเนนต์อื่นๆ (เช่น อาร์เรย์และโครงสร้าง) ควรได้รับการเข้ารหัส/ถอดรหัสโดยไคลเอ็นต์ (เช่น"aaa,bbb,ccc"สามารถเข้ารหัสเป็นอาร์เรย์สตริง 3 รายการ) - การเขียนทับ เนื่องจากพร็อพเพอร์ตี้ระบบแบบอ่านอย่างเดียวมีการใช้งานเป็นพร็อพเพอร์ตี้แบบเขียนได้ครั้งเดียว ผู้ให้บริการ/ODM ที่ต้องการลบล้างค่าแบบอ่านอย่างเดียวที่ AOSP กำหนดต้องนำเข้าค่าแบบอ่านอย่างเดียวของตนเองก่อนค่าแบบอ่านอย่างเดียวที่ AOSP กำหนด ซึ่งส่งผลให้ค่าที่เขียนซ้ำได้ซึ่งกำหนดโดยผู้ให้บริการถูกลบล้างโดยค่าที่ AOSP กำหนด
- ข้อกำหนดเกี่ยวกับพื้นที่ที่อยู่ พร็อพเพอร์ตี้ของระบบจะใช้พื้นที่ที่อยู่ค่อนข้างมากในแต่ละกระบวนการ พร็อพเพอร์ตี้ระบบจัดกลุ่มเป็น
prop_areaหน่วยที่มีขนาดคงที่ 128 KB โดยทั้งหมดจะได้รับการจัดสรรให้กับพื้นที่ของที่อยู่กระบวนการแม้ว่าจะเข้าถึงพร็อพเพอร์ตี้ระบบเพียงรายการเดียวในพร็อพเพอร์ตี้นั้นก็ตาม ซึ่งอาจทำให้เกิดปัญหาในอุปกรณ์ 32 บิตที่มีพื้นที่ที่อยู่จํากัด
เราพยายามที่จะเอาชนะข้อจํากัดเหล่านี้โดยไม่เสียความสามารถในการใช้งานร่วมกัน แต่ยังคงกังวลว่าพร็อพเพอร์ตี้ระบบไม่ได้ออกแบบมาเพื่อรองรับการเข้าถึงรายการการกําหนดค่าที่อ่านอย่างเดียว ในที่สุดเราก็ตัดสินใจว่าพร็อพเพอร์ตี้ของระบบเหมาะที่จะแชร์รายการที่อัปเดตแบบไดนามิกเพียงไม่กี่รายการใน Android ทั้งหมดแบบเรียลไทม์มากกว่า และจำเป็นต้องมีระบบใหม่ที่เจาะจงสำหรับการเข้าถึงรายการการกำหนดค่าที่อ่านอย่างเดียว
การออกแบบ HAL ของ ConfigStore
การออกแบบพื้นฐานนั้นง่ายมาก
รูปที่ 1 การออกแบบ HAL ของ ConfigStore
- อธิบาย Flag การสร้าง (ปัจจุบันใช้สำหรับคอมไพล์เฟรมเวิร์กแบบมีเงื่อนไข) ใน HIDL
- ผู้ให้บริการและ OEM จะระบุค่าสำหรับ SoC และอุปกรณ์โดยเฉพาะสำหรับ Flag การสร้างด้วยการติดตั้งใช้งานบริการ HAL
- แก้ไขเฟรมเวิร์กให้ใช้บริการ HAL เพื่อค้นหาค่าของรายการการกําหนดค่าที่รันไทม์
รายการการกําหนดค่าที่เฟรมเวิร์กอ้างอิงอยู่ในปัจจุบันจะรวมอยู่ในแพ็กเกจ HIDL ที่มีเวอร์ชัน (android.hardware.configstore@1.0) ผู้ให้บริการ/OEM จะระบุค่าให้กับรายการการกําหนดค่าด้วยการใช้อินเทอร์เฟซในแพ็กเกจนี้ และเฟรมเวิร์กจะใช้อินเทอร์เฟซเมื่อต้องการรับค่าสําหรับรายการการกําหนดค่า
ข้อควรพิจารณาด้านความปลอดภัย
Flag การสร้างที่กําหนดในอินเทอร์เฟซเดียวกันจะได้รับผลกระทบจากนโยบาย SELinux เดียวกัน หาก Flag การสร้างอย่างน้อย 1 รายการควรมีนโยบาย SELinux ที่แตกต่างกัน Flag ดังกล่าวต้องแยกไปยังอินเทอร์เฟซอื่น กรณีนี้อาจต้องมีการแก้ไขหลัก android.hardware.configstore package เนื่องจากอินเทอร์เฟซที่แยกกันใช้งานย้อนหลังไม่ได้แล้ว