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

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

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

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

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

הכנה

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

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

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

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

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

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

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

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

יצרני ציוד מקורי צריכים למקם את קובצי ה-APK של אפליקציות העדכון והנתונים בספרייה /system/priv-app של תמונת המערכת. לשם כך, הגרסה של תמונת המערכת צריכה לכלול באופן מפורש את יעדי ה-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 מתייחס לכל חבילת בדיקה ספציפית ליצרן ציוד מקורי (OEM) שדומה לחבילות בדיקה רגילות של 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: מעדכנים את קובצי הנתונים של המערכת/אזור הזמן ושל external/icu

בשלב הזה, יצרני ציוד מקורי (OEM) לוקחים קומיטים של Android מהמלאי של system/timezone ושל external/icu מהענפים של release-dev ב-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: מעדכנים את קוד הגרסה של אפליקציית הנתונים

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

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

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

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

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

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

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

   <!-- 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" />

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