OTA עבור התקני A/B ללא מחיצות דינמיות

אנדרואיד 10 תומך במחיצות דינמיות , מערכת מחיצות למרחב משתמש שיכולה ליצור, לשנות גודל ולהרוס מחיצות במהלך עדכוני אויר (OTA).

דף זה מתאר כיצד לקוחות OTA משנים את גודל המחיצות הדינמיות במהלך עדכון עבור מכשירי A/B שהושקו ללא תמיכה במחיצות דינמיות וכיצד לקוחות OTA משדרגים לאנדרואיד 10.

רקע כללי

במהלך עדכון של מכשיר A/B לתמיכה במחיצות דינמיות, טבלת המחיצות של ה-GUID (GPT) במכשיר נשמרת, כך שאין super על במכשיר. מטא נתונים מאוחסנים ב- system_a וב- system_b , אך ניתן להתאים זאת על ידי שינוי BOARD_SUPER_PARTITION_METADATA_DEVICE .

בכל אחד מהתקני הבלוק, ישנם שני חריצי מטא נתונים. נעשה שימוש בחריץ מטא נתונים אחד בלבד בכל התקן בלוק. לדוגמה, Metadata 0 ב- system_a -נתונים 1 ב- system_b תואמים למחיצות בחריצי A ו-B, בהתאמה. בזמן ריצה, זה לא משנה איזה משבצת מתעדכנת.

בדף זה, חריצי המטא נתונים נקראים Metadata S (מקור) ומטא נתונים T (יעד). באופן דומה, מחיצות מכונות system_s , vendor_t וכן הלאה.

למידע נוסף על בניית תצורות מערכת , ראה שדרוג התקנים .

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

דוגמה למטא נתונים במכשיר היא:

  • מערכת מכשיר חסימה system_a
    • מטא נתונים 0
      • קבוצה foo_a
        • מערכת מחיצה לוגית (דינמית) system_a
        • מחיצה לוגית (דינמית) product_services_a
        • מחיצות אחרות שעודכנו על ידי Foo
      • קבוצה bar_a
        • מחיצה לוגית (דינמית) vendor_a
        • מחיצה לוגית (דינמית) product_a
        • מחיצות אחרות שעודכנו על ידי בר
    • מטא נתונים 1 (לא בשימוש)
  • מערכת מכשיר חסימה system_b
    • מטא נתונים 0 (לא בשימוש)
    • מטא נתונים 1
      • קבוצה foo_b
        • מערכת מחיצות לוגית (דינמית) system_b
        • מחיצה לוגית (דינמית) product_services_b
        • מחיצות אחרות שעודכנו על ידי Foo
      • קבוצה בר_ב
        • מחיצה לוגית (דינמית) vendor_b
        • מחיצה לוגית (דינמית) product_b
        • מחיצות אחרות שעודכנו על ידי בר

אתה יכול להשתמש בכלי lpdump תחת system/extras/partition_tools כדי לזרוק את המטא נתונים במכשיר שלך. לדוגמה:

lpdump --slot 0 /dev/block/by-name/system_a
lpdump --slot 1 /dev/block/by-name/system_b

חידוש עדכון

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

מחולל ה-OTA בונה את הקובץ הסופי super.img המכיל את התוכן של כל המחיצות הדינמיות, ואז מפצל את התמונה למספר תמונות התואמות לגדלים של התקני הבלוק הפיזיים המתאימים למערכת, לספק וכו'. תמונות אלו נקראות super_system.img , super_vendor.img , וכן הלאה. לקוח OTA מחיל את התמונות הללו על המחיצות הפיזיות, במקום להחיל את התמונות עבור המחיצות הלוגיות (דינמיות).

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

זרימת העדכון זהה לאנדרואיד 9.

לפני העדכון:

ro.boot.dynamic_partitions=
ro.boot.dynamic_partitions_retrofit=

לאחר העדכון:

ro.boot.dynamic_partitions=true
ro.boot.dynamic_partitions_retrofit=true

עדכונים עתידיים לאחר שיפוץ

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

זרימת עדכון באמצעות חבילת עדכון רגילה

  1. אתחול המטא נתונים של מחיצת super .
    1. בנה מטא נתונים M חדשים מ- Metadata S (מטאדטה מקור). לדוגמה, אם Metadata S משתמש ב-[ system_s , vendor_s , product_s ] כהתקני חסימה, אז המטא-נתונים החדשים M משתמשים ב-[ system_t , vendor_t , product_t ] כהתקני חסימה. כל הקבוצות והמחיצות נמחקות ב-M.
    2. הוסף קבוצות יעד ומחיצות לפי השדה dynamic_partition_metadata במניפסט העדכון. ניתן למצוא את הגודל של כל מחיצה ב- new_partition_info .
    3. כתוב M ל- Metadata T.
    4. מפה את המחיצות שנוספו בממפ המכשיר כניתנות לכתיבה.
  2. החל את העדכון על מכשירי החסימה.
    1. במידת הצורך, מפה את מחיצות המקור בממפה המכשיר כקריאה בלבד. זה הכרחי עבור טעינת צד מכיוון שמחיצות המקור אינן ממפות לפני העדכון.
    2. החל עדכון מלא או דלתא על כל מכשירי החסימה בחריץ היעד.
    3. התקן את המחיצות כדי להפעיל את הסקריפט שלאחר ההתקנה, ולאחר מכן בטל את טעינת המחיצות.
  3. בטל את מיפוי מחיצות היעד.

