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 เนื่องจากอินเทอร์เฟซที่แยกจากกันไม่สามารถเข้ากันได้แบบย้อนหลังอีกต่อไป