תמונת מערכת משותפת של Android

בדף הזה מוצגים כמה מנגנונים שיצרני ציוד מקורי (OEM) של מכשירי Android יכולים להשתמש בהם כדי ליצור תמונת מערכת משותפת (SSI) משלהם עבור קווי מוצרים שונים. המסמך גם מציע הליך ליצירת SSI בבעלות יצרן ציוד מקורי על סמך תמונת מערכת גנרית (GSI) שנבנתה על ידי AOSP.

רקע

במסגרת Project Treble, מערכת Android המונוליטית פוצלה לשני חלקים: החלק הספציפי לחומרה (ההטמעה של הספק) והחלק הכללי של מערכת ההפעלה (מסגרת מערכת ההפעלה של Android). התוכנה של כל אחד מהם מותקנת במחיצה נפרדת: מחיצת הספק לתוכנה הספציפית לחומרה, ומחיצת המערכת לתוכנת מערכת ההפעלה הגנרית. ממשק עם גרסאות, שנקרא ממשק הספק (VINTF), מוגדר ונאכף בשתי המחיצות. באמצעות מערכת החלוקה הזו, אפשר לשנות את מחיצת המערכת בלי לשנות את מחיצת הספק, ולהיפך.

מוטיבציה

קוד המסגרת שפורסם ב-AOSP תאם לארכיטקטורת Treble ושמר על תאימות לאחור עם הטמעות ישנות יותר של ספקים. לדוגמה, קובץ אימג' כללי של מערכת שנבנה ממקורות Android 10 AOSP יכול לפעול בכל מכשיר שתואם ל-Treble ומריץ Android 8 או גרסה מתקדמת יותר. גרסת Android שמופצת במכשירים לצרכנים עוברת שינוי על ידי ספקי SoC ויצרני OEM. (ראו מחזור החיים של גרסת Android). השינויים וההרחבות שבוצעו במסגרת לא נכתבו כדי לשמור על תאימות לאחור, ולכן הם הובילו למורכבות מוגברת ולעלות גבוהה יותר בשדרוג מערכת ההפעלה. שינויים והתאמות ספציפיים למכשיר מוסיפים לעלות ולמורכבות של שדרוג גרסת Android OS.

לפני Android 11 לא הייתה ארכיטקטורה ברורה שאפשרה לשותפים ליצור תוספים מודולריים למסגרת של מערכת ההפעלה Android. במסמך הזה מתוארים השלבים שיצרני מערכת על שבב (SoC) ויצרני ציוד מקורי (OEM) יכולים לבצע כדי ליצור SSI. המשמעות היא תמונה אחת, שנבנתה ממקורות של מסגרת מערכת ההפעלה של Android לשימוש חוזר בכמה מכשירים, כדי לשמור על תאימות לדורות קודמים עם הטמעות של ספקים, וכדי לספק הפחתה משמעותית במורכבות ובעלות של שדרוגים של מערכת ההפעלה של Android. בקטע השלבים המומלצים ליצירת SSI שמבוסס על GSI מפורטים השלבים הספציפיים שצריך לבצע כדי ליצור SSI. שימו לב שלא חייבים להשתמש בכל ארבעת השלבים. השלבים שתבחרו (למשל, רק שלב 1) תלויים בהטמעה שלכם.

סקירה כללית על SSI

ב-SSI, רכיבי תוכנה ספציפיים למוצר והרחבות של יצרן הציוד המקורי ממוקמים במחיצה חדשה /product. הרכיבים במחיצה /product משתמשים בממשק יציב ומוגדר היטב כדי ליצור אינטראקציה עם רכיבים במחיצה /system. יצרני ציוד מקורי יכולים לבחור ליצור SSI אחד או מספר קטן של SSI לשימוש בכמה מק"טים של מכשירים. כשגרסה חדשה של מערכת ההפעלה Android יוצאת, יצרני ציוד מקורי משקיעים רק פעם אחת בעדכון של ממשקי ה-SSI שלהם לגרסה האחרונה של Android. הם יכולים להשתמש מחדש ב-SSI כדי לעדכן כמה מכשירים בלי לעדכן את המחיצה /product.

הערה: יצרני ציוד מקורי (OEM) וספקי SoC יוצרים SSI שכוללים את כל התכונות והשינויים המותאמים אישית שנדרשים ליצרן ציוד מקורי. השיטות המומלצות והמנגנונים שמופיעים בדף הזה מיועדים ליצרני ציוד מקורי (OEM) כדי לעזור להם להשיג את היעדים העיקריים הבאים:

• שימוש חוזר ב-SSI בכמה מק"טים של מכשירים.
• עדכון מערכת Android באמצעות תוספים מודולריים כדי להקל על שדרוגי מערכת ההפעלה.

הרעיון המרכזי של הפרדת רכיבים ספציפיים למוצר למחיצת המוצר דומה לרעיון של Treble להפרדת רכיבים ספציפיים ל-SoC למחיצת הספק. ממשק מוצר (בדומה ל-VINTF) מאפשר תקשורת בין SSI לבין מחיצת המוצר. שימו לב: כשמדובר ב-SSI, המונח 'רכיבים' מתייחס לכל המשאבים, הקבצים הבינאריים, הטקסטים, הספריות וכו' שמותקנים בתמונות, שהופכות למעשה למחיצות.

מחיצות סביב SSI

איור 1 מציג מחיצות מסביב ל-SSI, וממשקים עם גרסאות שונות במחיצות ובמדיניות בממשקים. בקטע הזה מוסבר על כל אחת מהמחיצות והממשקים.

איור 1. מחיצות וממשקים שקשורים ל-SSI

תמונות ומחיצות

בקטע הזה מוסבר ההבדל בין המונחים תמונה ומחיצה.

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

הקטעים באיור 1 מוגדרים כך:

• SSI: ה-SSI היא התמונה שמשותפת ליצרן ציוד מקורי, ויכולה להיות קיימת בכמה מכשירים. היא לא כוללת רכיבים ספציפיים לחומרה או למוצר. כל מה שכלול ב-SSI נתון, בהגדרה, לשיתוף בין כל המכשירים שמשתמשים ב-SSI הזה. ה-SSI מורכב מתמונה אחת /system או ממחיצות /system ו-/system_ext, כמו שרואים באיור 1.

  • המחיצה /system מכילה רכיבים שמבוססים על AOSP, ואילו המחיצה /system_ext, אם היא מיושמת, מכילה תוספים ורכיבים של יצרני OEM וספקי SoC שמקושרים באופן הדוק לרכיבי AOSP. לדוגמה, ספריית Java framework של יצרן ציוד מקורי (OEM) שמספקת ממשקי API בהתאמה אישית לאפליקציות של היצרן מתאימה יותר למחיצה /system_ext מאשר למחיצה /system. התוכן של מחיצות /system ו-/system_ext נוצר ממקורות Android שעברו שינוי על ידי ה-OEM.

  • החלוקה /system_ext היא אופציונלית, אבל מומלץ להשתמש בה לכל התכונות והתוספים המותאמים אישית שמשולבים באופן הדוק עם רכיבים שמבוססים על AOSP. ההבחנה הזו עוזרת לכם לזהות את השינויים שצריך לבצע כדי להעביר רכיבים כאלה ממחיצת /system_ext למחיצת /product לאורך זמן.

• מוצר: אוסף של רכיבים ספציפיים למוצר או למכשיר שמייצגים התאמות אישיות ותוספים של OEM למערכת Android OS. ממקמים רכיבים ספציפיים של SoC במחיצה /vendor. ספקי SoC יכולים גם להשתמש במחיצה /product לרכיבים מתאימים, כמו רכיבים שלא תלויים ב-SoC. לדוגמה, אם ספק SoC מספק רכיב בלתי תלוי ב-SoC ללקוחות OEM שלו (שלא חייבים לשלוח עם המוצר), ספק ה-SoC יכול למקם את הרכיב הזה בתמונת המוצר. המיקום של רכיב לא נקבע לפי הבעלות עליו, אלא לפי המטרה שלו.

• ספק: אוסף של רכיבים ספציפיים ל-SoC.

• ‫ODM: אוסף של רכיבים ספציפיים ללוח שלא מסופקים על ידי ה-SoC. בדרך כלל ספק ה-SoC הוא הבעלים של תמונת הספק, ויצרן המכשיר הוא הבעלים של תמונת ה-ODM. אם אין מחיצה נפרדת של /odm, התמונות של ספק ה-SoC ושל ה-ODM ימוזגו במחיצה /vendor.

ממשקים בין תמונות

יש שני ממשקים עיקריים לתמונות של ספקים ומוצרים שקשורים ל-SSI:

• ‫Vendor Interface (VINTF): ‏ VINTF הוא הממשק לרכיבים שנמצאים בתמונות של הספק ושל ה-ODM. רכיבים בתמונות של המוצר והמערכת יכולים ליצור אינטראקציה עם תמונות הספק וה-ODM רק דרך הממשק הזה. לדוגמה, תמונה של ספק לא יכולה להיות תלויה בחלק פרטי של תמונת המערכת, ולהפך. ההגדרה הזו מופיעה במקור ב-Project Treble, שבו התמונות פוצלו למחיצות של המערכת והספק. ממשק המשתמש מתואר באמצעות המנגנונים הבאים:

  • ‫HIDL (Passthrough HAL זמין רק למודולים system ו-system_ext)
  • Stable AIDL
  • הגדרות
    • System properties API
    • Config file schema API
  • VNDK
  • ‫APIs של Android SDK
  • ספריית Java SDK

• ממשקי מוצר: ממשק המוצר הוא הממשק בין SSI לבין תמונת המוצר. הגדרת ממשק יציב מפרידה בין רכיבי המוצר לבין רכיבי המערכת ב-SSI. ממשק המוצר דורש את אותם ממשקים יציבים כמו VINTF. עם זאת, רק ממשקי ה-API של VNDK ו-Android SDK נאכפים במכשירים שמושקים עם Android מגרסה 11 (ומעלה).

הפעלת SSI ב-Android 11

בקטע הזה מוסבר איך להשתמש בתכונות החדשות שנועדו לתמוך ב-SSI ב-Android 11.

המחיצה ‎ /system_ext

מחיצת /system_ext הוצגה ב-Android 11 כמחיצה אופציונלית. (זה המקום לרכיבים שאינם AOSP, שיש להם צימוד הדוק לרכיבים שמוגדרים ב-AOSP במחיצה /system). מניחים שהמחיצה /system_ext היא הרחבה ספציפית ל-OEM של המחיצה /system, ללא ממשק שמוגדר בשתי המחיצות. רכיבים במחיצה /system_ext יכולים לשלוח קריאות פרטיות ל-API במחיצה /system, ורכיבים במחיצה /system יכולים לשלוח קריאות פרטיות ל-API במחיצה /system_ext.

מכיוון ששני החלקים קשורים זה לזה, שניהם משודרגים יחד כשגרסת Android חדשה יוצאת. מחיצת /system_ext שנוצרה עבור הגרסה הקודמת של Android לא צריכה להיות תואמת למחיצת /system בגרסה הבאה של Android.

כדי להתקין מודול במחיצה /system_ext, מוסיפים system_ext_specific: true לקובץ Android.bp. במכשירים שאין בהם מחיצה /system_ext partition, מתקינים את המודולים האלה בספריית המשנה ./system_ext במחיצה /system.

היסטוריה

הנה היסטוריה של המחיצה /system_ext. מטרת העיצוב הייתה למקם את כל הרכיבים הספציפיים ל-OEM, בין אם הם נפוצים ובין אם לא, במחיצה /product. עם זאת, לא הייתה אפשרות להעביר את כולם בבת אחת, במיוחד כשחלק מהרכיבים היו קשורים באופן הדוק למחיצה /system. כדי להעביר רכיב עם צימוד הדוק למחיצה /product, צריך להרחיב את ממשק המוצר. לרוב, נדרש שינוי נרחב של הרכיב עצמו, מה שדורש הרבה זמן ומאמץ. המחיצה /system_ext נוצרה כמקום לאירוח זמני של רכיבים שלא מוכנים להעברה למחיצה /product. המטרה של SSI הייתה לבטל בסופו של דבר את החלוקה /system_ext.

עם זאת, המחיצה /system_ext שימושית לשמירה על המחיצה /system קרובה ככל האפשר ל-AOSP. ב-SSI, רוב המאמץ שמושקע בשדרוג מוקדש לרכיבים במחיצות /system ו-/system_ext. כשקובץ האימג' של המערכת נוצר ממקורות שדומים ככל האפשר לאלה שב-AOSP, אפשר להתמקד בשדרוג של קובץ האימג' של system_ext.

פירוק רכיבים ממחיצות /system ו-/system_ext למחיצה /product

