ConfigStore HAL

Android 8.0 แยกเสาหิน Android OS เข้าทั่วไป ( system.img ) และฮาร์ดแวร์ที่เฉพาะเจาะจง ( vendor.img และ odm.img ) พาร์ทิชัน ผลจากการเปลี่ยนแปลงนี้ ต้องลบการคอมไพล์แบบมีเงื่อนไขออกจากโมดูลที่ติดตั้งในพาร์ติชันระบบ และโมดูลดังกล่าวต้องกำหนดคอนฟิกูเรชันของระบบ ณ รันไทม์ (และทำงานแตกต่างกันขึ้นอยู่กับคอนฟิกูเรชันนั้น)

ConfigStore HAL จัดเตรียมชุดของ API สำหรับการเข้าถึงรายการการกำหนดค่าแบบอ่านอย่างเดียวที่ใช้ในการกำหนดค่ากรอบงาน Android หน้านี้อธิบายการออกแบบ ConfigStore HAL (และเหตุใดจึงไม่ใช้คุณสมบัติของระบบเพื่อจุดประสงค์นี้) หน้าอื่น ๆ ในรายละเอียดส่วนนี้ อินเตอร์เฟซฮาล , การดำเนินการให้บริการ และ การใช้งานฝั่งไคลเอ็นต์ ทั้งหมดใช้ surfaceflinger เป็นตัวอย่าง สำหรับความช่วยเหลือ ConfigStore เรียนอินเตอร์เฟซที่ดู การเพิ่มชั้นเรียนอินเตอร์เฟซและรายการ

ทำไมไม่ใช้คุณสมบัติของระบบ?

เราพิจารณาใช้คุณสมบัติของระบบแต่พบปัญหาพื้นฐานหลายประการ ได้แก่:

  • จำกัดความยาวของค่า คุณสมบัติของระบบมีขีดจำกัดความยาวของค่าอย่างเข้มงวด (92 ไบต์) นอกจากนี้ เนื่องจากข้อจำกัดเหล่านี้ได้เปิดเผยโดยตรงกับแอป Android เป็นมาโคร C การเพิ่มความยาวอาจทำให้เกิดปัญหาความเข้ากันได้แบบย้อนหลัง
  • ไม่มีการสนับสนุนประเภท ค่าทั้งหมดเป็นหลักสตริงและ API เพียงแค่แยกสตริงเป็น int หรือ bool ชนิดข้อมูลสารประกอบอื่น ๆ (เช่นอาร์เรย์และ struct) ควรจะเข้ารหัส / ถอดรหัสโดยลูกค้า (ตัวอย่างเช่น "aaa,bbb,ccc" สามารถกำหนดเป็นอาร์เรย์ของสามสตริง)
  • เขียนทับ เนื่องจากคุณสมบัติของระบบแบบอ่านอย่างเดียวถูกนำไปใช้เป็นคุณสมบัติการเขียนครั้งเดียว ผู้ขาย/ODM ที่ต้องการแทนที่ค่าแบบอ่านอย่างเดียวที่กำหนดโดย AOSP ต้องนำเข้าค่าแบบอ่านอย่างเดียวของตนเองก่อนค่าแบบอ่านอย่างเดียวที่กำหนดโดย AOSP ในทางกลับกัน ส่งผลให้ค่าที่เขียนซ้ำได้ที่กำหนดโดยผู้ขายถูกแทนที่ด้วยค่าที่กำหนดโดย AOSP
  • ระบุความต้องการพื้นที่ คุณสมบัติของระบบใช้พื้นที่ที่อยู่ค่อนข้างมากในแต่ละกระบวนการ คุณสมบัติของระบบจะถูกจัดกลุ่มใน prop_area หน่วยที่มีขนาดคงที่ 128 กิโลไบต์ซึ่งทั้งหมดจะถูกจัดสรรไปยังพื้นที่ที่อยู่กระบวนการแม้เพียงสถานที่ให้บริการระบบเดียวในนั้นมีการเข้าถึง ซึ่งอาจทำให้เกิดปัญหากับอุปกรณ์ 32 บิตซึ่งพื้นที่ที่อยู่มีค่ามาก

เราพยายามเอาชนะข้อจำกัดเหล่านี้โดยไม่ลดทอนความเข้ากันได้ แต่ยังคงกังวลว่าคุณสมบัติของระบบไม่ได้ออกแบบมาเพื่อรองรับการเข้าถึงรายการการกำหนดค่าแบบอ่านอย่างเดียว ในที่สุด เราก็ตัดสินใจว่าคุณสมบัติของระบบเหมาะสมกว่าสำหรับการแชร์รายการที่อัปเดตแบบไดนามิกบางรายการใน Android ทั้งหมดแบบเรียลไทม์ และจำเป็นต้องมีสำหรับระบบใหม่ที่ทุ่มเทให้กับการเข้าถึงรายการการกำหนดค่าแบบอ่านอย่างเดียว

การออกแบบ ConfigStore HAL

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

การออกแบบ Configstore HAL

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

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

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

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

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