הטמעת Virtual A/B – תיקונים

כדאי לבחור את התיקונים הבאים לטיפול בבעיות הידועות הבאות.

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

התקנה ממקור לא ידוע של חבילת OTA מלאה במכשיר A/B וירטואלי מחיצה שגודלה קטן מ- *2 * amount(size of update groups)* עלולה להיכשל עם הפרטים הבאים ביומן השחזור /tmp/recovery.log:

The maximum size of all groups with suffix _b (...) has exceeded half of allocatable space for dynamic partitions ...

דוגמה ליומן:

[INFO:dynamic_partition_control_android.cc(1020)] Will overwrite existing partitions. Slot A may be unbootable until update finishes!
[...]
[ERROR:dynamic_partition_control_android.cc(803)] The maximum size of all groups with suffix _b (2147483648) has exceeded half of allocatable space for dynamic partitions 1073741824.

אם נתקלתם בבעיה הזו, בחרו באפשרות CL 1399393, בנייה מחדש ו-Flash מחיצת האתחול או מחיצת השחזור אם המכשיר לא משתמש בשחזור בתור לאתחל.

תיקון שגיאת פילוח במהלך המיזוג

לאחר החלת עדכון OTA, במהלך מיזוג ה-VAB, מתבצעת קריאה אל update_engine_client --cancel גורם לקריסה של CleanupPreviousUpdateAction. א' שגיאה פוטנציאלית של המצביע הכללי קיימת גם כאשר markSlotSuccessful מגיע באיחור.

הבעיה נפתרה על ידי הוספת הפונקציה StopActionInternal. CleanupPreviousUpdateAction מבטל משימות בהמתנה בזמן ההרס. הוא שומר על שעוקב אחרי מזהה המשימה של המשימה הממתינה בלולאת ההודעות. בזמן ההרס, המשימה בהמתנה מבוטלת כדי למנוע שגיאת segfault.

כדי לתקן את הבעיה, צריך לוודא שהשינויים הבאים נמצאים בעץ המקור של Android 11 SIGSEGV קריסות באפליקציה update_engine במהלך המיזוג:

  • CL 1439792 (a) דרישה מוקדמת ל-CL 1439372)
  • CL 1439372 (CleanupPreviousUpdateAction: cancel pending tasks on destroy)
  • CL 1663460 (תיקון השגיאה האפשרית של מצביע לא ידוע כש-markSlotSuccessful מגיע באיחור)

מניעת מיזוג מוקדם של update_engine

כשמכשיר מופעל (Android 11 ואילך) וההפעלה מסתיימת, ה-update_engine קורא ל-ScheduleWaitMarkBootSuccessful() ול-WaitForMergeOrSchedule(). הפעולה הזו תתחיל את תהליך המיזוג. עם זאת, המכשיר מופעל מחדש בחריץ הישן. מכיוון שהמיזוג כבר התחיל, המכשיר לא מצליח ולא יהיה פעיל יותר.

מוסיפים את השינויים הבאים לעץ המקור. לתשומת ליבכם: CL 1664859 הוא אופציונלי.

  • CL 1439792 (דרישה מוקדמת ל-CL 1439372)
  • CL 1439372 (CleanupPreviousUpdateAction: cancel pending tasks on destroy)
  • CL 1663460 (תיקון של שגיאה אפשרית של מצביע העכבר הכללי כאשר markSlotSuccessful מגיע באיחור)
  • CL 1664859 (אופציונלי – מוסיפים unittest עבור CleanupPreviousUpdateAction)

מוודאים שהגדרת dm-verity נכונה

ב-Android מגרסה 11 ואילך, אפשר להגדיר בטעות במכשירים את האפשרויות הבאות של dm-verity:

  • CONFIG_DM_VERITY_AVB=y בליבה (kernel)
  • תוכנת האתחול שהוגדרה לשימוש בכל מצב אימות (למשל AVB_HASHTREE_ERROR_MODE_RESTART_AND_INVALIDATE), בלי AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO.

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

  1. מגדירים את CONFIG_DM_VERITY_AVB=n בליבה.
  2. מגדירים את המכשירים לשימוש במקום זאת, מצב AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO.

למידע נוסף, אפשר לעיין במסמכי התיעוד של Verity: טיפול בטעויות של dm-verity.

מוודאים שהקובץ הממוזג מוגדר בצורה נכונה

אם אתם יוצרים קובצי אימג' של מערכת וקובצי אימג' של ספק בנפרד, ואז משתמשים ב-merge_target_files כדי למזג אותם, יכול להיות שהגדרות של בדיקות A/B וירטואליות יוסרו בטעות במהלך תהליך המיזוג. כדי לוודא שההגדרות של Virtual A/B נכונות בקובץ היעד הממוזג, צריך להחיל את התיקונים הבאים: CL 2084183 (מיזוג של זוגות מפתח/ערך זהים בפרטים של מחיצה דינמית)

עדכון הרכיבים הנדרשים

החל מ-Android 13, snapuserd הועבר מ-ramdisk של ספק לגנרי ramdisk. אם המכשיר שלך משדרג ל-Android 13, ייתכן ששני המכשירים ramdisk של ספק ו-ramdisk גנרי מכילים עותק של snapuserd. במקרה כזה, ל-Virtual A/B נדרשת עותק המערכת של snapuserd. כדי לוודא העותק הנכון של snapuserd נמצא, יש להחיל CL 2031243 (מעתיקים את snapuserd אל first_stage_ramdisk).