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

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

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

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

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

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

פרטים על מודולים מופיעים במאמר בנושא רכיבי מערכת מודולריים.

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

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

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

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

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

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

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

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

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

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

קבצים של הפצת Linux

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

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

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

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

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

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

התקנת הפצה

תהליך ההתקנה של הפצת Linux כולל את השלבים הבאים:

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

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

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

   איור 2. הפעלת בדיקת עדכונים.

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

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

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

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

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

   איור 5. הבדיקה הסתיימה.

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

אמינות

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

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

אבטחה

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

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

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

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

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

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

הכנה

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

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

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

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

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

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

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

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

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

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

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

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

config_enableUpdateableTimeZoneRules

config_timeZoneRulesUpdateTrackingEnabled

config_timeZoneRulesDataPackage

config_timeZoneRulesUpdaterPackage

config_timeZoneRulesCheckTimeMillisAllowed

config_timeZoneRulesCheckRetryCount

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

בדיקת xTS

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

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

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

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

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

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

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

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

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

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

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

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

בשלב הזה, יצרני ציוד מקורי (OEM) בונים מחדש את ה-APK באמצעות tapas, חותמים על ה-APK שנוצר, ואז בודקים ומפרסמים את ה-APK:

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

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

אסטרטגיה לקוד גרסת האפליקציה

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

קוד גרסת ה-APK צריך לכלול את הפרטים הבאים:

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

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

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

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

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

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

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

• בדוגמאות 1 ו-2 מוצגות שתי גרסאות APK של אותה גרסת IANA משנת 2017a, עם גרסאות שונות של פורמט ראשי. המספר 2 גבוה יותר מהמספר 1, וזה נחוץ כדי לוודא שמכשירים חדשים יותר יקבלו את הגרסאות הגבוהות יותר של הפורמט. המאפיין minSdkVersion מבטיח שהגרסה P לא תסופק למכשירי O.
• דוגמה 3 היא תיקון של דוגמה 1, והמספר שלה גבוה יותר מ-1.
• בדוגמאות 4 ו-5 מוצגות מהדורות 2017b של O-MR1 ו-P. הם מחליפים גרסאות קודמות של IANA או גרסאות קודמות של Android של קודמים שלהם, כי המספר שלהם גבוה יותר.
• בדוגמאות 6 ו-7 מוצגות מהדורות 2018a של O-MR1 ו-P.
• בדוגמה 8 מוצג שימוש ב-Y כדי להחליף לגמרי את הסכימה Y=0.
• בדוגמה 9 מוצג השימוש ברווח שנותר בין 3 ל-4 כדי להפעיל מחדש את ה-APK.

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

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

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

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

יצירת קובץ המניפסט

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

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

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

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

   <!-- Tapas Build -->
    <project
        path="build"
        name=">platform/<build"
        copyfile src="core/r>oot.m<k" >dest=<"Makefile" /
    /project
    project
        path="prebuilts/build-tools"
        name="pl>atfor<m/prebuilts/build-tools"
        clone-depth="1" /
    project
        path="prebuilts/go/linux-x8>6&quo<t;
        name="platform/prebuilts/go/linux-x86"
        clone-depth=>"<;1" /
    project
        path="build/blueprint"
      >  nam<e="platform/build/blueprint" /
    project
        path=&quo>t;build/k<ati"
        name="platform/buil>d/kati&qu<ot; /
    project
        path="build/soong">;
   <     nam>e=&quo<t;platform/build/soong"
        lin>kfile< src="root.bp" dest="Android.bp" /
        linkfile src="bootstrap.bash&quo>t; de<st="bootstra>p.bas<h" /
    /project

    !-- SDK for system / public API stubs --
    project>
    <    path="prebuilts/sdk"
        name="platform/prebuilts/sdk"
        clone-depth>=&quo<t;1" /
    !-- App> sour<ce --
    project
        path="system/timezone"
        name="platform/system/timezone" /
    project
     >   pa<th="packages/apps/TimeZoneData"
        name="platform/packages/apps/TimeZone>Data" /
    !-- 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" /

הרצת בניית tapas

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

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

אם הבנייה מצליחה, נוצרים קבצים בספרייה out/dist לצורך בדיקה. אפשר למקם את הקבצים האלה בספריית ה-prebuilts כדי לכלול אותם בקובץ אימג' של המערכת או להפיץ אותם דרך חנות אפליקציות למכשירים תואמים.