סקירה כללית של ההגדרה

מערכת AOSP מציעה את האפשרויות הבאות לאחסון פרטי הגדרה במכשיר:

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

מאפייני מערכת

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

מידע נוסף על מאפייני מערכת זמין במאמר בנושא הוספת מאפייני מערכת.

הגדרה של מכשיר במהלך אתחול מוקדם

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

כשדימוי מערכת או ספק יחיד צריכים לתמוך בכמה וריאציות של חומרה, לא תמיד אפשר להגדיר ערכי תצורה באופן קשיח בזמן הבנייה. שירות init_dev_config פועל במהלך שלב early-init, ממש לפני apexd-bootstrap, ומאפשר לספקים לבדוק את מצב החומרה (לדוגמה, מתוך ארגומנטים של bootloader, מחיצות שהותקנו מוקדם או טבלאות של הגדרות חומרה) ולאתחל באופן דינמי את מאפייני המערכת לפני שספריות ושירותים תלויים מאותחלים.

שילוב שירותים ומחזור חיים

השירות init_dev_config מוגדר כברירת מחדל במערכת init.rc ומופעל באופן סינכרוני במהלך early-init, לפני apexd-bootstrap. מפתחים שמשלבים את Google Pay לא צריכים להצהיר על שירות init חדש.

במקום זאת, השירות הקיים משתמש בהרחבת מאפיינים בנתיב ההפעלה שלו, ומפריד את הצהרת שירות המערכת מהקובץ הבינארי של הספק. משתמשי שילוב מציינים את הנתיב לקובץ הבינארי של הספק באמצעות המאפיין ro.vendor.init_dev_config.path, ומגדירים אותו עם התוויות וההרשאות הנדרשות של SELinux.

דרישות ההטמעה לספקים

כדי לשלב עם init_dev_config:

1. מגדירים את הנתיב הבינארי של הספק בזמן הבנייה באמצעות PRODUCT_VENDOR_PROPERTIES. הנתיב הבינארי שצוין חייב להיות נתיב תקין לקובץ בינארי שמותקן במערכת:

   PRODUCT_VENDOR_PROPERTIES += \
       ro.vendor.init_dev_config.path=/vendor/bin/init_dev_config
   

   אם המאפיין הזה לא מוגדר, init מדלג על הפעלת השירות והאתחול ממשיך כרגיל.

2. מכיוון שהשירות פועל לפני apexd-bootstrap, ספריות ה-bionic המלאות שסופקו על ידי APEX עדיין לא זמינות. ב-Android.bp, מגדירים את bootstrap: true:

   rust_binary {
       name: "init_dev_config",
       vendor: true,
       srcs: ["src/main.rs"],
       rustlibs: [
           "librustutils",
       ],
       bootstrap: true,
   }
   

3. כותבים את הלוגיקה של השירות כדי לזהות את גרסת החומרה ולהגדיר את מאפייני המערכת המתאימים:

   use rustutils::system_properties;
   
   fn main() {
       let hw_sku = read_hardware_sku();
   
       // Dynamically initialize vendor-specific properties:
       let display_type = match hw_sku {
           1 => "oled",
           _ => "lcd",
       };
       system_properties::write("vendor.display.panel_type", display_type)
           .expect("Failed to set vendor display property");
   }
   

4. מתייגים את קובץ ההרצה של הספק באמצעות init_dev_config_exec:

    /vendor/bin/init_dev_config u:object_r:init_dev_config_exec:s0
   

5. נותנים את הרשאת הדומיין init_dev_config כדי להגדיר את סוגי המאפיינים הנדרשים:

    set_prop(init_dev_config, vendor_my_sku_prop)
   

מידע על שימוש ב-init_dev_config להפעלה ולהשבתה של APEX זמין במאמר בחירת ספק APEX בעת האתחול.

מאפייני HAL

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

קובצי XML של הגדרת המערכת

אם נתוני ההגדרה סטטיים אבל מורכבים (מובנים), כדאי להשתמש ב-XML או בפורמטים דומים אחרים לנתוני ההגדרה. חשוב לוודא שסכימת הקובץ נשארת יציבה. במקרה של קובצי XML, אפשר להשתמש ב-xsd_config כדי לשמור על יציבות הסכימה, וכדי ליהנות מניתוח XML שנוצר אוטומטית.

שכבת-על של משאבים

אפשר להשתמש בשכבות-על של משאבים כדי להתאים אישית מוצר. יש שני סוגים של שכבות-על של משאבים:

• שכבת-על רגילה של משאבים שמשמשת להתאמה אישית של מוצר בזמן הבנייה. מידע על שכבות-על רגילות של משאבים זמין במאמר התאמה אישית של ה-build באמצעות שכבות-על של משאבים.

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