כללים לאזור זמן

נתוני אזור הזמן מבוססי ה-APK יצאו משימוש ב-Android 10 מנגנון העדכון (זמין ב-Android 8.1 וב-Android 9) ומחליף אותו ב- מנגנון לעדכון מודולים שמבוסס על APEX. גרסאות 8.1 עד 13 של AOSP עדיין כוללות את קוד הפלטפורמה שנדרש ליצרני ציוד מקורי כדי להפעיל עדכונים המבוססים על APK, כך שהמכשירים משדרגים ל-Android 10 עדיין יכול לקבל עדכונים לגבי נתוני אזור זמן שסופקו על ידי שותף דרך APK. עם זאת, אין להשתמש במנגנון עדכון חבילות ה-APK במכשירים בסביבת הייצור שמקבל גם עדכוני מודול כי עדכון מבוסס APK מחליף עדכון שמבוסס על APEX (כלומר, מכשיר שיקבל עדכון APK יתעלם עדכונים שמבוססים על APEX).

עדכונים לגבי אזור הזמן (Android 10 ואילך)

המודול 'נתוני אזור זמן' שנתמך ב-Android 10 וב- עדכונים לגבי שעון קיץ (DST) ואזורי זמן במכשירי Android, סטנדרטיזציה של נתונים שיכולים להשתנות לעיתים קרובות לגבי דת, פוליטיקה או פוליטיקה מסיבות גיאופוליטיות.

העדכונים משתמשים בתהליך הבא:

  1. IANA מפרסם עדכון למסד הנתונים של אזור הזמן בתגובה ל ממשל אחד או יותר משנים כלל אזור זמן במדינות שלהם.
  2. Google או שותף Android מכינים עדכון למודול הנתונים של אזור הזמן (קובץ APEX) שמכיל את אזורי הזמן המעודכנים.
  3. המכשיר של משתמש הקצה יוריד את העדכון, יופעל מחדש ואז מחיל את משתנה, ולאחר מכן נתוני אזור הזמן של המכשיר יכילו את אזור הזמן החדש מהעדכון.

למידע נוסף על מודולים, ראו רכיבים של מערכות מודולריות.

עדכונים של אזור הזמן (Android מגרסה 8.1 עד 9)

הערה: מנגנון עדכון הנתונים של אזור זמן המבוסס על APK כולל הוסרה לגמרי מ-Android 14 ואילך ולא ניתן למצוא אותה בקוד המקור. השותפים צריכים לעבור באופן מלא אל אזור זמן מודול ראשי.

ב-Android 8.1 וב-Android 9, יצרני ציוד מקורי יכולים להשתמש במנגנון מבוסס APK כדי נתונים מעודכנים של כללי אזור זמן במכשירים בלי צורך בעדכון מערכת. המנגנון הזה מאפשר למשתמשים לקבל עדכונים בזמן אמת (כלומר כל משך החיים של מכשיר Android), ומאפשר לשותפי Android לבדוק עדכונים של אזור הזמן בנפרד מעדכוני תמונות המערכת.

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

קוד מקור ונתונים של אזור הזמן ב-Android

נדרש אזור זמן לכל מכשירי Android ממאגר, גם כאלה שלא משתמשים בתכונה הזו נתונים של כללים והם חייבים להישלח עם קבוצת ברירת מחדל של נתוני כללים לאזורי זמן מחיצה /system. בנתונים האלה נעשה שימוש בקוד הספריות הבאות בעץ המקור של Android:

  • קוד מנוהל מ-libcore/ (לדוגמה, java.util.TimeZone) משתמש ב-tzdata וב- tzlookup.xml קבצים.
  • קוד ספרייה מקורי ב-bionic/ (לדוגמה, mktime, קריאות מערכת מקומיות) משתמש בקובץ tzdata.
  • קוד ספריית ICU4J/ICU4C בexternal/icu/ משתמש ב-ICu קובץ .dat.

הספריות האלה עוקבות אחרי קובצי שכבות-על שעשויים להיות ספריית /data/misc/zoneinfo/current. המערכת מצפה לקובצי שכבת-על כך שיכיל נתונים משופרים על כללי אזור הזמן, ועל ידי מתן אפשרות לעדכן מכשירים ללא שינוי ב-/system.

