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

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

רקע

מסגרת פרויקט קוד פתוח של Android ‏ (AOSP) תואמת לארכיטקטורת Mainline כדי לשמור על תאימות לדורות קודמים עם הטמעות ישנות יותר של ספקים. לדוגמה, תמונת מערכת כללית (GSI) שנבנתה ממקורות Android 10 AOSP יכולה לפעול בכל מכשיר שתואם ל-Treble ופועלת בו מערכת Android 8 או גרסה מתקדמת יותר.

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

בעבר, ספקי SoC ויצרני ציוד מקורי (OEM) שינו באופן משמעותי את גרסת מסגרת Android שנשלחה במכשירים לצרכנים (פרטים נוספים זמינים במאמר מחזור החיים של מהדורת Android). מכיוון שתוספי המסגרת האלה לא תוכננו בדרך כלל עם תאימות לאחור, שינויים ספציפיים למכשיר הגדילו באופן משמעותי את המורכבות והעלות הכספית של שדרוגי מערכת הפעלה עתידיים. ב-Android 10 (רמת API‏ 29) ומטה, לא היה אקוסיסטם עם ארכיטקטורה ברורה וסטנדרטית שמאפשרת לשותפים ליצור הרחבות מודולריות למסגרת Android.

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

פרטים על ההטמעה מופיעים במאמר הצעות לשלבים בהטמעה של SSI שמבוססת על GSI. השלבים מודולריים. בהתאם לארכיטקטורה שלכם, אתם יכולים לבחור להטמיע שלבים ספציפיים (כמו שלב 1: ירושה של generic_system.mk לקובץ אימג' של מערכת OEM‏ (OEM GSI)) במקום את כל השלבים.

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

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

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

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

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

מחיצות שקשורות ל-SSI

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

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

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

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

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

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

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

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

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

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

המחיצה ‎ /system_ext

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

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

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

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

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

• ממשקי מוצר: ממשק המוצר הוא הממשק בין SSI לבין תמונת המוצר. הגדרת ממשק יציב מפרידה בין רכיבי המוצר לבין רכיבי המערכת ב-SSI.

הפעלת SSI

בקטע הזה מוסבר איך לתמוך ב-SSI ב-Android מגרסה 11 ואילך.

ביטול הקיבוץ של רכיבים

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

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

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

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

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

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

קובץ אימג' גנרי של המערכת (GSI) הוא קובץ אימג' של המערכת שנבנה ישירות מ-AOSP. הוא משמש לבדיקות תאימות (לדוגמה, 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 ‏ (OEM GSI)

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

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

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

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

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

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

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

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

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

שלב 4: מוודאים שלקובצי ה-GSI של יצרן הציוד המקורי יש את אותם קובצי בינאריים כמו לקובצי ה-GSI של AOSP

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

איור 6. צריך לוודא של-GSI של יצרן ציוד מקורי יש את אותם קבצים בינאריים כמו ל-GSI של AOSP.

הגדרה של SSI

יצרני ציוד מקורי יכולים להשתמש בהנחיות הבאות כדי להגדיר את ה-SSI שלהם.

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

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

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

הפיכת המחיצה ‎ /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 שפונים למוצר כדי לשמור על תאימות לאחור.

החלפת השבתת אפליקציות ספציפיות למק"ט

ב-Android 16 הוצא משימוש המנגנון מדור קודם להשבתה סלקטיבית של קובצי APK על סמך SKU של חומרה באמצעות שכבות-על של משאבי framework ‏(config_disableApksUnlessMatchedSku_apk_list ו-config_disableApkUnlessMatchedSku_skus_list), והוא הוסר. פרטים נוספים זמינים ב-aosp/3444399.

ההמלצה היא להשתמש בinstall-in-user-typeהגדרת המערכת בספריות ספציפיות למק"ט. הגישה הזו מונעת את ההתקנה של החבילה אצל משתמשים ב-SKU מסוים, במקום רק להשבית אותה אחרי ההתקנה.

1. צריך לכלול את כל קובצי ה-APK (קבוצת העל של כל האפליקציות הפוטנציאליות לכל מספרי ה-SKU בתמונת המערכת) בתמונה, בדרך כלל במחיצה /product.

2. מוודאים שהמק"ט של המכשיר מוגדר בצורה נכונה במאפיין המערכת ro.boot.hardware.sku (שמשמש את המערכת לזיהוי המק"ט של המכשיר בזמן האתחול).

3. יוצרים ספריות משנה של sysconfig ספציפיות למק"ט מתחת ל-/product/etc/sysconfig/ באמצעות מוסכמת השמות sku_<SKU_NAME>. המערכת טוענת באופן אוטומטי הגדרות מהספרייה שתואמת לנכס ro.boot.hardware.sku. נתיב לדוגמה: /product/etc/sysconfig/sku_basic_model/.

4. מגדירים מניעת התקנה של אפליקציות. בספרייה הספציפית ל-SKU, יוצרים קובץ הגדרה בפורמט XML (לדוגמה, disabled_apps.xml) ומשתמשים בתג <do-not-install-in> כדי להחריג חבילות ספציפיות.

דוגמה לפורמט XML (/product/etc/sysconfig/sku_basic_model/disabled_apps.xml):

<?xml version="1.0" encoding="utf-8"?>
<config>
    <!-- Prevents this package from being installed for ANY user on this SKU -->
    <install-in-user-type package="com.example.premium.feature.app" >
        <do-not-install-in user-type="FULL" />
        <do-not-install-in user-type="SYSTEM" />
    </install-in-user-type>
</config>

הנה השוואה בין שתי השיטות:

במקרים שבהם נדרשת שליטה ברמת פירוט גבוהה יותר (כלומר, השבתה של אפליקציה שבדרך כלל מותקנת כברירת מחדל בכל המהדורות), מערכת Android תומכת גם בתגים disabled-in-sku ו-enabled-in-sku-override ב-sysconfig:

• ‫<disabled-in-sku package="com.example.app" /> משבית את האפליקציה בכל העולם.

• ‫<enabled-in-sku-override package="com.example.app" /> מפעיל מחדש את האפליקציה למק"ט ספציפי כשהוא ממוקם בספרייה המתאימה sku_<name>.

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

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

PRODUCT_ENFORCE_RRO_TARGETS := *
PRODUCT_ENFORCE_RRO_EXCLUDED_OVERLAYS := # leave it empty

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

שאלות נפוצות

ריכזנו כאן תשובות לכמה שאלות נפוצות בנושא SSI.

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

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

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

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