Android डिवाइस, नेटवर्क सोर्स से सही Unix epoch टाइम अपने-आप पाने की कोशिश करते हैं. Android, समय की जानकारी पाने के लिए, सिंपल नेटवर्क टाइम प्रोटोकॉल (एसएनटीपी) का इस्तेमाल करता है. यह यूज़र डेटाग्राम प्रोटोकॉल (यूडीपी) का इस्तेमाल करता है.
इस पेज पर बताए गए कॉम्पोनेंट, समय का पता अपने-आप लगाने वाले सिस्टम का हिस्सा हैं. इसे नेटवर्क टाइम ओरिजिन कहा जाता है. नेटवर्क टाइम सर्वर से मिलने वाले टाइम सिग्नल का इस्तेमाल, Android डिवाइस के सिस्टम क्लॉक को सेट करने के लिए किया जा सकता है. ऐसा तब किया जा सकता है, जब डिवाइस पर समय का अपने-आप पता चलने की सुविधा काम करती हो और time_detector
सेवा को इसका इस्तेमाल करने के लिए कॉन्फ़िगर किया गया हो.
Android, नेटवर्क टाइम ओरिजिन का इस्तेमाल डिफ़ॉल्ट रूप से, समय का अपने-आप पता लगाने वाले मुख्य ओरिजिन के तौर पर करता है.
नेटवर्क टाइम डिटेक्शन सिस्टम
Android सिस्टम सर्वर में चलने वाली network_time_update_service
सेवा, नेटवर्क टाइम डिटेक्शन सिस्टम को लागू करती है. यह सेवा समय-समय पर SNTP का इस्तेमाल करके, किसी सर्वर से टाइम सिग्नल हासिल करती है. यह सेवा नेटवर्क कनेक्टिविटी पर भी नज़र रखती है. साथ ही, कनेक्टिविटी कमज़ोर होने के लंबे समय बाद, जब हाल ही का कोई टाइम सिग्नल उपलब्ध नहीं होता है, तो यह समय को रीफ़्रेश करती है.
network_time_update_service
सेवा, बूट होने के बाद और नेटवर्क कनेक्टिविटी पहली बार चालू होने पर, समय का सिग्नल पाने की कोशिश करती है. इसके बाद, सेवा अपने पास मौजूद सबसे नए सिग्नल को अपडेट रखने की कोशिश करती है. यह दुनिया भर के कई Android डिवाइसों के समय को रीफ़्रेश करने से जनरेट होने वाले लोड के साथ-साथ, अलग-अलग Android डिवाइसों की ज़रूरतों को भी पूरा करता है.
network_time_update_service
सेवा, इंटरनल एपीआई का इस्तेमाल करके time_detector
सेवा को नेटवर्क टाइम के सुझाव भेजती है. इसके बाद, Android प्लैटफ़ॉर्म के अन्य कॉम्पोनेंट, नेटवर्क टाइम के इन सुझावों का इस्तेमाल करते हैं.
नेटवर्क टाइम सोर्स से सुझाव मिलने के बाद, time_detector
सेवा यह तय करती है कि कॉन्फ़िगर किए गए प्राथमिकता के नियमों के हिसाब से सिस्टम क्लॉक को अपडेट करना है या नहीं.
सिस्टम क्लॉक को अपने-आप सेट करने के लिए, नेटवर्क ओरिजिन के सुझावों का इस्तेमाल करने के लिए, अपने-आप समय का पता लगाने वाले सिस्टम को कॉन्फ़िगर करने के लिए, core/res/res/values/config.xml
सिस्टम सर्वर कॉन्फ़िगरेशन फ़ाइल का इस्तेमाल करें. पक्का करें कि वैल्यू network
, config_autoTimeSourcesPriority
में सही जगह पर मौजूद हो. ज़्यादा जानकारी के लिए, समय के सोर्स की प्राथमिकता लेख पढ़ें.
डिवाइस कॉन्फ़िगरेशन
इस सेक्शन में बताया गया है कि डिवाइस बनाने वाली कंपनियां, नेटवर्क टाइम डिटेक्शन सिस्टम को कैसे कॉन्फ़िगर कर सकती हैं.
AOSP का बेस कॉन्फ़िगरेशन, config.xml
फ़ाइल में होता है:
frameworks/base/core/res/res/values/config.xml
:
कॉन्फ़िगरेशन कुंजी | AOSP वैल्यू | ब्यौरा |
---|---|---|
config_ntpRetry |
3 |
यह संख्या बताती है कि सिस्टम, नेटवर्क टाइम को रीफ़्रेश करने में विफल होने के बाद, कितनी बार छोटे एनटीपी पोलिंग इंटरवल (config_ntpPollingIntervalShorter ) के साथ नेटवर्क टाइम पोलिंग की कोशिश करता है. इसके बाद, सिस्टम सामान्य पोलिंग इंटरवल (config_ntpPollingInterval ) का इस्तेमाल करता है. 0 से कम वैल्यू का मतलब है कि सिस्टम, छोटे एनटीपी पोलिंग इंटरवल पर तब तक पोलिंग की कोशिश करता है, जब तक वह रीफ़्रेश नहीं हो जाता. |
config_ntpPollingInterval |
64800000 (18 घंटे) |
नेटवर्क के सामान्य समय के पोलिंग इंटरवल की जानकारी, मिलीसेकंड में. |
config_ntpPollingIntervalShorter |
60000 (1 मिनट) |
नेटवर्क से फिर से कनेक्ट करने की कोशिश करने के लिए, मिलीसेकंड में पोलिंग इंटरवल. इस कुकी का इस्तेमाल तब किया जाता है, जब समय रीफ़्रेश नहीं हो पाता. |
config_ntpServers |
एक एंट्री: ntp://time.android.com |
सटीक समय पाने के लिए, इस्तेमाल किए जाने वाले एनटीपी सर्वर. आइटम इस फ़ॉर्म में होने चाहिए:
ntp://<host>[:port] .
यह रजिस्टर की गई IANA यूआरआई स्कीम नहीं है. |
config_ntpTimeout |
5000 | टाइम आउट होने से पहले, एनटीपी सर्वर से जवाब पाने के लिए इंतज़ार करने का समय (मिलीसेकंड में). |
सर्वर
डिफ़ॉल्ट रूप से, AOSP time.android.com
पर मौजूद टाइम सर्वर का इस्तेमाल करता है. यह Google Public NTP का एलियास है. इस सेवा के लिए कोई एसएलए नहीं है. ज़्यादा जानकारी के लिए, Google Public NTP के बारे में अक्सर पूछे जाने वाले सवाल देखें.
एक से ज़्यादा सर्वर इस्तेमाल करने की सुविधा
Android 14 और इसके बाद के वर्शन के लिए, फ़्रेमवर्क कई एनटीपी सर्वर के साथ काम करता है. यह उन स्थितियों में काम करता है जहां डिवाइसों को एक ही कॉन्फ़िगरेशन के साथ दुनिया भर में डिस्ट्रिब्यूट किया जाता है. हालांकि, कुछ जगहों पर time.android.com
जैसे सर्वर को ऐक्सेस करने पर पाबंदी होती है.
एल्गोरिदम, config_ntpServers
कॉन्फ़िगरेशन कुंजी में बताए गए हर सर्वर से कनेक्ट करने की कोशिश करता है. जब एल्गोरिदम को ऐसा सर्वर मिल जाता है जो जवाब देता है, तो सिस्टम उस सर्वर का इस्तेमाल तब तक करता रहता है, जब तक वह रीफ़्रेश नहीं हो जाता या डिवाइस रीबूट नहीं हो जाता.
सटीक जवाब
Android में, नेटवर्क टाइम सिंक करने के लिए डिफ़ॉल्ट रूप से 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