רכיבי מערכת של Android שצריכים נתונים לפי כלל של אזור זמן בודקים את הדברים הבאים מיקומים ראשונים:

  • הקוד libcore/ וקוד bionic/ משתמשים ב עותק /data של tzdata ושל tzlookup.xml .
  • קוד ICU4J/ICU4C משתמש בקבצים שב-/data וחוזר /system קובצי נתונים שאינם קיימים (לפורמטים, מותאם לשוק המקומי מחרוזות וכו').

קובצי Distro

קובצי .zip של Distro מכילים את קובצי הנתונים שדרושים לאכלוס הספרייה /data/misc/zoneinfo/current. גם קובצי ה-Distro כוללים מטא-נתונים שמאפשרים למכשירים לזהות בעיות בניהול גרסאות.

הפורמט של הקובץ Distro תלוי במהדורת Android, כי התוכן משתנים בהתאם לגרסת ה-ICU, לדרישות פלטפורמת Android ולגרסה אחרת שינויים. ב-Android אפשר לקבל קובצי הפצה לגרסאות Android נתמכות לכל עדכון IANA (בנוסף לעדכון קובצי המערכת של הפלטפורמה). כדי לשמור על מעודכנים, יצרני ציוד מקורי יכולים להשתמש בקובצי ההפצה האלה או ליצור קבצים משלהם באמצעות עץ המקור של Android (שמכיל את הסקריפטים וקבצים אחרים שנדרשים כדי כדי ליצור קובצי Distro).

רכיבי עדכון של אזור זמן

עדכון של כללי אזור זמן כולל העברה של קובצי הפצה אל במכשיר ובהתקנה בטוחה של הקבצים שבתוכה. העברה ו כדי להתקין את האפליקציה:

  • הפונקציונליות של שירות הפלטפורמה (timezone.RulesManagerService), והוא מושבת כברירת מחדל. יצרני ציוד מקורי (OEM) צריכים להפעיל את הפונקציונליות באמצעות הגדרות אישיות. RulesManagerService פועל בתהליך ובשלבים של שרת המערכת פעולות לעדכון אזור זמן באמצעות כתיבה אל /data/misc/zoneinfo/staged. RulesManagerService יכולה גם החלפה או מחיקה של פעולות שכבר נערכו.
  • TimeZoneUpdater אפליקציית מערכת שלא ניתנת לעדכון (מוכרת גם כאפליקציית Updater). יצרני ציוד מקורי חייבים לכלול את האפליקציה הזו בתמונת המערכת של מכשירים שמשתמשים בתכונה.
  • OEM TimeZoneData אפליקציית מערכת שניתנת לעדכון (כלומר אפליקציית הנתונים) שנושאת קובצי הפצה למכשיר ויוצרת אותם. זמין לאפליקציית Updater. יצרני ציוד מקורי חייבים לכלול את האפליקציה הזו בתמונת המערכת של מכשירים שמשתמשים בתכונה.
  • tzdatacheck קובץ בינארי בזמן האתחול שנדרש לפעולה הנכונה ובטוחה של עדכוני אזור הזמן.

עץ המקור של Android מכיל קוד מקור גנרי רכיבים שונים, שיצרן הציוד המקורי יכול לבחור להשתמש בהם מבלי לבצע בהם שינויים. בדיקת הקוד כדי לאפשר ליצרני ציוד מקורי לבדוק באופן אוטומטי שהם הפעילו את התכונה בצורה נכונה.

התקנת דיסקו

תהליך ההתקנה של Distro כולל את השלבים הבאים:

  1. אפליקציית הנתונים מתעדכנת באמצעות הורדה מחנות אפליקציות או טעינה ממקור לא ידוע. תהליך שרת המערכת (באמצעות timezone.RulesManagerServer/timezone.PackageTracker כיתות) שעונים כדי לבדוק אם יש שינויים בחבילה של אפליקציית הנתונים שהוגדרה שספציפית ל-OEM (יצרן הציוד המקורי) שם.

    עדכונים לאפליקציית נתונים

    איור 1. עדכונים לאפליקציית נתונים.

  2. תהליך שרת המערכת מפעיל בדיקת עדכונים באמצעות שידור Intent מטורגט עם אסימון ייחודי לשימוש חד-פעמי, ל-Updater בקשה שרת המערכת עוקב אחרי האסימון האחרון שהוא יצר כדי יכול לקבוע מתי הושלמה הבדיקה האחרונה שהופעלה. כל סוג אחר המערכת מתעלמת מאסימונים.

    עדכון גורם מפעיל

    איור 2. הפעלה של בדיקת עדכון.

  3. במהלך בדיקת העדכון, אפליקציית Updater מבצעת את המשימות הבאות:
    • שליחת שאילתות על מצב המכשיר הנוכחי על ידי קריאה ל- RulesManagerService.

      קריאה ל- RulesManagerService

      איור 3. עדכונים לאפליקציית נתונים, קריאה ל- RulesManagerService.

    • שולח שאילתות לאפליקציית הנתונים על ידי שליחת שאילתה על כתובת URL מוגדרת היטב של ContentProvider כדי לקבל מידע על ההתפלגות.

      קבלת מידע על הפצה

      איור 4. עדכונים לאפליקציית נתונים, קבלת מידע על Distro.

  4. אפליקציית Updater נוקטת את הפעולה המתאימה בהתאם מידע שיש לו. הפעולות הזמינות כוללות:
    • מבקשים התקנה. המערכת קוראת את נתוני ההפצה מאפליקציית הנתונים והוא מועבר אל RulesManagerService בשרת המערכת. ב- RulesManagerService מאשרים מחדש שהגרסה והתוכן של פורמט Distro שמתאים למכשיר ומבצע את ההתקנה.
    • מבקשים הסרה (זה נדיר). לדוגמה, אם בוצע עדכון מתבצעת השבתה או הסרה של ה-APK באפליקציה /data, והמכשיר חוזר לגרסה הנוכחית ב-/system.
    • לא לעשות דבר. קורה כאשר מתגלה שההפצה של אפליקציית הנתונים לא חוקית.
    בכל המקרים, אפליקציית Updater קוראת ל- RulesManagerService באמצעות אסימון הביקורת כך ששרת המערכת יודע שהבדיקה הושלמה בהצלחה.

    הבדיקה הושלמה

    איור 5. הבדיקה הושלמה.

  5. אתחול ו-tzdatacheck. כשהמכשיר הבא יופעל, הבינארי של tzdatacheck מבצע כל פעולה מדורגת. הקובץ הבינארי של tzdatacheck יכול לבצע את המשימות הבאות:
    • מבצעים את הפעולה המדורגת על ידי טיפול ביצירה, בהחלפה, ו/או מחיקה של /data/misc/zoneinfo/current הקבצים לפני רכיבי מערכת אחרים פתחו והתחילו להשתמש בקבצים.
    • יש לוודא שהקבצים ב-/data נכונים עבור הנוכחי בגרסת פלטפורמה, וייתכן שזה לא המצב אם המכשיר קיבל לאחרונה עדכון מערכת והגרסה של פורמט Distro השתנתה.
    • מוודאים שהגרסה של כללי IANA היא אותה הגרסה או חדשה יותר מהגרסה שבה /system הפעולה הזו מספקת הגנה מפני עדכון מערכת שיוצא מהמכשיר עם נתונים ישנים יותר של כללי אזור זמן מאלה שקיימים ב/system תמונה.

אמינות

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

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

אבטחה

כאשר מופעל, הקוד RulesManagerService בשרת המערכת מבצע מספר בדיקות כדי לוודא שהמערכת בטוחה לשימוש.

  • בעיות שמציינות תמונת מערכת שהוגדרה בצורה לא תקינה מונעות מהמכשיר אתחול; לדוגמה: הגדרות לא נכונות של Updater או של אפליקציית נתונים, המעדכן או אפליקציית הנתונים לא נמצאות ב-/system/priv-app.
  • בעיות שמציינות שאפליקציית נתונים לא תקינה לא מונעות אתחול המכשיר אבל כן ימנעו הפעלה של בדיקת עדכונים. דוגמאות כוללים מחסור בהרשאות מערכת נדרשות, או שאפליקציית הנתונים לא חושפת ContentProvider ב-URI הצפוי.

הרשאות הקובץ עבור הספריות /data/misc/zoneinfo הן אכיפה באמצעות כללי SELinux. כמו בכל APK, אפליקציית הנתונים חייבת להיות חתומה על ידי אותו מפתח שמשמש לחתימה על הגרסה של /system/priv-app. אפליקציית הנתונים צפוי להיות שם חבילה ומפתח ייעודיים שספציפיים ל-OEM.

שילוב עדכונים של אזורי זמן

כדי להפעיל את תכונת העדכון של אזור הזמן, יצרני ציוד מקורי (OEM) בדרך כלל:

  • ליצור אפליקציית נתונים משלהם.
  • הכללת האפליקציות המעדכן ונתונים ב-build של קובץ האימג' של המערכת.
  • מגדירים את שרת המערכת כדי להפעיל את RulesManagerService.

התכוננות לבחינות

לפני שמתחילים, יצרני ציוד מקורי צריכים לעיין במדיניות, בבקרת איכות, ושיקולי אבטחה:

  • ליצור חתימה ייעודית ספציפית לאפליקציה עבור אפליקציית הנתונים שלהם.
  • יצירת אסטרטגיה של גרסאות וניהול גרסאות לעדכונים של אזור זמן כדי להבין אילו מכשירים יעודכנו ואיך הם יכולים להבטיח העדכונים מותקנים רק במכשירים שצריכים אותם. לדוגמה, ייתכן שיצרני ציוד מקורי (OEM) ירצו הם יכולים להשתמש באפליקציית נתונים אחת לכל המכשירים שלהם, או שהם יכולים לבחור להשתמש אפליקציות נתונים למכשירים שונים. ההחלטה משפיעה על בחירת החבילה שם, אולי קודי הגרסאות שבהם נעשה שימוש ואסטרטגיית בקרת האיכות.
  • להבין אם הם רוצים להשתמש בנתוני אזור זמן של Android ממאגר מתוך AOSP, או ליצור מצגות משלהם.

יצירה של אפליקציית נתונים

AOSP כולל את כל כללי המקור וה-build שנדרשים ליצירת אפליקציית נתונים ב- packages/apps/TimeZoneData, עם הוראות ותבניות לדוגמה עבור AndroidManifest.xml וקבצים אחרים שנמצאים ב- packages/apps/TimeZoneData/oem_template. תבניות לדוגמה כוללות גם יעד build ל-APK האמיתי של אפליקציית Data וגם יעדים נוספים עבור יצירת גרסאות בדיקה של אפליקציית הנתונים.

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

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

יצרני ציוד מקורי חייבים להתקין את אפליקציית הנתונים המובנית מראש בתמונת המערכת של מכשיר /system/priv-app לכלול חבילות APK מוכנות מראש (נוצרו על ידי מנות טאפאס תהליך build) בתמונת המערכת, יצרני ציוד מקורי יכולים להעתיק את הקבצים לדוגמה packages/apps/TimeZoneData/oem_template/data_app_prebuilt תבניות לדוגמה כוללות גם יעדי build להכללת גרסאות בדיקה של אפליקציית נתונים בחבילות בדיקה.

הכללת האפליקציות המעדכן והנתונים בתמונת המערכת

יצרני ציוד מקורי חייבים להציב את חבילות ה-APK של ה-Updater ושל אפליקציית הנתונים ב- הספרייה /system/priv-app של תמונת המערכת. כדי לעשות את זה, גרסת ה-build של קובץ האימג' של המערכת חייבת לכלול במפורש את אפליקציית ה-Updater ואת אפליקציית הנתונים המובנים מראש יעדים.

צריך לחתום על אפליקציית Updater באמצעות מפתח פלטפורמה ולכלול אותה אפליקציית מערכת אחרת. היעד מוגדר packages/apps/TimeZoneUpdater בתור TimeZoneUpdater. ההכללה של אפליקציות נתונים היא ספציפית ל-OEM ותלויה בשם היעד שנבחר עבור ליצור מראש.

הגדרת שרת המערכת

כדי להפעיל עדכונים של אזור הזמן, יצרני ציוד מקורי יכולים להגדיר את שרת המערכת על ידי ביטול מאפייני התצורה שמוגדרים ב frameworks/base/core/res/res/values/config.xml

נכס תיאור נדרש שינוי מברירת המחדל? 
config_enableUpdateableTimeZoneRules
 יש להגדיר את הערך כ-true כדי להפעיל את RulesManagerService. כן 
config_timeZoneRulesUpdateTrackingEnabled
 חובה להגדיר את הערך true כדי שהמערכת תאזין לשינויים אפליקציית הנתונים. כן 
config_timeZoneRulesDataPackage
 שם החבילה של אפליקציית הנתונים הספציפית ל-OEM. כן 
config_timeZoneRulesUpdaterPackage
 מוגדר לאפליקציית ברירת המחדל למעדכן. יש לשנות רק כאשר מספקים שונות של הטמעה של אפליקציית Updater. לא 
config_timeZoneRulesCheckTimeMillisAllowed
 משך הזמן המותר בין הפעלת בדיקת עדכונים על ידי RulesManagerService והתקנה, הסרה או תגובה מסוג 'לא לעשות כלום'. אחרי יכול להיווצר טריגר ספונטני למהימנות. לא 
config_timeZoneRulesCheckRetryCount
 מספר בדיקות העדכון הרציפות שנכשלו שמותרות לפני RulesManagerService מפסיק ליצור פריטים נוספים. לא

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

בדיקת xTS

xTS מתייחס לכל חבילת בדיקות ספציפית ל-OEM שדומה ל-Android סטנדרטי חבילות בדיקה באמצעות TradeF (כגון CTS ו-VTS). יצרני ציוד מקורי (OEM) שעושים בדיקה כזו בסוויטות אפשר להוסיף את בדיקות העדכון של אזורי הזמן של Android שמפורטות בהמשך מיקומים:

  • packages/apps/TimeZoneData/testing/xts כולל את הקוד הדרושה לבדיקות פונקציונליות אוטומטיות בסיסיות.
  • packages/apps/TimeZoneData/oem_template/xts מכיל דוגמה מבנה ספריות שכולל בדיקות בחבילת xTS דמוית מסחר אלקטרוני. בדומה ל- מצופה מיצרני ציוד מקורי להעתיק ולהתאים אישית את ספריות התבניות האחרות שלהם לצרכים שלכם.
  • packages/apps/TimeZoneData/oem_template/data_app_prebuilt מכיל הגדרת זמן build כדי לכלול את חבילות ה-APK המוכנות מראש לבדיקה שנדרשות של הבדיקה.

יצירת עדכונים לאזור זמן

כש-IANA מפרסמים קבוצה חדשה של כללי אזור זמן, ספריות הליבה של Android הצוות יוצר תיקונים לעדכון גרסאות ב-AOSP. יצרני ציוד מקורי שמשתמשים במלאי Android קובצי המערכת וההפצה יכולים לזהות את שמירות האלה, להשתמש בהם כדי ליצור גרסה של אפליקציית הנתונים שלהם, ואז לפרסם את הגרסה החדשה כדי לעדכן את המכשירים בסביבת הייצור.

אפליקציות נתונים מכילות קובצי Distro שקשורים מאוד לגרסאות Android, יצרני ציוד מקורי חייבים ליצור גרסה חדשה של אפליקציית הנתונים לכל כל נתמך גרסת Android שיצרן הציוד המקורי רוצה לעדכן. לדוגמה, אם OEM (יצרן ציוד מקורי) רוצה מספקים עדכונים ל-Android בגרסאות 8.1, 9 ו-10 מכשירים, עליהם להשלים את התהליך שלוש פעמים.

שלב 1: מעדכנים את קובצי הנתונים של המערכת/אזור הזמן, וגם קובצי נתונים חיצוניים או icu

בשלב הזה, יצרני ציוד מקורי מקבלים התחייבויות ל-Android לגבי system/timezone ו-external/icu מ- הסתעפויות משחררים-מפתחים ב-AOSP ולהחיל את ההתחייבויות האלה על עותק של בקוד המקור של Android.

תיקון ה-AOSP של המערכת/אזור הזמן מכיל קבצים מעודכנים ב- system/timezone/input_data והקבוצה system/timezone/output_data. יצרני ציוד מקורי (OEM) שצריכים עוד מוצרים מקומיים יכולים לשנות את קובצי הקלט ואז להשתמש בקבצים system/timezone/input_data וexternal/icu עד ליצור קבצים ב-output_data.

הקובץ החשוב ביותר הוא system/timezone/output_data/distro/distro.zip, כלומר נכללים אוטומטית בתהליך היצירה של ה-APK של אפליקציית הנתונים.

שלב 2: מעדכנים את קוד הגרסה של אפליקציית הנתונים

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

כשאתם יוצרים את אפליקציית הנתונים באמצעות קבצים שהועתקו מ: package/apps/TimeZoneData/oem_template/data_app, אפשר למצוא את קוד הגרסה/שם הגרסה שהוחלו על ה-APK ב-Android.mk: 

TIME_ZONE_DATA_APP_VERSION_CODE :=
TIME_ZONE_DATA_APP_VERSION_NAME :=

ניתן למצוא ערכים דומים ב-testing/Android.mk (עם זאת, קודי הגרסה לבדיקה חייבים להיות גבוהים יותר מגרסת התמונה של המערכת). לפרטים, אסטרטגיה לקוד גרסה לדוגמה scheme; אם משתמשים בסכימה לדוגמה או בסכימה דומה, אין צורך לעדכן את קודי הגרסאות כי הם צפויים להיות גבוהים יותר מאשר בקוד של הגרסה האמיתית.

שלב 3: בנייה מחדש, חתימה, בדיקה ופרסום

בשלב הזה, יצרני ציוד מקורי בונים מחדש את ה-APK באמצעות טאפאס, וחותמים על לאחר מכן בודקים את ה-APK ומשחררים אותו:

  • עבור מכשירים שלא פורסמו (או בעת הכנה של עדכון מערכת עבור המכשיר שפורסם), צריך לשלוח את חבילות ה-APK החדשות בספרייה המובנית מראש של אפליקציית הנתונים כדי לוודא שתמונת המערכת ובדיקות ה-xTS כוללות את חבילות ה-APK העדכניות ביותר. יצרני ציוד מקורי צריכים ולוודא שהקובץ החדש פועל כראוי (כלומר הוא עובר CTS בדיקות אוטומטיות וידניות ספציפיות ל-OEM).
  • במכשירים שפורסמו וכבר לא מקבלים עדכוני מערכת, ה-APK החתום יכול להיות משוחרר רק דרך חנות אפליקציות.

יצרני ציוד מקורי (OEM) אחראים לאבטחת איכות ולבדיקת הגרסאות העדכניות אפליקציית נתונים במכשירים שלהם לפני ההפצה.

אסטרטגיית קוד של גרסת אפליקציית נתונים

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

קוד הגרסה של ה-APK צריך לכלול את המידע הבא:

  • גרסה של פורמט Distro (ראשית + משנית)
  • מספר גרסה עולה (אטום)

בשלב הזה, רמת ה-API של הפלטפורמה קשורה באופן הדוק לגרסת הפורמט של ההפצה כי כל רמת API משויכת בדרך כלל לגרסה חדשה של ICU ( הופכת את קובצי ה-Distro ללא תואמים). בעתיד, מערכת Android עשויה לשנות את זה כך שקובץ Distro יכול לפעול בכמה גרסאות של פלטפורמת Android (וגם API) ברמה הזו לא נעשה שימוש בסכימת קוד הגרסה של אפליקציית הנתונים).

