בניית חבילות OTA

אפשר להשתמש בota_from_target_files שסופק ב-build/make/tools/releasetools כדי ליצור גרסה מלאה ומצטברת חבילות OTA למכשירים שמשתמשים בעדכוני מערכת A/B או עדכוני מערכת שאינם מסוג A/B. הכלי לוקח את קובץ target-files.zip שנוצר על ידי מערכת ה-build של Android כקלט.

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

ב-Android 8.0 הוצאו משימוש חבילות OTA מבוססות-קובץ למכשירים שאינם A/B. במקום זאת, צריך להשתמש בחבילות OTA מבוססות-בלוק. שפת תרגום יצירת חבילות OTA מבוססות בלוקים או מכשירים עם Android מגרסה 7.x ומטה, אישור האפשרות --block לפרמטר ota_from_target_files.

פיתוח עדכונים מלאים

עדכון מלא הוא חבילת OTA שמכילה את כל המצב הסופי של המכשיר (מחיצות המערכת, האתחול והשחזור). כל עוד המכשיר מסוגל לקבל את החבילה ולהחיל אותה, אפשר להתקין את ה-build באמצעות החבילה ללא קשר למצב הנוכחי של המכשיר. לדוגמה, פקודות משתמשות בכלי גרסה כדי לבנות את ארכיון target-files.zip מכשיר tardis.

. build/envsetup.sh && lunch tardis-eng
mkdir dist_output
make dist DIST_DIR=dist_output

make dist יוצר חבילה מלאה של OTA (ב-$OUT). הקובץ .zip שנוצר מכיל את כל מה שדרוש כדי ליצור חבילות OTA למכשיר tardis. אפשר גם לפתח את ota_from_target_files כקובץ בינארי של python ולקרוא לו ליצור חבילות מלאות או מצטברות.

ota_from_target_files dist_output/tardis-target_files.zip ota_update.zip

הנתיב ota_from_target_files מוגדר ב-$PATH, והפיתון שמתקבל הקובץ הבינארי נמצא בספרייה out/.

ota_update.zip מוכן לשליחה של מכשירי בדיקה (הכול חתום במפתח הבדיקה). עבור מכשירי משתמשים, יש ליצור מפתחות פרטיים משלך ולהשתמש בהם בתור שמפורטות במאמר חתימה על גרסאות build.

פיתוח עדכונים מצטברים

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

אפשר להתקין חבילת עדכון מצטבר רק במכשירים עם גרסת build המקור ששימשה ליצירת החבילה. כדי ליצור עדכון מצטבר, נדרש הקובץ target_files.zip מה-build הקודם (הזה הרצוי כדי לעדכן מ-) וגם את הקובץ target_files.zip מה-build החדש. עבור למשל, הפקודות הבאות משתמשות בכלי גרסה כדי ליצור עדכון מצטבר למכשיר tardis.

ota_from_target_files -i PREVIOUS-tardis-target_files.zip dist_output/tardis-target_files.zip incremental_ota_update.zip

ה-build הזה דומה מאוד ל-build הקודם ולעדכון המצטבר החבילה (incremental_ota_update.zip) קטנה בהרבה עדכון מלא (כ-1MB במקום 60MB).

מחלקים חבילה מצטברת רק למכשירים שפועלים בדיוק באותו האופן ה-build הקודם ששימש כנקודת ההתחלה של החבילה המצטברת. עליך להבהב התמונות בPREVIOUS-tardis-target_files.zip או PREVIOUS-tardis-img.zip (שניהם נוצרו באמצעות make dist, כדי להבהב באמצעות fastboot update), במקום את היחידות שבתוך הספרייה PRODUCT_OUT (שנוצרו באמצעות make, שיישמר מהבהב עם fastboot flashall). מתבצע ניסיון להתקין את החבילה המצטברת במכשיר עם תוצאות build אחרות, התקבלה שגיאת התקנה. כאשר ההתקנה נכשלה, המכשיר נשאר באותו מצב עבודה (עם מערכת); החבילה מאמתת את המצב הקודם של כל הקבצים שהיא מעדכנת לפני שנוגעים בהם, כדי שהמכשיר לא יהיה במצב משודרג למחצה.

כדי ליהנות מחוויית המשתמש הטובה ביותר, מומלץ לעדכן באופן מלא כל 3-4 נתונים מצטברים זה עוזר למשתמשים להתעדכן בגרסה האחרונה ולהימנע מזמן ארוך רצף התקנות של עדכונים מצטברים.

פיתוח חבילות OTA לכמה מק"טים

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

מידע על מק"טים

הפורמט של מק"ט הוא וריאציה של מערכת build משולבת , היא בדרך כלל קבוצת משנה לא מוצהרת של הפרמטרים הנוכחיים של build_fingerprint. יצרני ציוד מקורי יכולים להשתמש בכל שילוב של פרמטרים של גרסאות build שאושרו על ידי CDD עבור מק"ט, תוך שימוש גם בתמונה אחת עבור המק"טים האלה. לדוגמה, למק"ט הבא יש כמה וריאציות:

SKU = <product><device><modifierA><modifierB><modifierC>
  • modifierA הוא רמת המכשיר (למשל, Pro, Premium או Plus)
  • modifierB הוא וריאציית החומרה (כמו רדיו)
  • modifierC הוא האזור, שיכול להיות כללי (למשל NA, אירופה, המזרח התיכון ואפריקה (EMEA) או CHN) או ספציפי למדינה או לשפה (למשל JPN, ENG או CHN)