זרימת עדכון באמצעות חבילת עדכון מחדש

אם חבילת העדכון מחדש מוחלת על מכשיר שכבר מאפשר מחיצות דינמיות, לקוח OTA מחיל את קובץ super.img המפוצל על התקני בלוק ישירות. זרימת העדכון דומה לעדכון שיפוץ. ראה התקנה מחדש של עדכון לפרטים.

לדוגמה, נניח את הדברים הבאים:

  • חריץ A הוא החריץ הפעיל.
  • system_a מכיל את המטא-נתונים הפעילים במשבצת 0.
  • system_a , vendor_a ו- product_a משמשים כהתקני בלוק.

כאשר לקוח OTA מקבל חבילת עדכון מחדש, הוא מחיל את super_system.img על system_b פיזית, super_vendor.img על vendor_b פיזי ו- super_product.img על product_b פיזי. התקן החסימה הפיזי system_b מכיל את המטא-נתונים הנכונים למיפוי ה- system_b הלוגי, vendor_b ו- product_b בזמן האתחול.

הפקת חבילות עדכון

OTA מצטבר

בעת יצירת OTAs מצטברים עבור התקני התאמה מחדש, העדכונים תלויים בשאלה אם ה-build הבסיס מגדיר PRODUCT_USE_DYNAMIC_PARTITIONS ו- PRODUCT_RETROFIT_DYNAMIC_PARTITIONS או לא.

  • אם ה-Build הבסיסי לא מגדיר את המשתנים, זהו עדכון התאמה לאחור. חבילת העדכון מכילה את קובץ super.img המפוצל ומשביתה את השלב שלאחר ההתקנה.
  • אם מבנה הבסיס אכן מגדיר את המשתנים, זה זהה לעדכון טיפוסי עם מחיצות דינמיות. חבילת העדכון מכילה את התמונות עבור מחיצות לוגיות (דינמיות). ניתן להפעיל את השלב שלאחר ההתקנה.

OTA מלא

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

  • $(PRODUCT)-ota-retrofit-$(TAG).zip מכיל תמיד super.img מפוצל ומשבית את השלב שלאחר ההתקנה עבור עדכון מחדש.
    • הוא נוצר עם ארגומנט נוסף --retrofit_dynamic_partitions לסקריפט ota_from_target_files .
    • ניתן להחיל את זה על כל הבנייה.
  • $(PRODUCT)-ota-$(TAG).zip מכיל תמונות הגיוניות לעדכונים עתידיים.
    • החל את זה רק על מבנים עם מחיצות דינמיות מופעלות. ראה פרטים להלן על אכיפת זה.

דחיית עדכון ללא תיקון על בנייה ישנה

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

כדי למנוע מהמכשיר לקבל את חבילת OTA המלאה, אתה יכול לדרוש שלב לאחר ההתקנה כדי לבדוק את תצורת המכשיר הקיימת. לדוגמה:

device/ device_name /dynamic_partitions/check_dynamic_partitions

#!/system/bin/sh
DP_PROPERTY_NAME="ro.boot.dynamic_partitions"
DP_RETROFIT_PROPERTY_NAME="ro.boot.dynamic_partitions_retrofit"

DP_PROPERTY=$(getprop ${DP_PROPERTY_NAME})
DP_RETROFIT_PROPERTY=$(getprop ${DP_RETROFIT_PROPERTY_NAME})

if [ "${DP_PROPERTY}" != "true" ] || [ "${DP_RETROFIT_PROPERTY}" != "true" ] ; then
    echo "Error: applied non-retrofit update on build without dynamic" \
         "partitions."
    echo "${DP_PROPERTY_NAME}=${DP_PROPERTY}"
    echo "${DP_RETROFIT_PROPERTY_NAME}=${DP_RETROFIT_PROPERTY}"
    exit 1
fi

device/ device_name /dynamic_partitions/Android.mk

LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE:= check_dynamic_partitions
LOCAL_MODULE_TAGS := optional
LOCAL_MODULE_CLASS := EXECUTABLES
LOCAL_SRC_FILES := check_dynamic_partitions
LOCAL_PRODUCT_MODULE := true
include $(BUILD_PREBUILT)

device/ device_name /device.mk

PRODUCT_PACKAGES += check_dynamic_partitions

# OPTIONAL=false so that the error in check_dynamic_partitions will be
# propagated to OTA client.
AB_OTA_POSTINSTALL_CONFIG += \
    RUN_POSTINSTALL_product=true \
    POSTINSTALL_PATH_product=bin/check_dynamic_partitions \
    FILESYSTEM_TYPE_product=ext4 \
    POSTINSTALL_OPTIONAL_product=false \

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