דוגמה לאסטרטגיה של קוד גרסה

סכימת המספרים של ניהול הגרסאות לדוגמה מבטיחה שפורמט פריסה גבוה יותר גרסאות מחליפות את הגרסאות של פורמט ההפצה הנמוך יותר. האפליקציה AndroidManifest.xml משתמשת בandroid:minSdkVersion כדי לוודא שמכשירים ישנים לא מקבלים גרסאות בפורמט דיסטרו גבוה יותר יותר ממה שהם יכולים לטפל בו.

בדיקת גרסה

איור 6. דוגמה לאסטרטגיה של קוד גרסה.

דוגמה ערך המטרה
כן שמורה ההרשאה הזו מאפשרת להשתמש בסכמות או ב-APKs חלופיים בעתיד. היא בהתחלה (במרומז) 0. מאחר שהסוג הבסיסי הוא סוג int חתום של 32 ביט, הסכמה זו תומכת עד שתי גרסאות עתידיות של סכימת מספור.
01 הגרסה של הפורמט הראשי עוקב אחר גרסה של פורמט ראשי בן 3 ספרות אחרי הנקודה העשרונית. פורמט Distro תומך צריך להשתמש ב-3 ספרות אחרי הנקודה העשרונית, אבל רק ב-2 ספרות. לא סביר שהוא יגיע ל-100 בהינתן ההגדלה העיקרית הצפויה לכל רמת API. הגרסה הראשית 1 מקבילה לרמת API 27.
1 גרסת הפורמט המשני עוקב אחר גרסת הפורמט המשני בן 3 הספרות. פורמט Distro תומך מורכב מ-3 ספרות אחרי הנקודה העשרונית, אבל רק ספרה אחת משמשת כאן. לא סביר שהוא יגיע ל-10.
X שמורה הוא 0 לגרסאות ייצור (ועשוי להיות שונה ב-APKs לבדיקה).
ZZZZZ (ZZZZZ) מספר גרסה אטום מספר עשרוני מוקצה לפי דרישה. כולל פערים לאפשר הצגת מודעות מעברון לבצע עדכונים לפי הצורך.