יצרני ציוד מקורי רבים משתמשים בתמונה אחת לכמה מק"טים, ולאחר מכן מייצרים את שם המוצר הסופי ואת טביעת האצבע של המכשיר בסביבת זמן הריצה אחרי שהמכשיר מופעל. התהליך הזה מפשט את תהליך הפיתוח של הפלטפורמה ומאפשר למכשירים עם אבל גם שמות מוצרים שונים כדי לשתף תמונות נפוצות (כמו tardis וגם tardispro).

שימוש בטביעות אצבע דינמיות

טביעת אצבע היא שרשור מוגדר של build פרמטרים כמו ro.product.brand, ro.product.name וגם ro.product.device. טביעת האצבע של המכשיר נובעת מטביעת האצבע של מחיצת המערכת, והיא משמשת כמזהה ייחודי של התמונות (והבייטים) שפועלים במכשיר. כדי ליצור טביעת אצבע דינמית, משתמשים בלוגיקה דינמית בקובץ build.prop של המכשיר כדי מקבלים את הערך של משתני תוכנת האתחול בזמן האתחול של המכשיר, ואז משתמשים בנתונים האלה ליצור טביעת אצבע דינמית למכשיר.

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

  • מעדכנים את הקובץ odm/etc/build_std.prop כך שיכיל את השורה הבאה.

    ro.odm.product.device=tardis

  • מעדכנים את הקובץ odm/etc/build_pro.prop כך שיכיל את השורה הבאה.

    ro.odm.product.device=tardispro

  • מעדכנים את הקובץ odm/etc/build.prop כך שיכיל את השורות הבאות.

    ro.odm.product.device=tardis
import /odm/etc/build_${ro.boot.product.hardware.sku}.prop

השורות האלה מגדירות באופן דינמי את שם המכשיר, טביעת האצבע וערכים של ro.build.fingerprint על סמך הערך של מאפיין bootloader‏ (ro.boot.product.hardware.sku) (שמיועד לקריאה בלבד).

עדכון מטא-נתונים של חבילת OTA

חבילת OTA מכילה קובץ מטא-נתונים (META-INF/com/android/metadata) מתאר את החבילה, כולל את התנאי המוקדם והתנאי המאוחר של ה-OTA חבילה. לדוגמה, הקוד הבא הוא קובץ המטא-נתונים של חבילת OTA שמטרגטת את המכשיר tardis.

post-build=google/tardis/tardis:11/RP1A.200521.001/6516341:userdebug/dev-keys
post-build-incremental=6516341
post-sdk-level=30
post-security-patch-level=2020-07-05
post-timestamp=1590026334
pre-build=google/tardis/tardis:11/RP1A.200519.002.A1/6515794:userdebug/dev-keys
pre-build-incremental=6515794
pre-device=tardis

הערכים pre-device, pre-build-incremental ו-pre-build מגדירים את הערכים של צריך להגדיר את המכשיר כדי שאפשר יהיה להתקין את חבילת ה-OTA. הערכים post-build-incremental ו-post-build מגדירים את מצב המכשיר הצפוי אחרי התקנת חבילת OTA. הערכים של השדות pre- ו-post- נגזרים מהמאפיינים הבאים של ה-build.

  • הערך של pre-device נגזר ממאפיין ה-build ro.product.device.
  • הערכים pre-build-incremental ו-post-build-incremental נגזרים ממאפיין ה-build‏ ro.build.version.incremental.
  • הערכים pre-build ו-post-build נגזרים ממאפיין ה-build‏ ro.build.fingerprint.

במכשירים עם Android מגרסה 11 ואילך, אפשר להשתמש בדגל --boot_variable_file בכלים לעדכון OTA כדי לציין נתיב לקובץ שמכיל את הערכים של משתני זמן הריצה ששימשו ליצירת טביעת האצבע הדינמית של המכשיר. לאחר מכן, הנתונים משמשים לעדכון המטא-נתונים של OTA כך שיכללו את שם המכשיר ואת טביעת האצבע שלו בתנאים pre- ו-post- (באמצעות התו '|' כמפריד). הדגל --boot_variable_file כולל התחביר והתיאור הבאים.

  • תחביר: --boot_variable_file <path>
  • תיאור: מציין נתיב לקובץ שמכיל את הערכים האפשריים של מאפייני ro.boot.*. משמש לחישוב טביעות האצבע הזמינות בסביבת זמן הריצה כאשר מאפייני ro.product.* מסוימים מבוטלים על ידי הצהרת הייבוא. הקובץ צריך לכלול מאפיין אחד בכל שורה, כאשר בכל שורה מופיעים הפרטים הבאים פורמט: prop_name=value1,value2.

לדוגמה, כשהנכס הוא ro.boot.product.hardware.sku=std,pro, המטא-נתונים של OTA למכשירים tardis ו-tardispro מוצגים כפי שמתואר בהמשך.

post-build=google/tardis/tardis:11/<suffix>|google/tardis/tardispro:11/<suffix>
pre-build=google/tardis/tardis:11/<suffix>|google/tardis/tardispro:11/<suffix>
pre-device=tardis|tardispro

כדי לתמוך בפונקציונליות הזו במכשירים עם Android 10, אפשר לעיין בהטמעת העזרה. רשימת השינויים הזו מפענחת באופן מותנה את הצהרות ה-import בקובץ build.prop, וכך מאפשרת לזהות שינויים שמוגדרים מראש בנכס ולהציג אותם במטא-נתונים הסופיים של OTA.