הגדרת הגודל של המחיצה העליונה

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

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

בנוסף, מכשירי Virtual A/B יכולים להשתמש במקום ב-/data במהלך עדכון, וצריך לקחת את זה בחשבון כשקובעים את הגודל של /data.super אם נדרש יותר מדי מקום ב-/data, חלק מהמשתמשים לא יוכלו (או לא ירצו) להתקין את העדכון. עם זאת, אם ידוע שלרוב המשתמשים יש אחוז מסוים של מקום פנוי, המכשירים יכולים להפחית את המקום הזה מ-super. לחלופין, אפשר להגדיל את /data כך שלא יהיה צורך להשתמש בו אף פעם.super

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

הסתמכות על /data

בבדיקת A/B וירטואלית, המערכת מעודדת צמצום של super כדי לאפשר הגדלה של /data. חלק מהנפח הזה נדרש במהלך עדכון. כדי להבין את ההשפעה על האפשרות לעדכן, חשוב לדעת מהו אחוז המכשירים שסביר שיהיה בהם נפח אחסון פנוי כזה לאורך זמן. המספר הזה תלוי מאוד בחומרה של המכשיר ובהתנהגות המשתמשים במכשיר. בדוגמאות שבהמשך, המספר הזה נקרא AllowedUserdataUse.

ללא דחיסה

בלי דחיסה, עדכון OTA מלא צריך תמונת מצב בגודל שדומה בערך לגודל מערכת ההפעלה, ולכן צריך לקחת את זה בחשבון כשקובעים את הגודל של super:

  FinalDessertSize = FactorySize + (FactorySize * ExpectedGrowth)
  Super = Max(FinalDessertUpdate, FinalDessertSize * 2 - AllowedUserdataUse)

לדוגמה, נניח שיש מכשיר עם בדיקת A/B וירטואלית, שהגודל שלו במצב המפעל הוא 4GB, הצמיחה הצפויה היא 50% וידוע שכמעט לכל המשתמשים יש 1GB פנוי (או שהם מוכנים לפנות עד 1GB כדי להתקין עדכון). במכשיר הזה, אפשר לשנות את הגודל של super כך:

  FinalDessertSize = 4GB + (4GB * 0.5) = 6GB
  Super = Max(6GB, 6GB * 2 - 1GB) = Max(6GB, 11GB)

לכן, במכשיר הזה צריכה להיות מחיצה של 11 GB super.

עם דחיסה

בדחיסה, עדכון מלא של OTA צריך תמונת מצב בגודל של כ-70% מגודל מערכת ההפעלה:

  FinalDessertSize = FactorySize + (FactorySize * ExpectedGrowth)
  FinalOTASnapshotSize = FinalDessertSize * 0.7
  Super = Max(FinalDessertUpdate, FinalDessertSize + FinalOTASnapshotSize - AllowedUserdataUse)

לדוגמה, נניח שמכשיר מוגדר עם דחיסת Virtual A/B, עם גודל במפעל של 4GB, צמיחה צפויה של 50% וידע שלכמעט כל המשתמשים יש 1GB פנוי (או שהם מוכנים לפנות עד 1GB של נפח אחסון בשביל עדכון). במכשיר הזה, אפשר לשנות את הגודל של super כך:

  FinalDessertSize = 4GB + (4GB * 0.5) = 6GB
  FinalOTASnapshotSize = 6GB * 0.7 = 4.2GB
  Super = Max(6GB, 6GB + 4.2GB - 1GB) = Max(6GB, 9.2GB) = 9.2GB

לכן, במכשיר הזה צריכה להיות מחיצה של 9.2 GB super.

בלי להסתמך על /data

אם אתם רוצים שעדכוני OTA לא ידרשו אף פעם מקום לצילום תמונת מצב ב-/data, אז קביעת הגודל של super היא פשוטה.

ללא דחיסה