ניתן היה לדחוס את הסכמה בצורה טובה יותר אם משתמשים בבינארי במקום בעשרוני, לסכימה הזו יש יתרון שהוא קריא לאנשים. אם טווח המספרים המלא לא נותרו כספים, שם החבילה של אפליקציית הנתונים עשוי להשתנות.

שם הגרסה מייצג את הפרטים באופן קריא לאנשים, עבור לדוגמה: major=001,minor=001,iana=2017a, revision=1,respin=2. בטבלה הבאה מפורטות דוגמאות.

# קוד גירסה minSdkVersion {Major format version},{Minor format version},{כללי IANA version},{Revision}
1 11000010 O-MR1 upper=001,minor=001,iana=2017a,revision=1
2 21000010 P upper=002,minor=001,iana=2017a,revision=1
3 11000020 O-MR1 upper=001,minor=001,iana=2017a,revision=2
4 11000030 O-MR1 upper=001,minor=001,iana=2017b,revision=1
5 21000020 P larger=002,minor=001,iana=2017b,revision=1
6 11000040 O-MR1 Central=001,minor=001,iana=2018a,revision=1
7 21000030 P upper=002,minor=001,iana=2018a,revision=1
8 1123456789 - -
9 11000021 O-MR1 upper=001,minor=001,iana=2017a,revision=2,respin=2
  • בדוגמאות 1 ו-2 מופיעות שתי גרסאות של APK לאותה גרסת IANA של שנת 2017 עם גרסאות ראשיות שונות. הערך 2 גבוה מ-1, כלומר כדי להבטיח שמכשירים חדשים יותר יקבלו את הגרסאות בפורמט הגבוה יותר. minSdkVersion מבטיח שגרסת P לא תספק למכשירי O.
  • דוגמה 3 היא תיקון או תיקון עבור 1, מבחינת מספר היא גבוהה יותר מ-1.
  • בדוגמאות 4 ו-5 אפשר לראות גרסאות של O-MR1 ו-P משנת 2017. בצורה מספרית הם מחליפים גרסאות IANA קודמות או גרסאות Android קודמות של הגרסאות הקודמות.
  • בדוגמאות 6 ו-7 מוצגות גרסאות O-MR1 ו-P משנת 2018a.
  • דוגמה 8 ממחישה את השימוש ב-Y כדי להחליף לחלוטין את הסכמה Y=0.
  • דוגמה 9 ממחישה את השימוש בפער שנותר בין 3 ל-4 כדי לסובב מחדש APK.

