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

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

רקע

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

מוטיבציה

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

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

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

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

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

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

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

מחיצות סביב SSI

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

מחיצות וממשקים מסביב לתרשים הבלוק של SSI

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

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

במידע שבקטע הזה יש הבחנה בין המונחים image ו-partition.

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

הקטעים בתרשים 1 מוגדרים באופן הבא:

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

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

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

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

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

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

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

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

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

    • HIDL (Passthrough HAL זמין רק למודולים system ו-system_ext)
    • Stable AIDL
    • הגדרות
      • System properties API
      • Config file schema API
    • VNDK
    • Android SDK APIs
    • ספריית 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, צריך להתקין מודולים כאלה בספריית המשנה ./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, ולהשתמש בממשקים יציבים מהמחיצות /system ו-/system_ext.

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

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

החל מגרסה 11 של Android, הממשקים המקוריים והממשקים של 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

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

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

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

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

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

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

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

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

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

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

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

העברת קבצים שנוספו מ-GSI של OEM

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

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

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

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

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

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

שלב 4. להשתמש באותו קובץ בינארי ב-OEM GSI כמו ב-AOSP GSI

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

שימוש באותם קבצים בינאריים ב-OEM GSI כמו ב-AOSP GSI

איור 6. הוספת אותם קבצים בינאריים ל-GSI של OEM כמו ל-GSI של AOSP

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

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

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

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

אכיפת ממשקי מוצרים

כדי להבטיח שהמחיצה /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 לאפליקציות במחיצה של המוצר או הספק. יצרני ציוד מקורי צריכים להקפיא את ממשקי ה-API שמוצגים למוצרים כדי לשמור על תאימות לאחור.

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

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

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

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

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

PRODUCT_ENFORCE_RRO_TARGETS := *
PRODUCT_ENFORCE_RRO_EXCLUDED_OVERLAYS := # leave it empty

אם נדרשת הגדרה מפורטת, צריך להגדיר RRO באופן ידני במקום להסתמך על RRO שנוצר באופן אוטומטי. מידע מפורט זמין במאמר שכבות-על של משאבים בסביבת זמן ריצה (RRO). יצרני ציוד מקורי יכולים גם להגדיר 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.