הטמעת A/B וירטואלית

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

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

בנה דגלים

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

עבור מכשירים המופעלים עם A/B ​​וירטואלי, הגדר אותם כך שיורש את תצורת בסיס התקן A/B וירטואלי:

$(call inherit-product, \
    $(SRC_TARGET_DIR)/product/virtual_ab_ota.mk)

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

עבור Android 13 ומעלה, כדי לאפשר צילומי מצב דחוסים עם Virtual A/B, ירשו את תצורת הבסיס הבאה:

$(call inherit-product, $(SRC_TARGET_DIR)/product/generic_ramdisk.mk)
$(call inherit-product, \
    $(SRC_TARGET_DIR)/product/virtual_ab_ota/android_t_baseline.mk)

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

PRODUCT_VIRTUAL_AB_COMPRESSION_METHOD := gz

עבור Android 12, כדי לאפשר צילומי מצב דחוסים עם Virtual A/B, ירשו את תצורת הבסיס הבאה:

$(call inherit-product, $(SRC_TARGET_DIR)/product/generic_ramdisk.mk)
$(call inherit-product, \
    $(SRC_TARGET_DIR)/product/virtual_ab_ota/compression.mk)

דחיסת XOR

עבור מכשירים המשדרגים ל-Android 13 ומעלה, תכונת הדחיסה של XOR אינה מופעלת כברירת מחדל. כדי לאפשר דחיסת XOR, הוסף את הדברים הבאים לקובץ ה-. .mk של המכשיר.

PRODUCT_VENDOR_PROPERTIES += ro.virtual_ab.compression.xor.enabled=true

דחיסת XOR מופעלת כברירת מחדל עבור מכשירים שיורשים מ- android_t_baseline.mk .

מיזוג שטחי משתמש

עבור מכשירים שמשדרגים ל-Android 13 ומעלה, תהליך מיזוג מרחב המשתמש כפי שמתואר בשכבות של Device-Mapper אינו מופעל כברירת מחדל. כדי לאפשר מיזוג שטחי משתמש, הוסף את השורה הבאה לקובץ ה-. .mk של המכשיר:

PRODUCT_VENDOR_PROPERTIES += ro.virtual_ab.userspace.snapshots.enabled=true

מיזוג שטחי משתמש מופעל כברירת מחדל במכשירים המופעלים עם 13 ומעלה.

בקרת אתחול HAL

בקרת האתחול HAL מספקת ממשק עבור לקוחות OTA לשליטה בחריצי אתחול. Virtual A/B דורש שדרוג גרסה מינורי של HAL בקרת האתחול מכיוון שנדרשים ממשקי API נוספים כדי להבטיח שהמטען האתחול מוגן במהלך מהבהב/איפוס להגדרות היצרן. ראה IBootControl.hal ו- types.hal לגרסה העדכנית ביותר של הגדרת HAL.

// hardware/interfaces/boot/1.1/types.hal
enum MergeStatus : uint8_t {
    NONE, UNKNOWN, SNAPSHOTTED, MERGING, CANCELLED };

// hardware/interfaces/boot/1.1/IBootControl.hal
package android.hardware.boot@1.1;
interface IBootControl extends @1.0::IBootControl {
    setSnapshotMergeStatus(MergeStatus status)
        generates (bool success);
    getSnapshotMergeStatus()
        generates (MergeStatus status);
}
// Recommended implementation

Return<bool> BootControl::setSnapshotMergeStatus(MergeStatus v) {
    // Write value to persistent storage
    // e.g. misc partition (using libbootloader_message)
    // bootloader rejects wipe when status is SNAPSHOTTED
    // or MERGING
}

שינויים ב-Fstab

השלמות של מחיצת המטא נתונים חיונית לתהליך האתחול, במיוחד מיד לאחר החלת עדכון OTA. לכן, יש לבדוק את מחיצת המטא נתונים לפני first_stage_init מעלה אותה. כדי להבטיח שזה יקרה, הוסף את הדגל check fs_mgr לערך עבור /metadata . להלן דוגמה:

/dev/block/by-name/metadata /metadata ext4 noatime,nosuid,nodev,discard,sync wait,formattable,first_stage_mount,check

דרישות הליבה

כדי לאפשר צילום מצב, הגדר את CONFIG_DM_SNAPSHOT ל- true .

עבור מכשירים המשתמשים ב-F2FS, כלול את הדגל f2fs: ייצוא FS_NOCOW_FL לתיקון ליבת המשתמש כדי לתקן הצמדת קבצים. כלול את ה- f2fs: תומך גם בתיקון ליבת קבצים מוצמדים .

A/B וירטואלי מסתמך על תכונות שנוספו בגרסת ליבה 4.3: סיבית מצב הגלישה במטרות snapshot snapshot-merge . לכל המכשירים המופעלים עם אנדרואיד 9 ואילך כבר אמורה להיות גרסת ליבה 4.4 ואילך.

כדי לאפשר צילומי מצב דחוסים, גרסת הליבה המינימלית הנתמכת היא 4.19. הגדר CONFIG_DM_USER=m או CONFIG_DM_USER=y . אם משתמשים בקודם (מודול), יש לטעון את המודול ב-ramdisk של השלב הראשון. ניתן להשיג זאת על ידי הוספת השורה הבאה למכשיר Makefile:

BOARD_GENERIC_RAMDISK_KERNEL_MODULES_LOAD := dm-user.ko