כי כל מכשיר נשלח עם APK עם גרסה מתאימה שמוגדרת כברירת מחדל קובץ אימג' של המערכת, אין סיכון שתותקן גרסת O-MR1 במכשיר P כי יש לה מספר גרסה נמוך יותר מזה של גרסת תמונת מערכת P. א' מכשיר עם גרסת O-MR1 שמותקנת ב-/data ולאחר מכן מקבלת עדכון מערכת ל-P משתמש בגרסת /system בעדיפות גרסת O-MR1 ב /data כי גרסת P תמיד גבוהה יותר מאשר כל אפליקציה שמיועדת ל-O-MR1.

פיתוח אפליקציית הנתונים באמצעות טאפאס

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

טאפאס היא גרסה מצומצמת יותר של גרסת ה-build של Android שמשתמשת בעץ מקור מצומצם כדי לייצר גרסאות של תרגום מכונה. יצרני ציוד מקורי (OEM) שמכירים את מערכת ה-build הרגילה של Android צריכים לזהות את קבצים מגרסת ה-build הרגילה של פלטפורמת Android.

יצירת המניפסט

בדרך כלל ניתן ליצור עץ מקור מצומצם באמצעות קובץ מניפסט מותאם אישית מתייחס רק לפרויקטים של Git שדרושים למערכת ה-build ולבניית אפליקציה. אחרי שביצעתם את ההוראות ב- כשיוצרים אפליקציית נתונים, יצרני ציוד מקורי צריכים לפחות שני פרויקטים של Git ספציפיים ל-OEM (יצרן הציוד המקורי) שנוצרו באמצעות קובצי התבנית שכאן packages/apps/TimeZoneData/oem_template:

  • פרויקט Git אחד מכיל קובצי אפליקציה כמו המניפסט קובצי build שנדרשים כדי ליצור את קובץ ה-APK של האפליקציה (לדוגמה, vendor/oem/apps/TimeZoneData). הפרויקט הזה גם מכיל כללי build לחבילות APK לבדיקה, שיכולות לשמש בדיקות xTS.
  • פרויקט אחד של Git מכיל את חבילות ה-APK החתומות שנוצרו על ידי גרסת ה-build של האפליקציה עבור לכלול את בדיקות ה-build ו-xTS של המערכת.

