ConfigStore HAL

באנדרואיד 10, ConfigStore HAL משתמש בדגלי build כדי לאחסן ערכי תצורה במחיצת vendor , ושירות במחיצת system ניגש לערכים הללו באמצעות HIDL (זה נכון גם באנדרואיד 9). עם זאת, עקב צריכת זיכרון גבוהה ושימוש קשה, ה-ConfigStore HAL הוצא משימוש.

ConfigStore HAL נשאר ב-AOSP כדי לתמוך במחיצות של ספקים מדור קודם. במכשירים עם אנדרואיד 10 ואילך, surfaceflinger קורא תחילה את מאפייני המערכת; אם לא מוגדר מאפיין מערכת עבור פריט תצורה ב- `SurfaceFlingerProperties.sysprop`, `surfaceflinger` נופל בחזרה ל-ConfigStore HAL.

אנדרואיד 8.0 מפצלת את מערכת ההפעלה אנדרואיד המונוליטית למחיצות כלליות ( system.img ) וספציפיות לחומרה ( vendor.img ו- odm.img ). כתוצאה משינוי זה, יש להסיר קומפילציה מותנית ממודולים המותקנים במחיצת המערכת ומודולים כאלה חייבים לקבוע את תצורת המערכת בזמן הריצה (ולהתנהג אחרת בהתאם לתצורה זו).

ה-ConfigStore HAL מספק קבוצה של ממשקי API לגישה לפריטי תצורה לקריאה בלבד המשמשים להגדרת מסגרת Android. דף זה מתאר את העיצוב של ConfigStore HAL (ומדוע לא נעשה שימוש במאפייני המערכת למטרה זו); דפים אחרים בסעיף זה מפרטים את ממשק ה-HAL , הטמעת השירות והשימוש בצד הלקוח , והכל תוך שימוש surfaceflinger כדוגמה. לעזרה עם מחלקות ממשק ConfigStore, ראה הוספת מחלקות ופריטים ממשק .

למה לא להשתמש במאפייני מערכת?

שקלנו להשתמש במאפייני מערכת אך מצאנו מספר בעיות בסיסיות, כולל:

  • מגבלות אורך על ערכים. למאפייני המערכת יש מגבלות הדוקות על אורך הערכים שלהם (92 בתים). בנוסף, מכיוון שמגבלות אלו נחשפו ישירות לאפליקציות אנדרואיד כפקודות מאקרו C, הגדלת האורך עלולה לגרום לבעיות תאימות לאחור.
  • אין תמיכה בסוג. כל הערכים הם בעצם מחרוזות, וממשקי API פשוט מנתחים את המחרוזת ל- int או bool . סוגי נתונים מורכבים אחרים (לדוגמה, מערך ומבנה) צריכים להיות מקודד/פענוח על ידי הלקוחות (לדוגמה, "aaa,bbb,ccc" יכול להיות מקודד כמערך של שלוש מחרוזות).
  • מחליף. מכיוון שמאפייני מערכת לקריאה בלבד מיושמים כמאפייני כתיבה חד פעמית, ספקים/ODMs שרוצים לעקוף ערכי קריאה בלבד המוגדרים ב-AOSP חייבים לייבא ערכי קריאה בלבד משלהם לפני ערכי קריאה בלבד המוגדרים ב-AOSP. זה, בתורו, גורם לכך שערכים ניתנים לכתיבה מחדש המוגדרים על ידי הספק נדחקים על ידי ערכים המוגדרים של AOSP.
  • דרישות שטח כתובות. מאפייני מערכת לוקחים כמות גדולה יחסית של שטח כתובות בכל תהליך. מאפייני המערכת מקובצים ביחידות prop_area בגודל קבוע של 128 KB, שכולן מוקצות למרחב כתובות תהליך גם אם יש גישה רק למאפיין מערכת בודד בו. זה יכול לגרום לבעיות במכשירי 32 סיביות שבהם שטח הכתובות יקר.

ניסינו להתגבר על מגבלות אלו מבלי לוותר על תאימות, אך המשכנו להיות מודאגים מכך שמאפייני המערכת לא נועדו לתמוך בגישה לפריטי תצורה לקריאה בלבד. בסופו של דבר החלטנו שמאפייני מערכת מתאימים יותר לשיתוף כמה פריטים מעודכנים דינמית בכל אנדרואיד בזמן אמת, ושקיים צורך במערכת חדשה המיועדת לגישה לפריטי תצורה לקריאה בלבד.

עיצוב ConfigStore HAL

העיצוב הבסיסי פשוט:

עיצוב HAL של Configstore

איור 1. עיצוב ConfigStore HAL

  • תאר דגלי בנייה (המשמשים כיום להידור מותנה של המסגרת) ב-HIDL.
  • ספקים ויצרני OEM מספקים ערכים ספציפיים ל-SoC ומכשירים עבור דגלים על ידי הטמעת שירות HAL.
  • שנה את המסגרת כדי להשתמש בשירות HAL כדי למצוא את הערך של פריט תצורה בזמן ריצה.

פריטי תצורה שמתייחסים אליהם כעת על ידי המסגרת כלולים בחבילת HIDL מנוסחת ( android.hardware.configstore@1.0 ). ספקים/OEM מספקים ערכים לפריטי התצורה על ידי הטמעת ממשקים בחבילה זו, והמסגרת משתמשת בממשקים כאשר היא צריכה לקבל ערך עבור פריט תצורה.

שיקולי אבטחה

דגלי בנייה המוגדרים באותו ממשק מושפעים מאותה מדיניות SELinux. אם לדגל בנייה אחד או יותר צריכים להיות מדיניות SELinux שונה, יש להפריד אותם לממשק אחר . זה עשוי לדרוש עדכון גדול של android.hardware.configstore package מכיוון שהממשקים המופרדים אינם תואמים עוד לאחור.