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

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

רקע

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

מוטיבציה

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

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

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

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

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

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

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

מחיצות סביב SSI

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

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

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

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

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

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

הסעיפים באיור 1 מוגדרים כך:

  • SSI: ה-SSI הוא התמונה נפוצה אצל ה-OEM ויכולה להתקיים במספר מכשירים. אין בה רכיבים ספציפיים לחומרה או למוצר. מעצם הגדרתו, כל מה שמשותף ב-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 ששונו על ידי ה-OEM.

    • המחיצה /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)
    • 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, ה-OEM יכול להתמקד בתמונה של 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 יכול להכיל את הקבצים שבבעלות ה-OEM בנוסף לקובצי ה-AOSP GSI. עם זאת, יצרני ציוד מקורי (OEM) לא רשאים לשנות את הקובץ generic_system.mk עצמו.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

יצרני ציוד מקורי יכולים להגדיר רשימה כדי לאפשר התקנה זמנית של מודולים ספציפיים למוצר במחיצה /system. עם זאת, כדי שה-GSI של יצרן הציוד המקורי יהיה משותף לכל המוצרים של יצרן הציוד המקורי, הרשימה צריכה להיות ריקה. התהליך הזה מיועד להגדרת ה-GSI של ה-OEM, והוא יכול להיות בלתי תלוי בשלבים של 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 מותנים שמסתמכים על מאפייני המערכת באמצעות המאפיינים android:requiredSystemPropertyName ו-android:requiredSystemPropertyValue.

שאלות נפוצות

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

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

האם אפשר לשנות את generic_system.mk (mainline_system.mk) ל-GSI של OEM?

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

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

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