ב-Android 9 הוצגה מחיצת /product שמשולבת עם מחיצת /system. המודולים במחיצה /product משתמשים במשאבי המערכת ללא הגבלה, ולהפך. כדי לאפשר SSI ב-Android 10, רכיבי המוצר מחולקים למחיצות /system_ext ו-/product. המחיצה /system_ext לא צריכה לפעול בהתאם להגבלות על שימוש ברכיבי מערכת שהיו במחיצה /product ב-Android 9. החל מ-Android 10, צריך להפריד את המחיצה /product מהמחיצה /system ולהשתמש בממשקי API יציבים מהמחיצות /system ו-/system_ext.

המטרה העיקרית של /system_ext המחיצה היא להרחיב את תכונות המערכת, ולא להתקין מודולים של מוצרים בחבילה, כפי שמתואר בקטע /system_ext partition. כדי לעשות זאת, מבטלים את הקיבוץ של המודולים הספציפיים למוצר ומעבירים אותם למחיצה /product. הפרדת המודולים הספציפיים למוצר מאפשרת ל-/system_ext להיות משותף למכשירים. (פרטים נוספים זמינים במאמר בנושא הפיכת המחיצה /system_ext למשותפת).

כדי להפריד את מחיצת /product מרכיבי המערכת, מדיניות האכיפה של מחיצת /product צריכה להיות זהה למדיניות האכיפה של מחיצת /vendor שכבר הופרדה באמצעות Project Treble.

החל מ-Android 11, ממשקי Java וממשקים מקוריים למחיצת /product נאכפים כמו שמתואר בהמשך. מידע נוסף זמין במאמר בנושא החלת ממשקי חלוקה של מוצרים.

• ממשקי משתמש מקוריים: המודולים המקוריים במחיצה /product צריכים להיות מופרדים מהמחיצות האחרות. יחסי התלות המותרים ממודולי המוצר הם רק ספריות VNDK מסוימות (כולל LLNDK) מהמחיצה /system. ספריות JNI שאפליקציות המוצר תלויות בהן חייבות להיות ספריות NDK.
• ממשקי Java: מודולי Java (אפליקציה) במחיצה /product לא יכולים להשתמש בממשקי API מוסתרים, כי הם לא יציבים. המודולים האלה יכולים להשתמש רק בממשקי API ציבוריים ובממשקי API של המערכת מהמחיצה /system, ובספריות Java SDK במחיצה /system או /system_ext. אפשר להגדיר ספריות Java SDK לממשקי API בהתאמה אישית.

פעולות מומלצות ל-SSI שמבוסס על GSI

איור 2. מחיצות מוצעות ל-SSI שמבוסס על GSI

תמונת מערכת גנרית (GSI) היא תמונת המערכת שנבנית ישירות מ-AOSP. הוא משמש לבדיקות התאימות של Treble (לדוגמה, CTS-on-GSI) וגם כפלטפורמת הפניה שמפתחי אפליקציות יכולים להשתמש בה כדי לבדוק את התאימות של האפליקציות שלהם, אם אין להם מכשיר אמיתי שפועלת בו הגרסה הנדרשת של Android.

יצרני ציוד מקורי יכולים גם להשתמש ב-GSI כדי ליצור את ה-SSI שלהם. כמו שמוסבר במאמר תמונות ומחיצות, SSI מורכב מתמונת המערכת לרכיבים שמוגדרים ב-AOSP ומתמונת system_ext לרכיבים שמוגדרים על ידי יצרן הציוד המקורי. כשמשתמשים ב-GSI כתמונת system, יצרן הציוד המקורי יכול להתמקד בתמונת system_ext לשדרוג.

החלק הזה מיועד ליצרני ציוד מקורי (OEM) שרוצים להפוך את ההתאמות האישיות שלהם למודולריות במחיצות /system_ext ו-/product, תוך שימוש בתמונת מערכת של AOSP או של מערכת שדומה ל-AOSP. אם יצרני ציוד מקורי (OEM) יוצרים את קובץ האימג' של המערכת ממקורות AOSP, הם יכולים להחליף את קובץ האימג' של המערכת שהם יוצרים ב-GSI שסופק על ידי AOSP. עם זאת, יצרני ציוד מקורי לא צריכים להגיע לשלב הסופי (שימוש ב-GSI כמו שהוא) בבת אחת.

שלב 1. הורשה של generic_system.mk לתמונת המערכת של יצרן ציוד מקורי (OEM GSI)