ה-build של האפליקציה משתמש בכמה פרויקטים אחרים של Git שמשותפים עם או שמכילות ספריות קוד שלא תלויות ב-OEM.

קטע הקוד של המניפסט הבא מכיל את הקבוצה המינימלית של פרויקטים ב-Git שנדרשים כדי לתמוך בגרסת O-MR1 של אפליקציית 'נתונים' של אזור הזמן. יצרני ציוד מקורי (OEM) חייבים להוסיף פרויקטי Git ספציפיים ל-OEM (שכוללים בדרך כלל פרויקט מכיל את אישור החתימה) למניפסט הזה, והוא עשוי להגדיר להסתעפויות בהתאם.

   <!-- Tapas Build -->
    <project
        path="build"
        name="platform/build">
        <copyfile src="core/root.mk" dest="Makefile" />
    </project>
    <project
        path="prebuilts/build-tools"
        name="platform/prebuilts/build-tools"
        clone-depth="1" />
    <project
        path="prebuilts/go/linux-x86"
        name="platform/prebuilts/go/linux-x86"
        clone-depth="1" />
    <project
        path="build/blueprint"
        name="platform/build/blueprint" />
    <project
        path="build/kati"
        name="platform/build/kati" />
    <project
        path="build/soong"
        name="platform/build/soong">
        <linkfile src="root.bp" dest="Android.bp" />
        <linkfile src="bootstrap.bash" dest="bootstrap.bash" />
    </project>

    <!-- SDK for system / public API stubs -->
    <project
        path="prebuilts/sdk"
        name="platform/prebuilts/sdk"
        clone-depth="1" />
    <!-- App source -->
    <project
        path="system/timezone"
        name="platform/system/timezone" />
    <project
        path="packages/apps/TimeZoneData"
        name="platform/packages/apps/TimeZoneData" />
    <!-- Enable repohooks -->
    <project
        path="tools/repohooks"
        name="platform/tools/repohooks"
        revision="main"
        clone_depth="1" />
    <repo-hooks
        in-project="platform/tools/repohooks"
        enabled-list="pre-upload" />

הפעלה של גרסת הטאפאס

לאחר יצירת עץ המקור, מפעילים את ה-build של טאפאס באמצעות הפקודות הבאות:

source build/envsetup.sh
tapas
make -j30 showcommands dist TARGET_BUILD_APPS='TimeZoneData TimeZoneData_test1 TimeZoneData_test2'  TARGET_BUILD_VARIANT=userdebug

גרסת build מוצלחת יוצרת קבצים בספרייה out/dist עבור בדיקה. ניתן למקם את הקבצים האלה בספרייה המובנית מראש כדי לכלול אותם את תמונת המערכת ו/או מופצת דרך חנות אפליקציות לצורך מכשירים.