אנדרואיד 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
מכשיר חסימה פיזית_a- מטא נתונים 0
- קבוצה
foo_a
-
system_a
מחיצה לוגית (דינמית)_a - מחיצה לוגית (דינמית)
product_services_a
- מחיצות אחרות שעודכנו על ידי Foo
-
- קבוצה
bar_a
- מחיצה לוגית (דינמית)
vendor_a
- מחיצה לוגית (דינמית)
product_a
- מחיצות אחרות שעודכנו על ידי בר
- מחיצה לוגית (דינמית)
- קבוצה
- מטא נתונים 1 (לא בשימוש)
- מטא נתונים 0
-
system_b
מכשיר חסימה פיזית_ב- מטא נתונים 0 (לא בשימוש)
- מטא נתונים 1
- קבוצה foo_b
-
system_b
מחיצות לוגית (דינמית)_b - מחיצה לוגית (דינמית)
product_services_b
- מחיצות אחרות שעודכנו על ידי Foo
-
- קבוצה בר_ב
- מחיצה לוגית (דינמית)
vendor_b
- מחיצה לוגית (דינמית)
product_b
- מחיצות אחרות שעודכנו על ידי בר
- מחיצה לוגית (דינמית)
- קבוצה foo_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 מתעדכן לעבודה עם מחיצות דינמיות. ההיקפים של מחיצות המקור לעולם אינם משתרעים על פני מחיצות היעד הפיזיות.
זרימת עדכון באמצעות חבילת עדכון רגילה
- אתחל את המטא נתונים של מחיצת
super
.- בנה מטא נתונים M חדשים מ- Metadata S (מטאדטה מקור). לדוגמה, אם Metadata S משתמש ב-[
system_s
,vendor_s
,product_s
] כהתקני חסימה, אז המטא-נתונים החדשים M משתמשים ב-[system_t
,vendor_t
,product_t
] כהתקני חסימה. כל הקבוצות והמחיצות נמחקות ב-M. - הוסף קבוצות יעד ומחיצות לפי השדה
dynamic_partition_metadata
במניפסט העדכון. ניתן למצוא את הגודל של כל מחיצה ב-new_partition_info
. - כתוב M ל- Metadata T.
- מפה את המחיצות שנוספו בממפ המכשיר כניתנות לכתיבה.
- בנה מטא נתונים M חדשים מ- Metadata S (מטאדטה מקור). לדוגמה, אם Metadata S משתמש ב-[
- החל את העדכון על מכשירי החסימה.
- במידת הצורך, מפה את מחיצות המקור בממפה המכשיר כקריאה בלבד. זה הכרחי עבור טעינת צד מכיוון שמחיצות המקור אינן ממופה לפני העדכון.
- החל עדכון מלא או דלתא על כל מכשירי החסימה בחריץ היעד.
- התקן את המחיצות כדי להפעיל את הסקריפט שלאחר ההתקנה, ולאחר מכן בטל את טעינת המחיצות.
- בטל את מיפוי מחיצות היעד.
זרימת עדכון באמצעות חבילת עדכון מחדש
אם חבילת העדכון מחדש מוחלת על מכשיר שכבר מאפשר מחיצות דינמיות, לקוח 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
המפוצל ומשביתה את השלב שלאחר ההתקנה. - אם ה-base build אכן מגדיר את המשתנים, זה זהה לעדכון טיפוסי עם מחיצות דינמיות. חבילת העדכון מכילה את התמונות עבור מחיצות לוגיות (דינמיות). ניתן להפעיל את השלב שלאחר ההתקנה.
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
כשלב לאחר ההתקנה ודוחה את העדכון.