על ידי ירושה generic_system.mk (שנקרא mainline_system.mk ב-Android 11, ושונה שמו ל-generic_system.mk ב-AOSP), תמונת המערכת (OEM GSI) כוללת את כל הקבצים שיש ב-AOSP GSI. יצרני ציוד מקורי יכולים לשנות את הקבצים האלה, כך שקובץ ה-GSI של יצרן הציוד המקורי יכול להכיל את הקבצים הקנייניים של יצרן הציוד המקורי בנוסף לקובצי ה-GSI של AOSP. עם זאת, יצרני ציוד מקורי לא יכולים לשנות את הקובץ generic_system.mk עצמו.

איור 3. הורשה של generic_system.mk עבור תמונת המערכת של יצרן ציוד מקורי

שלב 2. מוודאים שרשימת הקבצים ב-GSI של יצרן הציוד המקורי זהה לרשימת הקבצים ב-GSI של AOSP

בשלב הזה, ל-GSI של יצרן הציוד המקורי לא יכולים להיות קבצים נוספים. צריך להעביר את הקבצים הקנייניים של יצרן הציוד המקורי למחיצות system_ext או product.

איור 4. העברת קבצים שנוספו מחוץ ל-GSI של יצרן הציוד המקורי

שלב 3. הגדרת רשימת היתרים כדי להגביל את הקבצים שמשתנים ב-GSI של יצרן ציוד מקורי

כדי לבדוק את הקבצים ששונו, יצרני ציוד מקורי יכולים להשתמש בכלי compare_images ולהשוות בין ה-GSI של AOSP לבין ה-GSI של יצרן הציוד המקורי. מקבלים את ה-GSI של AOSP מיעד ה-lunch של AOSP‏ generic_system_*.

אם מריצים את הכלי compare_images באופן תקופתי עם הפרמטר allowlist, אפשר לעקוב אחרי ההבדלים מחוץ לרשימת ההיתרים. כך לא צריך לבצע שינויים נוספים ב-GSI של יצרן הציוד המקורי.

איור 5. הגדרה של רשימת היתרים כדי לצמצם את רשימת הקבצים ששונו ב-GSI של יצרן ציוד מקורי

שלב 4. לוודא שקובצי ה-GSI של יצרן ציוד מקורי (OEM) זהים לקובצי ה-GSI של AOSP

ניקוי הרשימה הלבנה מאפשר ליצרני ציוד מקורי להשתמש ב-GSI של AOSP כתמונת המערכת למוצרים שלהם. כדי לנקות את רשימת ההיתרים, יצרני ציוד מקורי יכולים לוותר על השינויים שלהם ב-GSI של יצרן הציוד המקורי, או להעביר את השינויים שלהם ל-AOSP כדי שה-GSI של AOSP יכלול את השינויים שלהם.

איור 6. הפיכת קובצי ה-GSI של יצרן ציוד מקורי (OEM) לקובצי בינאריים זהים לקובצי ה-GSI של AOSP

הגדרת SSI ליצרני ציוד מקורי (OEM)

הגנה על המחיצה ‎ /system בזמן הבנייה

כדי למנוע שינויים ספציפיים למוצר במחיצה /system ולהגדיר את ה-GSI של יצרן ציוד מקורי, יצרני ציוד מקורי יכולים להשתמש בפקודת מאקרו של makefile שנקראת require-artifacts-in-path כדי למנוע הצהרה על מודולים של המערכת אחרי הפעלת פקודת המאקרו. דוגמה ליצירת קובץ makefile והפעלת בדיקה של נתיב פריט המידע שנוצר בתהליך פיתוח

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

אכיפה של ממשקי מוצרים

כדי להבטיח שהמחיצה /product לא תצורף לחבילה, יצרני ציוד מקורי יכולים לוודא שהמכשירים שלהם אוכפים את ממשקי המוצר על ידי הגדרת PRODUCT_PRODUCT_VNDK_VERSION:= current למודולים מקוריים ו-PRODUCT_ENFORCE_PRODUCT_PARTITION_INTERFACE:= true למודולים של Java. המשתנים האלה מוגדרים באופן אוטומטי אם הערך של PRODUCT_SHIPPING_API_LEVEL במכשיר גדול מ-30 או שווה לו. מידע מפורט זמין במאמר בנושא החלת ממשקי חלוקת מוצרים.

הפיכת המחיצה ‎ /system_ext למשותפת