במכשיר וירטואלי מסוג A/B ללא דחיסה, או במכשיר רגיל מסוג A/B:

  FinalDessertSize = FactorySize + (FactorySize * ExpectedGrowth)
  Super = FinalDessertSize * 2

לדוגמה, נניח שיש מכשיר וירטואלי לבדיקת A/B עם גודל מקורי של 4 GB וצפי לגידול של 50%. כדי לוודא שבמכשיר הזה לעולם לא נעשה שימוש ב-/data לצילומי מצב של OTA, החישוב שלו ייראה כך:

  FinalDessertSize = 4GB + (4GB * 0.5) = 6GB
  Super = FinalDessertSize * 2 = 12GB

לכן, במכשיר הזה צריכה להיות מחיצה של 12 GB super.

עם דחיסה

למכשיר וירטואלי A/B עם דחיסה:

  FinalDessertSize = FactorySize + (FactorySize * ExpectedGrowth)
  FinalOTASnapshotSize = FinalDessertSize * 0.7
  Super = FinalDessertSize + FinalOTASnapshotSize

לדוגמה, נניח שיש מכשיר דחיסה וירטואלי מסוג A/B עם גודל מקורי של 4 GB וצמיחה צפויה של 50%. כדי לוודא שהמכשיר הזה לא ישתמש אף פעם ב-/data לצילומי מצב של OTA, החישוב שלו ייראה כך:

  FinalDessertSize = 4GB + (4GB * 0.5) = 6GB
  FinalOTASnapshotSize = 6GB * 0.7 = 4.2GB
  Super = 6GB + 4.2GB = 10.2GB

לכן, במכשיר הזה צריך להיות מחיצה בנפח 10.2 GB super.

נקודות שחשוב לדעת

יכול להיות שתחשבו שאם הגודל של המפעל הוא 4GB, והעדכון הסופי הוא 5GB, אז super צריך להיות 9GB ולא 10GB. עם זאת, אם העדכון הראשון והעדכון הסופי הם שניהם בגודל 5 GB, יכול להיות שלא יהיה מספיק מקום ב-super לעדכון הסופי. הנוסחאות שלמעלה מניחות שצמיחה של מחיצה יכולה לקרות בכל זמן. יכול להיות שהנפח שנדרש להחלת העדכון הסופי יהיה זהה לזה שנדרש להחלת העדכון הראשון.

חשוב לזכור ששיעורי הדחיסה הם אומדן. יכול להיות שדחיסה של תמונת מערכת הפעלה תהיה טובה יותר או גרועה יותר, בהתאם לתוכן שלה. אם משתמשים במערכת קבצים דחוסה כמו EROFS, הדחיסה הנוספת מ-Virtual A/B לא משתלמת. במקרה כזה, עדיף להשתמש באחת מהנוסחאות הלא דחוסות בתור הנחיה.

חישוב הגודל

כדי למצוא את הערך של FactorySize בדוגמאות הקודמות, מחברים את הגדלים של כל המחיצות הדינמיות. תמונות המחיצות הדינמיות של AOSP הן:

• system.img
• vendor.img
• product.img
• system_ext.img
• vendor_dlkm.img
• system_dlkm.img

חשוב לוודא שחישבתם את הגודל על סמך תמונות לא דלילות. כשיוצרים גרסה של Android 12 או גרסה ישנה יותר, התמונות מפוזרות כברירת מחדל, ואפשר לבטל את הפיזור שלהן באמצעות simg2img.

אפשר גם לחשב את גודל המחיצות מחבילת OTA. בנוסף, המערכת תעריך את גודל התמונה של בדיקת ה-A/B הווירטואלית לכל מחיצה:

  python3 system/update_engine/scripts/payload_info.py path/to/ota-package.zip

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

כדי למצוא את הערך של ExpectedGrowth, צריך להשתמש במכשיר ששוחרר בעבר. כדי לחשב את הצמיחה, משתמשים בתמונה super המוקדמת ביותר והמאוחרת ביותר.