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

ב-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 עד 9)

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

ב-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 לנתונים שלא קיימים (לפורמטים, למחרוזות מותאמות תרבות וכו').

קובצי הפצה

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

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

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

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

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

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

התקנת הפצה

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

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

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

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

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

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

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

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

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

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

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

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

אמינות

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

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

אבטחה

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

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

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

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

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

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

הכנה

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

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

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

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

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

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

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

הכללת האפליקציות Updater ו-Data בקובץ האימג' של המערכת

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

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

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

כדי לאפשר עדכונים של אזורי זמן, יצרני ציוד מקורי יכולים להגדיר את שרת המערכת על ידי שינוי של מאפייני ההגדרה שמוגדרים ב-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, יצרני ציוד מקורי חייבים ליצור גרסה חדשה של אפליקציית הנתונים לכל גרסה נתמכת של Android שהם רוצים לעדכן. לדוגמה, אם יצרן ציוד מקורי רוצה לספק עדכונים למכשירי Android בגרסאות 8.1,‏ 9 ו-10, הוא צריך להשלים את התהליך שלוש פעמים.

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

בשלב הזה, יצרני ציוד מקורי (OEM) לוקחים את ההתחייבויות (commits) של 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: מעדכנים את קוד הגרסה של אפליקציית הנתונים

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

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

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

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

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

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

לאפליקציית הנתונים צריכה להיות אסטרטגיית ניהול גרסאות מתאימה כדי לוודא שהמכשירים יקבלו את קובצי ה-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

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

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

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

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

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

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

קטע המניפסט הבא מכיל את הקבוצה המינימלית של פרויקטי Git שנדרשים כדי לתמוך ב-build של O-MR1 של אפליקציית נתוני אזור הזמן. יצרני ציוד מקורי חייבים להוסיף למניפסט הזה את פרויקטי ה-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" />

הפעלת ה-build של tapas

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

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

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