ב-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. כך מתבצע סטנדרטיזציה של נתונים שעשויים להשתנות לעיתים קרובות מסיבות דתיות, פוליטיות וגיאו-פוליטיות.
העדכונים מתבצעים לפי התהליך הבא:
- IANA מפרסמת עדכון למסד הנתונים של אזורי הזמן בתגובה לשינוי של כלל אזור זמן במדינה אחת או יותר.
- Google או שותף Android מכינים עדכון של מודול נתוני אזור הזמן (קובץ APEX) שמכיל את אזורי הזמן המעודכנים.
- מכשיר משתמש הקצה מוריד את העדכון, מופעל מחדש ומחיל את השינויים. לאחר מכן, נתוני אזור הזמן של המכשיר מכילים את נתוני אזור הזמן החדש מהעדכון.
פרטים על מודולים זמינים במאמר רכיבי מערכת מודולריים.
עדכוני אזורי זמן (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 של Distro מכילים את קובצי הנתונים שנדרשים כדי לאכלס את הספרייה /data/misc/zoneinfo/current. קובצי המינויים מכילים גם מטא-נתונים שמאפשרים למכשירים לזהות בעיות בגרסאות.
פורמט הקובץ של המהדורה תלוי במהדורת Android, כי התוכן משתנה בהתאם לגרסה של ICU, לדרישות של פלטפורמת Android ולשינויים אחרים במהדורה. Android מספקת קובצי הפצה לגרסאות נתמכות של Android בכל עדכון של IANA (בנוסף לעדכון של קובצי המערכת בפלטפורמה). כדי שהמכשירים שלהם יהיו עדכניים, יצרני ציוד מקורי יכולים להשתמש בקובצי ההפצה האלה או ליצור משלהם באמצעות עץ המקור של Android (שמכיל את הסקריפטים וקבצים אחרים שדרושים ליצירת קובצי Distro).
רכיבי העדכון של אזור הזמן
עדכון של כללי אזור הזמן כולל העברה של קובצי הפצה למכשיר והתקנה בטוחה של הקבצים שבתוכם. כדי לבצע את ההעברה וההתקנה, נדרשים:
- פונקציונליות של שירות פלטפורמה (
timezone.RulesManagerService), מושבתת כברירת מחדל. יצרני ציוד מקורי צריכים להפעיל את הפונקציונליות באמצעות הגדרה. הפונקציהRulesManagerServiceפועלת בתהליך של שרת המערכת ומעדכנת את אזור הזמן באמצעות כתיבה ב-/data/misc/zoneinfo/staged. אפשר גם להשתמש ב-RulesManagerServiceכדי להחליף או למחוק פעולות שכבר הוגדרו בתהליך ההרצה. -
TimeZoneUpdater, אפליקציית מערכת שלא ניתן לעדכן (שנקראת גם אפליקציית העדכון). יצרני ציוד מקורי חייבים לכלול את האפליקציה הזו בתמונת המערכת של מכשירים שמשתמשים בתכונה. - OEM
TimeZoneData, אפליקציית מערכת שניתן לעדכן (שנקראת גם אפליקציית הנתונים) שנושאת את קובצי המינויים למכשיר ומאפשרת להם להיות זמינים לאפליקציית העדכון. יצרני ציוד מקורי חייבים לכלול את האפליקציה הזו בתמונת המערכת של המכשירים שמשתמשים בתכונה. -
tzdatacheck, קובץ בינארי בזמן האתחול שנדרש לפעולה הנכונה ובטוחה של עדכוני אזור הזמן.
עץ המקור של Android מכיל קוד מקור גנרי לרכיבים שלמעלה, שבהם יצרני הציוד המקורי יכולים להשתמש ללא שינוי. קוד הבדיקה מאפשר ליצרני ציוד מקורי לבדוק באופן אוטומטי שהם הפעילו את התכונה בצורה נכונה.
התקנת הפצה
תהליך התקנת הפצת Linux כולל את השלבים הבאים:
- העדכון של אפליקציית הנתונים מתבצע באמצעות הורדה מחנות האפליקציות או טעינה ממקור לא ידוע. תהליך שרת המערכת (דרך הכיתות
timezone.RulesManagerServer/timezone.PackageTracker) מחפש שינויים בשם החבילה של אפליקציית הנתונים שהוגדרה, ספציפית ליצרן הציוד המקורי.
איור 1. עדכונים לאפליקציית נתונים.
- תהליך שרת המערכת מפעיל בדיקת עדכון על ידי שידור Intent ממוקד עם אסימון ייחודי לשימוש חד-פעמי אל אפליקציית Updater. שרת המערכת עוקב אחרי האסימון האחרון שהוא יצר כדי שהוא יכול לקבוע מתי הבדיקה האחרונה שהוא הפעיל הושלמה ומתעלמים מהאסימונים האחרים.
איור 2. מפעילים בדיקה של עדכונים.
- במהלך בדיקת העדכון, אפליקציית Updater מבצעת את המשימות הבאות:
- שליחת שאילתות על מצב המכשיר הנוכחי על ידי קריאה ל- RulesManagerService.
איור 3. עדכונים של אפליקציית נתונים, קריאה ל-RulesManagerService.
- שליחת שאילתות לאפליקציית Data על ידי שליחת שאילתות על כתובת URL ומפרטי עמודות של ContentProvider מוגדרים היטב כדי לקבל מידע על ההפצה.
איור 4. עדכוני אפליקציות נתונים, קבלת מידע על הפצה.
- שליחת שאילתות על מצב המכשיר הנוכחי על ידי קריאה ל- RulesManagerService.
- אפליקציית Updater מבצעת את הפעולה המתאימה על סמך המידע שיש לה. הפעולות הזמינות כוללות:
- שולחים בקשה להתקנה. נתוני המפצה נקרא מאפליקציית הנתונים ומועברים ל-RulesManagerService בשרת המערכת. השירות RulesManagerService מאשר מחדש שהגרסה והתוכן של פורמט ההפצה מתאימים למכשיר, ומארגן את ההתקנה.
- לבקש הסרה (מקרה נדיר). לדוגמה, אם קובץ ה-APK המעודכן ב-
/dataמושבת או מוסר והמכשיר חוזר לגרסה שקיימת ב-/system. - לא לעשות דבר. מתרחשת כשההפצה של אפליקציית הנתונים נמצאת לא חוקית.
איור 5. הבדיקה הושלמה.
- מפעילים מחדש את המחשב ומריצים את הפקודה tzdatacheck. בהפעלה הבאה של המכשיר, הקובץ הבינארי tzdatacheck יבצע כל פעולה שהועברה ל-staging. קובץ ה-binary tzdatacheck יכול לבצע את המשימות הבאות:
- כדי לבצע את הפעולה המתוזמנת, צריך לטפל ביצירה, בהחלפה ו/או במחיקה של קובצי
/data/misc/zoneinfo/currentלפני שרכיבי מערכת אחרים יפתחו את הקבצים ויתחילו להשתמש בהם. - בודקים שהקבצים ב-
/dataמתאימים לגרסה הנוכחית של הפלטפורמה. יכול להיות שהקבצים לא יהיו מתאימים אם המכשיר קיבל עדכון מערכת והגרסה של פורמט המהדורה השתנתה. - מוודאים שגרסת הכללים של IANA זהה לגרסה ב-
/systemאו חדשה ממנה. כך אפשר למנוע מצב שבו עדכון מערכת יותיר במכשיר נתונים ישנים יותר של כללי אזור הזמן מאשר אלה שקיימים בקובץ האימג'/system.
- כדי לבצע את הפעולה המתוזמנת, צריך לטפל ביצירה, בהחלפה ו/או במחיקה של קובצי
אמינות
תהליך ההתקנה מקצה לקצה הוא אסינכרוני ומפוצל בין שלושה תהליכים של מערכת הפעלה. בכל שלב במהלך ההתקנה המכשיר עלול להתרוקן, אין יותר מדי מקום בכונן או לגרום לבעיות אחרות, ובדיקת ההתקנה לא תושלם. במקרה שלא מוצלח, אפליקציית Updater מודיעה לשרת המערכת על כך שהעדכון נכשל. במקרה הגרוע ביותר, ה-RulesManagerService לא מקבל שיחה בכלל.
כדי לטפל בבעיה הזו, קוד שרת המערכת עוקב אחרי השלמת בדיקת עדכון מופעלת, וגם אחרי קוד הגרסה האחרונה שנבדקה של אפליקציית הנתונים. כשהמכשיר לא פעיל ומחובר לחשמל, קוד שרת המערכת יכול לבדוק את המצב הנוכחי. אם מתגלה בדיקת עדכון חלקית או גרסה לא צפויה של אפליקציית הנתונים, מתבצעת בדיקת עדכון באופן ספונטני.
אבטחה
כשהקוד של RulesManagerService מופעל בשרת המערכת, הוא מבצע כמה בדיקות כדי לוודא שהשימוש במערכת בטוח.
- בעיות שמציינות תמונת מערכת שהוגדרה בצורה לא תקינה מונעות את הפעלת המכשיר. לדוגמה, הגדרות לא נכונות של המעדכן או של אפליקציית הנתונים, או שאפליקציית ה-Updater או הנתונים לא נמצאת ב-
/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 שמתאימות להוספה לקובץ האימג' של המערכת (בגרסה הראשונית) ולחתימה והפצה דרך חנות אפליקציות (בגרסאות העדכונים הבאות). למידע נוסף על השימוש בטאפאס, ראו בניית אפליקציית הנתונים באמצעות טאפאס.
יצרני ציוד מקורי צריכים להתקין את אפליקציית הנתונים המובנית מראש בתמונת המערכת של מכשיר ב/system/priv-app. כדי לכלול קובצי APK שנוצרו מראש (שנוצרו על ידי תהליך ה-build של tapas) בתמונת המערכת, יצרני ציוד מקורי יכולים להעתיק את קובצי הדוגמה שב-packages/apps/TimeZoneData/oem_template/data_app_prebuilt. התבניות לדוגמה כוללות גם יעדי build להוספת גרסאות בדיקה של אפליקציית Data לחבילות בדיקה.
הכללת האפליקציות המעדכן ונתונים בתמונת המערכת
יצרני ציוד מקורי (OEM) צריכים להציב את חבילות ה-APK של Updater ושל אפליקציית הנתונים בספרייה /system/priv-app של קובץ האימג' של המערכת. לשם כך, ה-build של קובץ האימג' של המערכת צריך לכלול באופן מפורש את היעדים שנוצרו מראש של אפליקציית Updater ואפליקציית Data.
האפליקציה Updater צריכה להיות חתומה במפתח הפלטפורמה ולהיכלל כמו כל אפליקציית מערכת אחרת. היעד מוגדר ב-packages/apps/TimeZoneUpdater בתור TimeZoneUpdater. ההכללה של אפליקציית הנתונים ספציפית ליצרן הציוד המקורי (OEM) ותלויה בשם היעד שנבחר ל-prebuild.
הגדרת שרת המערכת
כדי להפעיל עדכונים של אזור זמן, יצרני ציוד מקורי יכולים להגדיר את שרת המערכת על ידי שינוי מאפייני ההגדרות שנקבעו ב-frameworks/base/core/res/res/values/config.xml.
| נכס | תיאור | נדרש שינוי מברירת המחדל? |
|---|---|---|
config_enableUpdateableTimeZoneRules |
צריך להגדיר אותו לערך true כדי להפעיל את RulesManagerService. |
כן |
config_timeZoneRulesUpdateTrackingEnabled |
הערך חייב להיות true כדי שהמערכת תאזין לשינויים באפליקציית הנתונים. |
כן |
config_timeZoneRulesDataPackage |
שם החבילה של אפליקציית הנתונים הספציפית ל-OEM. | כן |
config_timeZoneRulesUpdaterPackage |
מוגדרת לאפליקציית Updater שמוגדרת כברירת מחדל. יש לשנות רק כאשר מבצעים הטמעה אחרת של אפליקציית Updater. | לא |
config_timeZoneRulesCheckTimeMillisAllowed |
פרק הזמן שעובר בין הפעלת בדיקת עדכונים על ידי RuulesManagerService לבין התקנה, הסרה או תגובה לכל פעולה. אחרי הנקודה הזו, יכול להיות שייווצר טריגר אמינות ספונטני. | לא |
config_timeZoneRulesCheckRetryCount |
מספר הבדיקות הסדורות של העדכונים שנכשלו שמותר לבצע לפני ש-RulesManagerService מפסיק ליצור בדיקות נוספות. | לא |
שינויים בהגדרות צריכים להיות בתמונת המערכת (לא של הספק או של גורם אחר), כי מכשיר שהוגדר בצורה שגויה עלול לסרב להפעיל את האתחול. אם השינויים בהגדרות היו בתמונת הספק, עדכון לתמונת מערכת ללא אפליקציית נתונים (או עם שמות חבילות שונים של אפליקציית נתונים או של אפליקציית העדכון) ייחשב כהגדרה שגויה.
בדיקת 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 Core יוצר תיקונים לעדכון הגרסאות ב-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 באמצעות טאפאס, חותמים על ה-APK שנוצר ואז בודקים ומשחררים את ה-APK:
- במכשירים שלא שוחררו (או כשמכינים עדכון מערכת למכשיר שכבר שוחרר), שולחים את קובצי ה-APK החדשים לספרייה שנוצרה מראש של אפליקציית הנתונים כדי לוודא שבקובץ האימג' של המערכת ובבדיקות xTS יהיו קובצי ה-APK העדכניים ביותר. יצרני ציוד מקורי צריכים לבדוק שהקובץ החדש פועל בצורה תקינה (כלומר, עובר את CTS ואת כל הבדיקות האוטומטיות והידניות הספציפיות ליצרן).
- במכשירים שכבר פורסמו ולא מקבלים יותר עדכוני מערכת, יכול להיות שה-APK החתום יפורסם רק דרך חנות אפליקציות.
יצרני ציוד מקורי (OEM) אחראים לאבטחת איכות ולבדיקה של אפליקציית הנתונים המעודכנת במכשירים שלהם לפני ההשקה.
אסטרטגיה לקוד גרסת האפליקציה של הנתונים
לאפליקציית הנתונים צריכה להיות אסטרטגיית ניהול גרסאות מתאימה כדי לוודא שהמכשירים יקבלו את קובצי ה-APK הנכונים. לדוגמה, אם מתקבל עדכון מערכת שמכיל קובץ APK ישן יותר מהקובץ שהורדתם מחנות האפליקציות, צריך לשמור את הגרסה מחנות האפליקציות.
קוד גרסת ה-APK צריך לכלול את הפרטים הבאים:
- גרסת פורמט הפצה (ראשית + משנית)
- מספר גרסה שמתווסף אליו מספר (אטום)
נכון לעכשיו, רמת ה-API של הפלטפורמה קשורה מאוד לגרסה של פורמט המהדורה, כי בדרך כלל כל רמת API משויכת לגרסה חדשה של ICU (שגורמת לקבצים של המהדורה לא להיות תואמים). בעתיד, יכול להיות שמערכת Android תשנה את זה כדי שקובץ הפצה יוכל לפעול במספר מהדורות של פלטפורמת Android (ורמת ה-API לא תהיה בשימוש בסכמת הקוד של גרסת אפליקציית הנתונים).
דוגמה לאסטרטגיית קוד גרסה
הסכימה לדוגמה של מספרי גרסאות מבטיחה שגירסאות של פורמט הפצה גבוה יותר יחליפו גרסאות של פורמט הפצה נמוך יותר.
AndroidManifest.xml משתמש ב-android:minSdkVersion כדי לוודא שמכשירים ישנים לא יקבלו גרסאות עם פורמט הפצה בגרסה גבוהה יותר ממה שהם יכולים לטפל בו.
איור 6. דוגמה לאסטרטגיית קוד גרסה.
| דוגמה | ערך | המטרה |
|---|---|---|
| Y | שמורה | מאפשרת להשתמש בעתיד בסכמות חלופיות או בחבילות APK לבדיקה. היא בהתחלה (מרומזת) 0. מכיוון שהסוג הבסיסי הוא סוג int חתום של 32 ביט, התוכנית הזו תומכת עד לשתי גרסאות עתידיות של סכמת המספור. |
| 01 | הגרסה הראשית של הפורמט | עוקב אחר גרסה של פורמט ראשי בן 3 ספרות אחרי הנקודה העשרונית. פורמט המהדורה תומך ב-3 ספרות עשרוניות, אבל כאן נעשה שימוש רק ב-2 ספרות. לא סביר שהוא יגיע ל-100 בהינתן התוספת הגדולה הצפויה לכל רמת API. הגרסה הראשית 1 תואמת לרמת API 27. |
| 1 | הגרסה המשנית של הפורמט | מעקב אחרי מספר הגרסה המשנית בפורמט של 3 ספרות עשרוניות. הפורמט של הפצת ה-Linux תומך ב-3 ספרות עשרוניות, אבל כאן נעשה שימוש רק בספרה אחת. סביר להניח שהיא לא תגיע ל-10. |
| X | שמורה | הוא 0 לגרסאות ייצור (ועשוי להיות שונה ב-APKs לבדיקה). |
| ZZZZZ | מספר גרסה אטום | מספר עשרוני מוקצה לפי דרישה. כולל פערים שמאפשרים לבצע עדכונים של מודעות מעברון במקרה הצורך. |
אפשר לדחוס את התוכנית טוב יותר אם משתמשים בספרות בינאריות במקום עשרוניות, אבל לתוכנית הזו יש יתרון: היא קריאה לבני אדם. אם מיצית את טווח המספרים המלא, השם של חבילת אפליקציית הנתונים עשוי להשתנות.
שם הגרסה הוא ייצוג של הפרטים שקריא לבני אדם, לדוגמה: major=001,minor=001,iana=2017a, revision=1,respin=2.
דוגמאות מופיעות בטבלה הבאה.
| # | קוד גירסה | minSdkVersion | {Major format version},{Minor format version},{IANA rules version},{Revision} |
|---|---|---|---|
| 1 | 11000010 | O-MR1 | major=001,minor=001,iana=2017a,revision=1 |
| 2 | 21000010 | P | major=002,minor=001,iana=2017a,revision=1 |
| 3 | 11000020 | O-MR1 | upper=001,minor=001,iana=2017a,revision=2 |
| 4 | 11000030 | O-MR1 | upper=001,minor=001,iana=2017b,revision=1 |
| 5 | 21000020 | P | major=002,minor=001,iana=2017b,revision=1 |
| 6 | 11000040 | O-MR1 | major=001,minor=001,iana=2018a,revision=1 |
| 7 | 21000030 | P | major=002,minor=001,iana=2018a,revision=1 |
| 8 | 1123456789 | - | - |
| 9 | 11000021 | O-MR1 | upper=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 או את הגרסאות הקודמות של 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 שהם ספציפיים ל-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" />
הפעלת ה-build של tapas
אחרי שמסיימים ליצור את עץ המקור, מפעילים את ה-build של מקישים באמצעות הפקודות הבאות:
source build/envsetup.shtapasmake -j30 showcommands dist TARGET_BUILD_APPS='TimeZoneData TimeZoneData_test1 TimeZoneData_test2' TARGET_BUILD_VARIANT=userdebug
גרסת build תקינה יוצרת קבצים בספרייה out/dist לצורך בדיקה. אפשר להוסיף את הקבצים האלה לספריית prebuilts כדי לכלול אותם בתמונת המערכת, ו/או להפיץ אותם דרך חנות אפליקציות למכשירים תואמים.