ב-Android 10, ConfigStore HAL משתמש בדגלי build כדי לאחסן ערכי הגדרה במחיצה vendor, ושירות במחיצה system ניגש לערכים האלה באמצעות HIDL (זה נכון גם ב-Android 9). עם זאת, בגלל צריכת זיכרון גבוהה ושימוש מסובך, ה-HAL של ConfigStore הוצא משימוש.
ה-HAL של ConfigStore נשאר ב-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) ולמכשיר עבור דגלי build על ידי הטמעה של שירות HAL.
- משנים את המסגרת כך שתשתמש בשירות HAL כדי למצוא את הערך של פריט הגדרה בזמן ריצה.
פריטי ההגדרה שאליהם יש כרגע הפניות במסגרת העבודה כלולים בחבילת HIDL עם ניהול גרסאות (android.hardware.configstore@1.0). ספקים או יצרני ציוד מקורי (OEM) מספקים ערכים לפריטי ההגדרה על ידי הטמעה של ממשקים בחבילה הזו, ומסגרת העבודה משתמשת בממשקים כשהיא צריכה לקבל ערך לפריט הגדרה.
שיקולי אבטחה
הגדרות build שמוגדרות באותו ממשק מושפעות מאותה מדיניות SELinux. אם לדגלי build מסוימים צריכות להיות מדיניות SELinux שונה, צריך להפריד אותם לממשק אחר. יכול להיות שיהיה צורך לבצע שינויים משמעותיים ב-android.hardware.configstore package כי הממשקים הנפרדים כבר לא תואמים לגרסאות קודמות.