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