ConfigStore HAL

ใน 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

การออกแบบพื้นฐานนั้นเรียบง่าย:

การออกแบบ Configstore HAL

รูปที่ 1 การออกแบบ ConfigStore HAL

  • อธิบายบิลด์แฟล็ก (ปัจจุบันใช้สำหรับคอมไพล์เฟรมเวิร์กแบบมีเงื่อนไข) ใน HIDL
  • ผู้จัดจำหน่ายและ OEM จัดเตรียม SoC และค่าเฉพาะอุปกรณ์สำหรับการสร้างแฟล็กโดยการใช้บริการ HAL
  • ปรับเปลี่ยนกรอบงานเพื่อใช้บริการ HAL เพื่อค้นหาค่าของรายการการกำหนดค่าขณะรันไทม์

รายการการกำหนดค่าที่อ้างอิงโดยเฟรมเวิร์กในปัจจุบันจะรวมอยู่ในแพ็คเกจ HIDL เวอร์ชัน ( android.hardware.configstore@1.0 ) ผู้จัดจำหน่าย/OEM จัดเตรียมค่าให้กับรายการการกำหนดค่าโดยการใช้อินเทอร์เฟซในแพ็คเกจนี้ และกรอบงานใช้อินเทอร์เฟซเมื่อจำเป็นต้องรับค่าสำหรับรายการการกำหนดค่า

ข้อควรพิจารณาด้านความปลอดภัย

แฟล็กบิวด์ที่กำหนดในอินเทอร์เฟซเดียวกันจะได้รับผลกระทบจากนโยบาย SELinux เดียวกัน หากแฟล็กบิวด์อย่างน้อยหนึ่งรายการควรมีนโยบาย SELinux ที่แตกต่างกัน แฟล็กเหล่านั้นจะต้องถูกแยกไปยังอินเทอร์เฟซอื่น ซึ่งอาจต้องมีการแก้ไขครั้งใหญ่ของ android.hardware.configstore package เนื่องจากอินเทอร์เฟซที่แยกจากกันไม่สามารถเข้ากันได้แบบย้อนหลังอีกต่อไป