זיהוי זמן רשת

מכשירי Android מנסים באופן אוטומטי לקבל את זמן האפס של Unix הנכון ממקור ברשת. כדי לקבל את פרטי השעה, מערכת Android משתמשת בפרוטוקול SNTP, שמשתמש בפרוטוקול UDP.

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

כברירת מחדל, Android משתמש במקור של שעון הרשת כמקור הראשי לזיהוי אוטומטי של השעה.

מערכת לזיהוי זמן הרשת

שירות network_time_update_service שפועל בשרת המערכת של Android מטמיע את מערכת זיהוי השעון ברשת. מדי פעם השירות משתמש ב-SNTP כדי לקבל אות זמן משרת. השירות גם עוקב אחרי קישוריות הרשת ומפעיל רענון של השעה כשאין אות זמן עדכני זמין אחרי תקופות ממושכות של קישוריות חלשה.

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

באמצעות ממשקי API פנימיים, network_time_update_service שולח הצעות לשעון הרשת לשירות time_detector. לאחר מכן, רכיבים אחרים בפלטפורמת Android משתמשים בהצעות האלה לשעון הרשת.

אחרי קבלת הצעות ממקור הזמן ברשת, השירות time_detector קובע אם לעדכן את שעון המערכת בהתאם לכללי התעדוף שהוגדרו.

כדי להגדיר את מערכת זיהוי השעה האוטומטית כך שתשתמש בהצעות של מקור הרשת כדי להגדיר את שעון המערכת באופן אוטומטי, משתמשים בקובץ התצורה של שרת המערכת core/res/res/values/config.xml. מוודאים שהערך network נכלל ב-config_autoTimeSourcesPriority במיקום הרצוי. פרטים נוספים זמינים במאמר עדיפות של מקור זמן.

תצורת מכשיר

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

הגדרות ה-AOSP הבסיסיות הן frameworks/base/core/res/res/values/config.xml:

מפתח הגדרה ערך AOSP תיאור
config_ntpRetry 3 אחרי ניסיון כושל לרענון, זהו מספר הפעמים שהמערכת מנסה לבצע סקירה של שעון הרשת עם פרק זמן קצר יותר לסקירה של NTP‏ (config_ntpPollingIntervalShorter), לפני שהיא חוזרת למצב רגילה ומשתמשת בפרק הזמן הרגיל לסקירה (config_ntpPollingInterval). אם הערך קטן מ-0, המשמעות היא שהמערכת מנסה שוב לבצע סקירה בפרק הזמן הקצר יותר לסקירה של NTP עד שהיא מצליחה לרענן.
config_ntpPollingInterval 64800000 (18 שעות) מרווח הזמן הרגיל של הסקרים של זמן הרשת באלפיות השנייה.
config_ntpPollingIntervalShorter 60000 (דקה אחת) מרווח הזמן באלפיות השנייה בין הניסיונות החוזרים לבדיקה של זמן הרשת. משמש כשרענון הזמן נכשל.
config_ntpServers רשומה אחת: ntp://time.android.com שרתי NTP שיש להשתמש בהם כדי לקבל זמן מדויק. הפריטים צריכים להיות בפורמט: ntp://<host>[:port].
זו לא סכימת URI רשומה של IANA.
config_ntpTimeout 5000 משך הזמן להמתנה לתגובה של שרת NTP באלפיות שנייה לפני תפוגת הזמן.

שרתים

כברירת מחדל, AOSP משתמש בשרתי זמן בכתובת time.android.com, שהיא כינוי ל-Google Public NTP. לשירות הזה אין הסכם רמת שירות. לפרטים נוספים, ראו שאלות נפוצות על NTP הציבורי של Google.

תמיכה במספר שרתים

ב-Android מגרסה 14 ואילך, ה-framework תומך במספר שרתי NTP. כך אפשר לתמוך במצבים שבהם המכשירים מופצים ברחבי העולם עם הגדרה אחת, אבל הגישה לשרתים כמו time.android.com מוגבלת במקומות מסוימים.

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

 דיוק

כברירת מחדל, סנכרון זמן הרשת ב-Android משתמש ב-SNTP כפעם אחת ביום עם שאילתה חד-פעמית, כדי לוודא שתמיד יש לה אות של זמן אחרון.

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

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

הדיוק הכולל של שעון המערכת מושפע גם מהיכולת של מכשיר Android לעקוב אחרי הזמן שחלף בצורה מדויקת אחרי קבלת אות זמן. זו בעיה שקשורה לכל ניהול הזמנים ב-Android, ולא רק לזיהוי זמן הרשת, ולכן השירות time_detector מתעלם מהצעות ישנות. השירות network_time_update_service מתעדכן באופן קבוע במרווח הזמן config_ntpPollingInterval כדי לספק לשירות time_detector הצעות עדכניות לזמנים, וכדי לוודא שהשירות time_detector לא יעבור למקורות זמן בעדיפות נמוכה יותר, שגם לרוב פחות מדויקים או לפעמים שגויים, כמו telephony.

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

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

שימושים אחרים בזמן הרשת

אם לא הגדרתם זיהוי זמן אוטומטי באמצעות המקור network או שהמשתמש השבית את הזיהוי האוטומטי של הזמן, הרכיבים הבאים עדיין משתמשים בזמן שהתקבל מהשירות network_time_update_service:

  • השיטה SystemClock.currentNetworkTimeClock().
  • פונקציות פנימיות בפלטפורמה. לדוגמה, A-GPS יכול לאתר תיקון ראשוני של GNSS (מיקום) מהר יותר כשיש לו מידע על זמן הרשת.

ניפוי באגים ובדיקה

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

אינטראקציה עם השירות network_time_update_service

כדי לדגום את המצב הנוכחי של network_time_update_service, משתמשים בפקודה:

adb shell cmd network_time_update_service dump

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

adb shell cmd network_time_update_service help