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

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

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

חבילות OTA מבוססות-קבצים של Android 8.0 שהוצאו משימוש למכשירים שאינם מסוג 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, והבינארי הבינארי של python ממוקם בספרייה 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_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 על סמך הערך של מאפיין תוכנת האתחול 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 סופי.