יכול להיות שהמחיצה /system_ext תהיה שונה בין מכשירים, כי היא יכולה להכיל מודולים ספציפיים למכשיר שכלולים במערכת. מכיוון שה-SSI מורכב ממחיצות /system ומחיצות /system_ext, ההבדלים במחיצת /system_ext מונעים מיצרני ציוד מקורי להגדיר SSI. יצרני ציוד מקורי יכולים להשתמש ב-SSI משלהם ולשתף אותו בין כמה מכשירים על ידי הסרת ההבדלים והפיכת מחיצת /system_ext למשותפת.

בקטע הזה מפורטות המלצות להפיכת המחיצה /system_ext למשותפת.

חשיפת ממשקי API מוסתרים במחיצת המערכת

אי אפשר להתקין הרבה אפליקציות ספציפיות למוצרים במחיצת המוצרים כי הן משתמשות בממשקי API מוסתרים, שאסור להשתמש בהם במחיצת המוצרים. כדי להעביר אפליקציות ספציפיות למכשיר למחיצת המוצר, צריך להפסיק את השימוש בממשקי API מוסתרים.

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

לחלופין, יצרני ציוד מקורי יכולים להגדיר ממשקי API בהתאמה אישית על ידי יצירת ספריית Java SDK משלהם במחיצה /system_ext. היא יכולה להשתמש בממשקי API מוסתרים במחיצת המערכת, והיא יכולה לספק את ממשקי ה-API לאפליקציות במחיצת המוצר או הספק. יצרני ציוד מקורי (OEM) צריכים להקפיא את ממשקי ה-API שפונים למוצר כדי לשמור על תאימות לדורות קודמים.

הכללת קבוצת העל של כל חבילות ה-APK ודילוג על התקנות של חבילות מסוימות לכל מכשיר

חלק מהחבילות שמצורפות למערכת לא משותפות לכל המכשירים. פירוק של מודולי ה-APK האלה כדי להעביר אותם למחיצת המוצר או הספק יכול להיות מסובך. כפתרון ביניים, יצרני ציוד מקורי יכולים לכלול את כל המודולים ב-SSI, ואז לסנן את המודולים הלא רצויים באמצעות מאפיין מק"ט (ro.boot.hardware.sku). כדי להשתמש במסנן, יצרני ציוד מקורי משתמשים בשכבת-על של משאבי המסגרת config_disableApkUnlessMatchedSku_skus_list ו-config_disableApksUnlessMatchedSku_apk_list.

כדי להגדיר הגדרות מדויקות יותר, צריך להצהיר על מקלט שידורים שמשבית חבילות מיותרות. ה-broadcast receiver קורא ל-setApplicationEnabledSetting כדי להשבית את החבילה כשהוא מקבל את ההודעה ACTION_BOOT_COMPLETED.

הגדרה של RRO במקום שימוש בשכבת-על סטטית של משאבים

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

PRODUCT_ENFORCE_RRO_TARGETS := *
PRODUCT_ENFORCE_RRO_EXCLUDED_OVERLAYS := # leave it empty

אם נדרשת הגדרה מפורטת, צריך להגדיר RRO באופן ידני במקום להסתמך על RRO שנוצר באופן אוטומטי. מידע מפורט זמין במאמר Runtime Resource Overlays (RROs). יצרני ציוד מקורי (OEM) יכולים גם להגדיר שכבות-על מותנות של RRO שתלויות במאפייני המערכת באמצעות המאפיינים android:requiredSystemPropertyName ו-android:requiredSystemPropertyValue.

שאלות נפוצות

האם אפשר להגדיר כמה ממשקי SSI?

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

האם אפשר לשנות את generic_system.mk (mainline_system.mk) עבור GSI של יצרן ציוד מקורי?

לא. אבל יצרני ציוד מקורי יכולים להגדיר קובץ makefile חדש עבור GSI של יצרן ציוד מקורי שמקבל בירושה את הקובץ generic_system.mk ולהשתמש בקובץ makefile החדש במקום זאת. לדוגמה, אפשר לעיין במאמר בנושא החלת ממשקי חלוקת מוצרים.

האם אפשר להסיר מודולים מ-generic_system.mk שמתנגשים עם ההטמעה שלי?

לא. ל-GSI יש קבוצה מינימלית של מודולים שאפשר להפעיל ולבדוק. אם לדעתכם מודול מסוים לא חיוני, אתם יכולים לדווח על באג כדי לעדכן את הקובץ generic_system.mk ב-AOSP.