חוקי אזור זמן

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

עדכוני אזור זמן (אנדרואיד 10+)

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

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

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

לפרטים על מודולים, ראה רכיבי מערכת מודולריים .

עדכוני אזור זמן (אנדרואיד 8.1–9)

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

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

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

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

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

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

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

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

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

קבצי הפצה

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

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

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

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

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

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

התקנת דיסטרו

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

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

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

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

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

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

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

מהימנות

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

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

בִּטָחוֹן

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

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

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

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

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

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

מכין

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

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

יצירת אפליקציית Data

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

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

אפליקציית Data מיועדת להיבנות ב- Tapas build המייצר APKs המתאימות להוספה לתמונת המערכת (למהדורה הראשונית) ולחתום ולהפיץ דרך חנות אפליקציות (לעדכונים הבאים). לפרטים על שימוש בטאפאס, ראה בניית אפליקציית הנתונים באמצעות טאפאס .

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

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

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

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

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

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

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

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

בדיקת xTS

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

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

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

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

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

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

תיקון מערכת/אזור זמן 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: עדכון קוד הגרסה של אפליקציית Data

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

בעת בניית אפליקציית הנתונים באמצעות קבצים שהועתקו 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 באמצעות טאפאס, חותמים על ה-APK שנוצר, ואז בודקים ומשחררים את ה-APK:

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

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

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

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

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

  • גרסת פורמט דיסטרו (מז'ור + מינור)
  • מספר גרסה מתגבר (אטום).

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

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

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

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

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

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

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

בניית אפליקציית Data באמצעות טאפאס

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

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

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

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

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

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

קטע המניפסט הבא מכיל את הסט המינימלי של פרויקטי Git הנחוצים לתמיכה בבניית O-MR1 של אפליקציית Data Zone Time. יצרני 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" />

הפעלת בניית הטאפאס

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

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

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