ใน Android 10 ConfigStore HAL ใช้แฟล็กบิลด์เพื่อจัดเก็บค่าการกำหนดค่าในพาร์ติชัน vendor
และบริการในพาร์ติชัน system
จะเข้าถึงค่าเหล่านั้นโดยใช้ HIDL (ซึ่งก็เป็นจริงใน Android 9 เช่นกัน) อย่างไรก็ตาม เนื่องจากการใช้หน่วยความจำสูงและการใช้งานที่ยากลำบาก ConfigStore HAL จึงเลิกใช้แล้ว
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"
สามารถเข้ารหัสเป็นอาร์เรย์สามสายได้) - เขียนทับ เนื่องจากคุณสมบัติของระบบแบบอ่านอย่างเดียวถูกนำมาใช้เป็นคุณสมบัติการเขียนครั้งเดียว ผู้จำหน่าย/ODM ที่ต้องการแทนที่ค่าแบบอ่านอย่างเดียวที่กำหนดโดย AOSP จะต้องนำเข้าค่าแบบอ่านอย่างเดียวของตนเองก่อนค่าแบบอ่านอย่างเดียวที่กำหนดโดย AOSP ซึ่งในทางกลับกัน ส่งผลให้ค่าที่เขียนซ้ำได้ที่กำหนดโดยผู้จำหน่ายถูกแทนที่โดยค่าที่กำหนดโดย AOSP
- ที่อยู่ความต้องการพื้นที่ คุณสมบัติของระบบใช้พื้นที่ที่อยู่ค่อนข้างมากในแต่ละกระบวนการ คุณสมบัติของระบบถูกจัดกลุ่มในหน่วย
prop_area
ที่มีขนาดคงที่ 128 KB ซึ่งทั้งหมดจะถูกจัดสรรให้กับพื้นที่แอดเดรสของกระบวนการ แม้ว่าจะมีการเข้าถึงคุณสมบัติระบบเดียวในนั้นก็ตาม ซึ่งอาจทำให้เกิดปัญหากับอุปกรณ์ 32 บิตซึ่งพื้นที่ที่อยู่มีค่า
เราพยายามที่จะเอาชนะข้อจำกัดเหล่านี้โดยไม่สูญเสียความเข้ากันได้ แต่ยังคงกังวลว่าคุณสมบัติของระบบไม่ได้ออกแบบมาเพื่อรองรับการเข้าถึงรายการการกำหนดค่าแบบอ่านอย่างเดียว ในที่สุดเราก็ตัดสินใจว่าคุณสมบัติของระบบเหมาะสมกว่าสำหรับการแชร์รายการที่อัปเดตแบบไดนามิกบางรายการใน Android ทั้งหมดแบบเรียลไทม์ และจำเป็นต้องมีระบบใหม่ที่มีไว้สำหรับการเข้าถึงรายการการกำหนดค่าแบบอ่านอย่างเดียวโดยเฉพาะ
การออกแบบ ConfigStore HAL
การออกแบบพื้นฐานนั้นเรียบง่าย:
รูปที่ 1 การออกแบบ ConfigStore HAL
- อธิบายบิลด์แฟล็ก (ปัจจุบันใช้สำหรับคอมไพล์เฟรมเวิร์กแบบมีเงื่อนไข) ใน HIDL
- ผู้จัดจำหน่ายและ OEM จัดเตรียม SoC และค่าเฉพาะอุปกรณ์สำหรับการสร้างแฟล็กโดยการใช้บริการ HAL
- ปรับเปลี่ยนกรอบงานเพื่อใช้บริการ HAL เพื่อค้นหาค่าของรายการการกำหนดค่าขณะรันไทม์
รายการการกำหนดค่าที่อ้างอิงโดยเฟรมเวิร์กในปัจจุบันจะรวมอยู่ในแพ็คเกจ HIDL เวอร์ชัน ( android.hardware.configstore@1.0
) ผู้จัดจำหน่าย/OEM จัดเตรียมค่าให้กับรายการการกำหนดค่าโดยการใช้อินเทอร์เฟซในแพ็คเกจนี้ และกรอบงานใช้อินเทอร์เฟซเมื่อจำเป็นต้องรับค่าสำหรับรายการการกำหนดค่า
ข้อควรพิจารณาด้านความปลอดภัย
แฟล็กบิวด์ที่กำหนดในอินเทอร์เฟซเดียวกันจะได้รับผลกระทบจากนโยบาย SELinux เดียวกัน หากแฟล็กบิวด์อย่างน้อยหนึ่งรายการควรมีนโยบาย SELinux ที่แตกต่างกัน แฟล็กเหล่านั้นจะต้องถูกแยกไปยังอินเทอร์เฟซอื่น ซึ่งอาจต้องมีการแก้ไขครั้งใหญ่ของ android.hardware.configstore package
เนื่องจากอินเทอร์เฟซที่แยกจากกันไม่สามารถเข้ากันได้แบบย้อนหลังอีกต่อไป