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

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

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

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

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

שימוש ב-/data

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

ללא דחיסת נתונים

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

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

עם דחיסה

עם דחיסה, אופליין מלא דורש קובץ snapshot בגודל של כ-70% מגודל מערכת ההפעלה:

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

לדוגמה, נניח שיש מכשיר שהוגדר בו דחיסת 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

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

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

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

ללא דחיסת נתונים

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

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

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

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

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

עם דחיסה

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

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

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

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

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

נקודות שצריך לשים לב אליהן:

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

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

חישוב הגודל

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

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

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

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

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

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

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