כללי אזור זמן

אנדרואיד 10 deprecates מנגנון עדכון נתוני APK מבוסס אזור הזמן (הזמין Android 8.1 ו- Android 9) ומחליפים אותו עם מנגנון עדכון מודול APEX מבוסס . AOSP ממשיכה לכלול את קוד הפלטפורמה הדרוש עבור יצרני OEM כדי לאפשר עדכונים מבוססי 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)

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

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

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

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

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

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

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

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

קבצי Distro

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

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

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

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

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

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

התקנת Distro

תהליך ההתקנה של הדיסטרו כולל את השלבים הבאים:

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

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

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

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

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

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

מהימנות

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

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

בִּטָחוֹן

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

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

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

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

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

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

מכין

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

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

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

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

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

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

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

כולל האפליקציות Updater ו- Data בתמונת המערכת

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

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

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

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

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

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

בדיקות xTS

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

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

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

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

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

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

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

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

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

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

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

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

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

  • גירסת פורמט Distro (מז'ור + קטין)
  • מספר גרסה מצטבר (אטום)

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

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

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

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

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

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

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

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

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

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

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

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

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

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