התאמה מחדש במכשירים המשדרגים לאנדרואיד 11

בעת שדרוג ל-Android 11, מכשירים שהושקו עם מחיצות דינמיות יכולים, אופציונלי, להתאים מחדש A/B וירטואלי. תהליך העדכון זהה לרוב למכשירים המופעלים עם A/B ​​וירטואלי, עם כמה הבדלים קלים:

  • מיקום קבצי COW - עבור התקני הפעלה, לקוח OTA משתמש בכל השטח הריק הזמין במחיצת העל לפני השימוש בשטח ב- /data . עבור התקני תיקון, תמיד יש מספיק מקום במחיצת העל כך שקובץ COW לעולם לא ייווצר ב- /data .

  • דגלים של תכונה בזמן בנייה — עבור מכשירים המשלבים A/B ​​וירטואלי, הן PRODUCT_VIRTUAL_AB_OTA והן PRODUCT_VIRTUAL_AB_OTA_RETROFIT מוגדרות כ- true , כפי שמוצג להלן:

    (call inherit-product, \
        (SRC_TARGET_DIR)/product/virtual_ab_ota_retrofit.mk)
    
  • גודל מחיצה סופר - מכשירים המופעלים עם A/B ​​וירטואלי יכולים לחתוך BOARD_SUPER_PARTITION_SIZE לחצי מכיוון שחריצי B אינם נמצאים במחיצת העל. מכשירים שמתאימים A/B ​​וירטואלית לאחור שומרים על גודל מחיצת העל הישנה, ​​כך BOARD_SUPER_PARTITION_SIZE גדול או שווה ל -2 * סכום (גודל קבוצות עדכון) + תקורה , שבתורו גדול או שווה ל -2 * סכום (גודל מחיצות) + תקורה .

שינויים בטעינת האתחול

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

לפני מחיקת /data , סיים את המיזוג בשחזור או חזרה בהתאם למצב המכשיר:

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

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

  1. הטמע את בקרת האתחול HAL כך שמטען האתחול יוכל לקרוא את הערך שהוגדר על ידי שיטת setSnapshotMergeStatus() ‎.
  2. אם סטטוס המיזוג הוא MERGING , או אם סטטוס המיזוג הוא SNAPSHOTTED השתנה למשבצת המעודכנת לאחרונה, יש לדחות בקשות למחיקת userdata , metadata או המחיצה המאחסנת את סטטוס המיזוג במטען האתחול.
  3. הטמע את הפקודה fastboot snapshot-update cancel כך שמשתמשים יוכלו לאותת למטען האתחול שהם רוצים לעקוף את מנגנון ההגנה הזה.
  4. שנה כלים או סקריפטים מהבהבים מותאמים אישית כדי להנפיק fastboot snapshot-update cancel בעת הבהוב של המכשיר כולו. זה בטוח להנפקה מכיוון שהבהוב של המכשיר כולו מסירה את ה-OTA. כלי עבודה יכולים לזהות פקודה זו בזמן ריצה על ידי הטמעת fastboot getvar snapshot-update-status . פקודה זו עוזרת להבדיל בין מצבי שגיאה.

דוגמא

struct VirtualAbState {
    uint8_t StructVersion;
    uint8_t MergeStatus;
    uint8_t SourceSlot;
};

bool ShouldPreventUserdataWipe() {
    VirtualAbState state;
    if (!ReadVirtualAbState(&state)) ...
    return state.MergeStatus == MergeStatus::MERGING ||
           (state.MergeStatus == MergeStatus::SNAPSHOTTED &&
            state.SourceSlot != CurrentSlot()));
}

שינויים בכלי Fastboot

אנדרואיד 11 מבצעת את השינויים הבאים בפרוטוקול fastboot:

  • getvar snapshot-update-status - מחזירה את הערך שבקרת האתחול HAL מסר למטען האתחול:
    • אם המצב הוא מיזוג, MERGING האתחול חייב להחזיר merging .
    • אם המצב הוא SNAPSHOTTED , טוען האתחול חייב להחזיר snapshotted .
    • אחרת, טוען האתחול חייב להחזיר none .
  • snapshot-update merge - משלים פעולת מיזוג, אתחול לשחזור/fastbootd במידת הצורך. פקודה זו תקפה רק אם snapshot-update-status merging , והיא נתמכת רק ב-fastbootd.
  • snapshot-update cancel — מגדיר את מצב המיזוג של בקרת האתחול HAL ל- CANCELLED . פקודה זו אינה חוקית כאשר המכשיר נעול.
  • erase או wipe - erase או wipe של metadata , userdata משתמש או מחיצה שמחזיקה בסטטוס המיזוג עבור בקרת האתחול HAL אמורה לבדוק את סטטוס המיזוג של תמונת המצב. אם המצב הוא SNAPSHOTTED MERGING המכשיר אמור לבטל את הפעולה.
  • set_active — פקודת set_active שמשנה את המשבצת הפעילה צריכה לבדוק את מצב המיזוג של תמונת המצב. אם המצב הוא MERGING , המכשיר אמור לבטל את הפעולה. ניתן לשנות את החריץ בבטחה במצב SNAPSHOTTED .

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

  1. שאילתה getvar snapshot-update-status .
  2. אם merging או snapshotted , snapshot-update cancel .
  3. המשך בצעדים מהבהבים.

הפחתת דרישות האחסון

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