פיתוח חבילות 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 הקודם (ה-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 של המכשיר כדי לקבל את הערך של משתני 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 על סמך הערך של מאפיין תוכנת האתחול 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.