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