בניית חבילות 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, והקובץ הבינארי של 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 parameter, ובדרך כלל הוא קבוצת משנה לא מוצהרת של הפרמטרים הנוכחיים של 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 של המכשיר כדי לקבל את הערך של משתני bootloader בזמן האתחול של המכשיר, ולאחר מכן משתמשים בנתונים האלה כדי ליצור טביעת אצבע דינמית של המכשיר.

לדוגמה, כדי להשתמש בחותמות אצבע דינמיות במכשירי 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 סופי.