תמונת מערכת משותפת של אנדרואיד

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

רקע כללי

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

מוֹטִיבָצִיָה

קוד המסגרת ששוחרר ב-AOSP תואם לארכיטקטורת Treble ושמר על תאימות לאחור עם יישומי ספקים ישנים יותר. לדוגמה, תמונת מערכת גנרית הבנויה ממקורות AOSP של Android 10 יכולה לפעול בכל מכשיר תואם Treble שפועל על אנדרואיד 8 ומעלה. הגרסה של אנדרואיד שנשלחת במכשירי צרכנים השתנתה על ידי ספקי SoC ויצרני OEM. (ראה Life of an Android Release .) השינויים וההרחבות הללו שבוצעו למסגרת לא נכתבו לשמירה על תאימות לאחור, מה שתורגם למורכבות מוגברת ולעלות גבוהה יותר בשדרוג מערכת ההפעלה. שינויים ושינויים ספציפיים למכשיר מוסיפים לעלות ולמורכבות של שדרוג גרסת מערכת ההפעלה אנדרואיד.

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

סקירת SSI

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

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

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

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

מחיצות סביב SSI

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

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

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

המידע בסעיף זה מבחין בין המונחים תמונה ומחיצה .

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

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

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

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

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

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

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

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

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

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

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

  • HIDL (Passthrough HAL זמין רק עבור מודולי system ו- system_ext )
  • איידל יציב
  • תצורות
    • API של מאפייני מערכת
    • API של סכימת קובץ תצורה
  • VNDK
  • ממשקי API של Android SDK
  • ספריית Java SDK

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

הפעלת SSI באנדרואיד 11

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

המחיצה /system_ext

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

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

אנדרואיד 9 הציגה מחיצת /product המשולבת עם מחיצת /system . המודולים במחיצת /product משתמשים במשאבי המערכת ללא כל הגבלה, ולהיפך. כדי לאפשר SSI באנדרואיד 10, רכיבי המוצר מחולקים למחיצות /system_ext ו- /product . המחיצה /system_ext אינה חייבת לעמוד בהגבלות על השימוש ברכיבי מערכת שמחיצת /product עשתה באנדרואיד 9. החל מ-Android 10, יש לבטל את מחיצת /product ממחיצת /system ועליה להשתמש בממשקים יציבים מ- המחיצות /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) וכפלטפורמת ייחוס שמפתחי אפליקציות יכולים להשתמש בה כדי לבדוק את התאימות של האפליקציות שלהם כאשר אין להם מכשיר אמיתי שמריץ את הגרסה הנדרשת של אנדרואיד.

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

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

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

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

איור 3. ירושה של generic_system.mk עבור תמונת המערכת של OEM

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

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

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

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

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

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

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

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

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

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

הגדרת SSI עבור יצרני OEM

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

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

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

לאכוף ממשקי מוצר

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

סעיף זה נותן המלצות להפיכת המחיצה /system_ext לנפוצה.

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

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

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

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

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

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

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

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

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

PRODUCT_ENFORCE_RRO_TARGETS := *
PRODUCT_ENFORCE_RRO_EXCLUDED_OVERLAYS := # leave it empty

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

שאלות נפוצות (שאלות נפוצות)

האם אני יכול להגדיר מספר SSIs?

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

האם אני יכול לשנות את generic_system.mk ( mainline_system.mk ) עבור OEM GSI?

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

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

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