Android 10, APK पर आधारित टाइम ज़ोन का डेटा अपडेट करने का तरीका (Android 8.1 और Android 9 में उपलब्ध) बंद कर देता है. साथ ही, इसे APEX पर आधारित मॉड्यूल अपडेट करने के तरीके से बदल दिया जाता है. AOSP 8.1 से 13 में अब भी वह प्लैटफ़ॉर्म कोड शामिल है जो OEMs के लिए, 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 और उसके बाद के वर्शन से पूरी तरह हटा दिया गया है. साथ ही, इसे सोर्स कोड में भी नहीं देखा जा सकता. पार्टनर को टाइम ज़ोन के मुख्य मॉड्यूल पर पूरी तरह से माइग्रेट कर देना चाहिए.
Android 8.1 और Android 9 में, OEM, डिवाइसों पर टाइम ज़ोन के अपडेट किए गए नियमों का डेटा पुश करने के लिए, APK पर आधारित तरीके का इस्तेमाल कर सकते हैं. इसके लिए, उन्हें सिस्टम अपडेट करने की ज़रूरत नहीं पड़ती. इस तरीके से, लोगों को समय-समय पर अपडेट मिलते हैं. इससे, Android डिवाइस पर समय क्षेत्र के अपडेट की जांच की जा सकती है. साथ ही, Android पार्टनर, सिस्टम की इमेज अपडेट किए बिना समय क्षेत्र के अपडेट की जांच कर सकते हैं.
Android की कोर लाइब्रेरी टीम, स्टॉक Android डिवाइस पर टाइम ज़ोन के नियमों को अपडेट करने के लिए ज़रूरी डेटा फ़ाइलें उपलब्ध कराती है. OEM, अपने डिवाइसों के लिए टाइम ज़ोन के अपडेट बनाते समय, इन डेटा फ़ाइलों का इस्तेमाल कर सकते हैं. इसके अलावा, वे अपनी डेटा फ़ाइलें भी बना सकते हैं. सभी मामलों में, OEM के पास क्वालिटी की पुष्टि/जांच, समय, और टाइम ज़ोन के नियमों के अपडेट को लॉन्च करने का कंट्रोल होता है. यह कंट्रोल, उन डिवाइसों के लिए होता है जिन पर ये अपडेट काम करते हैं.
Android टाइम ज़ोन का सोर्स कोड और डेटा
सभी स्टॉक Android डिवाइसों के लिए, टाइम ज़ोन के नियमों का डेटा ज़रूरी है. भले ही, वे इस सुविधा का इस्तेमाल न करते हों. साथ ही, डिवाइसों को /system पार्टीशन में टाइम ज़ोन के नियमों के डेटा का डिफ़ॉल्ट सेट भेजना ज़रूरी है. इसके बाद, Android सोर्स ट्री में मौजूद इन लाइब्रेरी के कोड का इस्तेमाल करके, इस डेटा का इस्तेमाल किया जाता है:
libcore/से मैनेज किए जा रहे कोड (जैसे,java.util.TimeZone) मेंtzdataऔरtzlookup.xmlफ़ाइलों का इस्तेमाल होता है.bionic/में मौजूद नेटिव लाइब्रेरी कोड (उदाहरण के लिए,mktime, localtime सिस्टम कॉल के लिए)tzdataफ़ाइल का इस्तेमाल करता है.external/icu/में मौजूद ICU4J/ICU4C लाइब्रेरी कोड, icu.datफ़ाइल का इस्तेमाल करता है.
ये लाइब्रेरी, /data/misc/zoneinfo/current डायरेक्ट्री में मौजूद ओवरले फ़ाइलों को ट्रैक करती हैं. ओवरले फ़ाइलों में, बेहतर टाइम ज़ोन नियमों का डेटा शामिल होता है. इससे /system में बदलाव किए बिना, डिवाइसों को अपडेट किया जा सकता है.
Android सिस्टम के जिन कॉम्पोनेंट को टाइम ज़ोन के नियम का डेटा चाहिए वे सबसे पहले इन जगहों पर जाकर डेटा देखते हैं:
libcore/औरbionic/कोड,tzdataऔरtzlookup.xmlफ़ाइलों की/dataकॉपी का इस्तेमाल करते हैं.- ICU4J/ICU4C कोड,
/dataमें मौजूद फ़ाइलों का इस्तेमाल करता है. साथ ही,/systemफ़ाइलों का इस्तेमाल उस डेटा के लिए करता है जो मौजूद नहीं है. जैसे, फ़ॉर्मैट, स्थानीय भाषा में लिखी गई स्ट्रिंग वगैरह.
डिस्ट्रो फ़ाइलें
डिस्ट्रो .zip फ़ाइलों में, /data/misc/zoneinfo/current डायरेक्ट्री को पॉप्युलेट करने के लिए ज़रूरी डेटा फ़ाइलें होती हैं. डिस्ट्रो फ़ाइलों में ऐसा मेटाडेटा भी होता है जिसकी मदद से डिवाइस, वर्शन से जुड़ी समस्याओं का पता लगा सकते हैं.
डिस्ट्रो फ़ाइल फ़ॉर्मैट, Android रिलीज़ पर निर्भर करता है. ऐसा इसलिए है, क्योंकि ICU वर्शन, Android प्लैटफ़ॉर्म की ज़रूरी शर्तों, और रिलीज़ से जुड़े अन्य बदलावों के साथ कॉन्टेंट बदलते रहते हैं. Android, हर IANA अपडेट के लिए, काम करने वाले Android रिलीज़ के लिए डिस्ट्रो फ़ाइलें उपलब्ध कराता है. साथ ही, प्लैटफ़ॉर्म की सिस्टम फ़ाइलों को भी अपडेट करता है. अपने डिवाइसों को अप-टू-डेट रखने के लिए, OEM इन डिस्ट्रो फ़ाइलों का इस्तेमाल कर सकते हैं या Android सोर्स ट्री का इस्तेमाल करके अपनी फ़ाइलें बना सकते हैं. सोर्स ट्री में, डिस्ट्रो फ़ाइलें जनरेट करने के लिए ज़रूरी स्क्रिप्ट और अन्य फ़ाइलें होती हैं.
टाइम ज़ोन अपडेट करने वाले कॉम्पोनेंट
टाइम ज़ोन के नियमों में बदलाव करने के लिए, डिस्ट्रिब्यूशन फ़ाइलों को डिवाइस पर भेजा जाता है. साथ ही, उनमें मौजूद फ़ाइलों को सुरक्षित तरीके से इंस्टॉल किया जाता है. ट्रांसफ़र और इंस्टॉलेशन के लिए, ये ज़रूरी हैं:
- प्लैटफ़ॉर्म सेवा की सुविधा (
timezone.RulesManagerService), जो डिफ़ॉल्ट रूप से बंद रहती है. OEM को कॉन्फ़िगरेशन की मदद से, इस सुविधा को चालू करना होगा.RulesManagerService, सिस्टम सर्वर प्रोसेस में चलता है और/data/misc/zoneinfo/stagedमें लिखकर, टाइम ज़ोन अपडेट करने की कार्रवाइयों को शुरू करता है.RulesManagerServiceपहले से तय किए गए ऑपरेशन को भी बदल सकता है या मिटा सकता है. -
TimeZoneUpdater, यह एक ऐसा सिस्टम ऐप्लिकेशन है जिसे अपडेट नहीं किया जा सकता (यानी कि Updater ऐप्लिकेशन). OEM को इस सुविधा का इस्तेमाल करने वाले डिवाइसों की सिस्टम इमेज में, इस ऐप्लिकेशन को शामिल करना चाहिए. - OEM
TimeZoneData, अपडेट किए जा सकने वाला एक सिस्टम ऐप्लिकेशन (यानी डेटा ऐप्लिकेशन) है, जो डिस्ट्रो फ़ाइलों को डिवाइस में ले जाता है और उन्हें अपडेटर ऐप्लिकेशन पर उपलब्ध कराता है. ओईएम को इस सुविधा का इस्तेमाल करने वाले डिवाइसों के सिस्टम इमेज में इस ऐप्लिकेशन को शामिल करना चाहिए. -
tzdatacheck, टाइम ज़ोन के अपडेट को सही और सुरक्षित तरीके से लागू करने के लिए, बूट-टाइम बाइनरी की ज़रूरत होती है.
Android सोर्स ट्री में ऊपर बताए गए कॉम्पोनेंट के लिए सामान्य सोर्स कोड होता है. OEM, बिना किसी बदलाव के इसका इस्तेमाल कर सकता है. टेस्ट कोड दिया जाता है, ताकि OEM यह अपने-आप देख सकें कि उन्होंने सुविधा को सही तरीके से चालू किया है.
डिस्ट्रिब्यूशन इंस्टॉल करना
डिस्ट्रो इंस्टॉल करने की प्रोसेस में ये चरण शामिल हैं:
- ऐप्लिकेशन स्टोर से डाउनलोड करने या साइडलोड करने के ज़रिए, डेटा ऐप्लिकेशन अपडेट हो जाता है. सिस्टम सर्वर प्रोसेस (
timezone.RulesManagerServer/timezone.PackageTrackerक्लास के ज़रिए), कॉन्फ़िगर किए गए, OEM के हिसाब से, डेटा ऐप्लिकेशन पैकेज के नाम में होने वाले बदलावों को देखती है.
पहली इमेज. डेटा ऐप्लिकेशन के अपडेट.
- किसी टारगेट किए गए इंटेंट को Updater ऐप्लिकेशन पर ब्रॉडकास्ट करके, सिस्टम सर्वर प्रोसेस अपडेट की जांच शुरू करती है. सिस्टम सर्वर, जनरेट किए गए सबसे हाल के टोकन पर नज़र रखता है. इससे यह पता चलता है कि ट्रिगर की गई सबसे हाल की जांच कब पूरी हुई; किसी भी अन्य टोकन को अनदेखा कर दिया जाता है.
दूसरी इमेज. अपडेट की जांच करने की सुविधा को ट्रिगर करें.
- अपडेट की जांच के दौरान, Updater ऐप्लिकेशन ये काम करता है:
- RulesManagerService को कॉल करके, डिवाइस की मौजूदा स्थिति के बारे में क्वेरी करता है.
तीसरी इमेज. डेटा ऐप्लिकेशन के अपडेट, RulesManagerService को कॉल कर रहे हैं.
- डिस्ट्रिब्यूशन के बारे में जानकारी पाने के लिए, Data ऐप्लिकेशन को क्वेरी भेजता है. इसके लिए, यह अच्छी तरह से तय किए गए ContentProvider यूआरएल और कॉलम के स्पेसिफ़िकेशन पर क्वेरी करता है.
चौथी इमेज. डेटा ऐप्लिकेशन के अपडेट, डिस्ट्रिब्यूशन के बारे में जानकारी पाएं.
- RulesManagerService को कॉल करके, डिवाइस की मौजूदा स्थिति के बारे में क्वेरी करता है.
- अपने पास मौजूद जानकारी के आधार पर, Updater ऐप्लिकेशन सही कार्रवाई करता है. उपलब्ध कार्रवाइयों में ये शामिल हैं:
- इंस्टॉल करने का अनुरोध करें. डिस्ट्रो डेटा को डेटा ऐप्लिकेशन से पढ़ा जाता है और सिस्टम सर्वर केRuleManagerService को पास किया जाता है. RulesManagerService, डिस्ट्रिब्यूशन फ़ॉर्मैट के वर्शन और कॉन्टेंट की फिर से पुष्टि करता है कि यह डिवाइस के लिए सही है या नहीं. इसके बाद, वह इंस्टॉल की प्रोसेस शुरू करता है.
- अनइंस्टॉल करने का अनुरोध करें (ऐसा बहुत कम होता है). उदाहरण के लिए, अगर
/dataमें अपडेट किया गया APK बंद या अनइंस्टॉल किया जा रहा है और डिवाइस/systemमें मौजूद वर्शन पर वापस लौट रहा है. - कुछ न करें. यह तब होता है, जब डेटा ऐप्लिकेशन डिस्ट्रिब्यूशन अमान्य हो.
पांचवीं इमेज. जांच पूरी हो गई.
- डिवाइस को रीबूट करें और tzdatacheck चलाएं. डिवाइस को अगली बार बूट करने पर,
tzdatacheck बाइनरी, किसी भी स्टेज वाले ऑपरेशन को पूरा करता है. tzdatacheck बाइनरी, ये काम कर सकती है:
- सिस्टम के अन्य कॉम्पोनेंट के ज़रिए फ़ाइलों को खोलने और उनका इस्तेमाल करना शुरू करने से पहले,
/data/misc/zoneinfo/currentफ़ाइलों को बनाने, बदलने, और/या उन्हें मिटाने की प्रोसेस पूरी करके, पहले से तय की गई कार्रवाई करें. - देखें कि
/dataमें मौजूद फ़ाइलें मौजूदा प्लैटफ़ॉर्म वर्शन के हिसाब से सही हैं या नहीं. अगर डिवाइस को अभी-अभी सिस्टम अपडेट मिला है और डिस्ट्रो फ़ॉर्मैट का वर्शन बदला गया है, तो ऐसा हो सकता है. - पक्का करें कि IANA के नियमों का वर्शन,
/systemमें मौजूद वर्शन के बराबर या उससे नया हो. इससे, सिस्टम अपडेट होने पर, डिवाइस पर/systemइमेज में मौजूद समय क्षेत्र के नियमों के पुराने डेटा के बजाय, नए डेटा के सेव होने से बचा जा सकता है.
- सिस्टम के अन्य कॉम्पोनेंट के ज़रिए फ़ाइलों को खोलने और उनका इस्तेमाल करना शुरू करने से पहले,
विश्वसनीयता
इंस्टॉलेशन की पूरी प्रोसेस एसिंक्रोनस होती है और इसे ओएस की तीन प्रोसेस में बांटा जाता है. इंस्टॉल करने के दौरान किसी भी समय, डिवाइस की बैटरी खत्म हो सकती है, डिस्क में जगह खत्म हो सकती है या अन्य समस्याएं हो सकती हैं. इन समस्याओं की वजह से इंस्टॉल करने की जांच पूरी नहीं हो पा रही है. अगर अपडेट नहीं हो पाता है, तो Updater ऐप्लिकेशन, सिस्टम सर्वर को इसकी जानकारी देता है. अगर अपडेट नहीं हो पाता है, तो RulesManagerService को कोई कॉल नहीं मिलता.
इसे मैनेज करने के लिए, सिस्टम सर्वर कोड यह ट्रैक करता है कि ट्रिगर किया गया अपडेट की जांच पूरा हो गया है या नहीं. साथ ही, यह भी ट्रैक करता है कि Data ऐप्लिकेशन का पिछला जांचा गया वर्शन कोड क्या है. जब डिवाइस इस्तेमाल में नहीं है और चार्ज हो रहा है, तब सिस्टम सर्वर कोड मौजूदा स्थिति की जांच कर सकता है. अगर यह पता चलता है कि अपडेट की जांच अधूरी है या Data ऐप्लिकेशन का वर्शन अनचाहा है, तो यह अपने-आप अपडेट की जांच शुरू कर देता है.
सुरक्षा
इस सेटिंग के चालू होने पर, सिस्टम के सर्वर में मौजूदRuleManagerService कोड कई बार जांच करता है, ताकि यह पक्का किया जा सके कि सिस्टम इस्तेमाल करने के लिए सुरक्षित है.
- गलत तरीके से कॉन्फ़िगर की गई सिस्टम इमेज से जुड़ी समस्याओं की वजह से, डिवाइस को बूट करने में समस्या आती है. उदाहरण के लिए, अपडेटर या डेटा ऐप्लिकेशन का गलत कॉन्फ़िगरेशन या अपडेटर या डेटा ऐप्लिकेशन का
/system/priv-appमें न होना. - गलत डेटा ऐप्लिकेशन इंस्टॉल होने की समस्याओं की वजह से, डिवाइस को बूट होने से नहीं रोका जाता. हालांकि, अपडेट की जांच ट्रिगर होने से रोका जाता है. उदाहरण के लिए, ज़रूरी सिस्टम अनुमतियों की कमी या डेटा ऐप्लिकेशन, उम्मीद के मुताबिक यूआरआई पर ContentProvider को एक्सपोज़ नहीं करता.
/data/misc/zoneinfo डायरेक्ट्री के लिए, फ़ाइल की अनुमतियां
SELinux नियमों का इस्तेमाल करके लागू की जाती हैं. किसी भी APK की तरह, डेटा ऐप्लिकेशन पर भी उसी कुंजी से हस्ताक्षर किया जाना चाहिए जिसका इस्तेमाल /system/priv-app वर्शन पर हस्ताक्षर करने के लिए किया गया था. डेटा ऐप्लिकेशन में, OEM के हिसाब से पैकेज का नाम और कुंजी होनी चाहिए.
टाइम ज़ोन के अपडेट इंटिग्रेट करना
टाइम ज़ोन अपडेट करने की सुविधा चालू करने के लिए, ओईएम आम तौर पर:
- अपना डेटा ऐप्लिकेशन बना सकते हैं.
- सिस्टम इमेज बिल्ड में, Updater और Data ऐप्लिकेशन शामिल करें.
- RulesManagerService को चालू करने के लिए, सिस्टम सर्वर को कॉन्फ़िगर करें.
वीडियो की रणनीति
शुरू करने से पहले, OEM को इन नीतियों, क्वालिटी अश्योरेंस, और सुरक्षा से जुड़ी बातों की समीक्षा करनी चाहिए:
- अपने डेटा ऐप्लिकेशन के लिए, खास तौर पर ऐप्लिकेशन साइनिंग पासकोड बनाएं.
- टाइम ज़ोन के अपडेट के लिए रिलीज़ और वर्शन बनाने की रणनीति बनाएं, ताकि यह समझा जा सके कि किन डिवाइसों को अपडेट किया जाएगा. साथ ही, यह भी पक्का किया जा सके कि अपडेट सिर्फ़ उन डिवाइसों पर इंस्टॉल किए जाएं जिनमें उनकी ज़रूरत है. उदाहरण के लिए, हो सकता है कि ओईएम अपने सभी डिवाइसों के लिए एक ही डेटा ऐप्लिकेशन का इस्तेमाल करना चाहें या अलग-अलग डिवाइसों के लिए अलग-अलग डेटा ऐप्लिकेशन का इस्तेमाल करना चाहें. इस फ़ैसले से, पैकेज के नाम, इस्तेमाल किए गए वर्शन कोड, और क्वालिटी जांच की रणनीति पर असर पड़ता है.
- यह समझें कि उन्हें AOSP से स्टॉक Android टाइमज़ोन डेटा का इस्तेमाल करना है या अपना डेटा बनाना है.
डेटा ऐप्लिकेशन बनाना
AOSP में, packages/apps/TimeZoneData में डेटा ऐप्लिकेशन बनाने के लिए ज़रूरी सभी सोर्स कोड और बिल्ड नियम शामिल होते हैं. साथ ही, AndroidManifest.xml और packages/apps/TimeZoneData/oem_template में मौजूद अन्य फ़ाइलों के लिए निर्देश और टेंप्लेट के उदाहरण भी शामिल होते हैं. उदाहरण के तौर पर दिए गए टेंप्लेट में, असल डेटा ऐप्लिकेशन APK के लिए बने बिल्ड टारगेट के साथ-साथ, डेटा ऐप्लिकेशन के टेस्ट वर्शन बनाने के लिए अतिरिक्त टारगेट भी शामिल होते हैं.
OEM, Data ऐप्लिकेशन को अपने आइकॉन, नाम, अनुवाद, और अन्य जानकारी के साथ पसंद के मुताबिक बना सकते हैं. हालांकि, डेटा ऐप्लिकेशन को लॉन्च नहीं किया जा सकता. इसलिए, आइकॉन सिर्फ़ सेटिंग > ऐप्लिकेशन स्क्रीन पर दिखता है.
डेटा ऐप्लिकेशन को tapas बिल्ड के साथ बनाया जाना चाहिए. इससे, शुरुआती रिलीज़ के लिए सिस्टम इमेज में जोड़े जाने वाले APK बनते हैं. साथ ही, बाद के अपडेट के लिए, ऐप्लिकेशन स्टोर के ज़रिए हस्ताक्षर किए जाते हैं और डिस्ट्रिब्यूट किए जाते हैं. tapas का इस्तेमाल करने के बारे में ज़्यादा जानने के लिए, tapas का इस्तेमाल करके डेटा ऐप्लिकेशन बनाना लेख पढ़ें.
OEM को /system/priv-app में मौजूद डिवाइस की सिस्टम इमेज में पहले से बना डेटा ऐप्लिकेशन इंस्टॉल करना होगा. सिस्टम इमेज में पहले से बने APKs (tapas के ज़रिए जनरेट किए गए) शामिल करने के लिए, OEM packages/apps/TimeZoneData/oem_template/data_app_prebuilt में मौजूद उदाहरण फ़ाइलों को कॉपी कर सकते हैं. उदाहरण के तौर पर दिए गए टेंप्लेट में, टेस्ट सुइट में Data ऐप्लिकेशन के टेस्ट वर्शन शामिल करने के लिए, बिल्ड टारगेट भी शामिल हैं.
सिस्टम इमेज में अपडेटर और डेटा ऐप्लिकेशन शामिल करें
OEM को अपडेटर और डेटा ऐप्लिकेशन के APK, सिस्टम इमेज की /system/priv-app डायरेक्ट्री में डालने होंगे. ऐसा करने के लिए, सिस्टम इमेज के बिल्ड में, अपडेटर ऐप्लिकेशन और डेटा ऐप्लिकेशन के पहले से बने टारगेट शामिल होने चाहिए.
Updater ऐप्लिकेशन को प्लैटफ़ॉर्म कुंजी से साइन किया जाना चाहिए और उसे किसी भी
दूसरे सिस्टम ऐप्लिकेशन की तरह शामिल किया जाना चाहिए. टारगेट को
packages/apps/TimeZoneUpdater में TimeZoneUpdater के तौर पर तय किया गया है. डेटा ऐप्लिकेशन को शामिल करने की प्रोसेस, OEM के लिए तय होती है. यह पहले से बनाए गए बिल्ड के लिए चुने गए टारगेट के नाम पर निर्भर करती है.
सिस्टम सर्वर कॉन्फ़िगर करें
टाइम ज़ोन के अपडेट चालू करने के लिए, ओईएम frameworks/base/core/res/res/values/config.xml में बताई गई कॉन्फ़िगरेशन प्रॉपर्टी को ओवरराइड करके सिस्टम सर्वर को कॉन्फ़िगर कर सकते हैं.
| प्रॉपर्टी | ब्यौरा | क्या ओवरराइड करना ज़रूरी है? |
|---|---|---|
config_enableUpdateableTimeZoneRules |
नियम मैनेजर सेवा चालू करने के लिए, true पर सेट होना चाहिए. |
हां |
config_timeZoneRulesUpdateTrackingEnabled |
सिस्टम को Data ऐप्लिकेशन में होने वाले बदलावों को सुनने के लिए, इसे true पर सेट करना ज़रूरी है. |
हां |
config_timeZoneRulesDataPackage |
OEM के हिसाब से डेटा ऐप्लिकेशन का पैकेज नेम. | हां |
config_timeZoneRulesUpdaterPackage |
डिफ़ॉल्ट Updater ऐप्लिकेशन के लिए कॉन्फ़िगर किया गया. सिर्फ़ तब बदलें, जब कोई दूसरा Updater ऐप्लिकेशन लागू किया जा रहा हो. | नहीं |
config_timeZoneRulesCheckTimeMillisAllowed |
RulesManagerService की ओर से अपडेट की जांच ट्रिगर होने और इंस्टॉल, अनइंस्टॉल या कोई कार्रवाई न करने के बीच का समय. इस बिंदु के बाद, भरोसेमंदता का ट्रिगर अपने-आप जनरेट हो सकता है. | नहीं |
config_timeZoneRulesCheckRetryCount |
RulesManagerService के अपडेट की जांच के नतीजे असफल होने की संख्या, जिसके बाद वह और नतीजे जनरेट करना बंद कर देती है. | नहीं |
कॉन्फ़िगरेशन बदलने की सुविधा, सिस्टम इमेज में होनी चाहिए, न कि वेंडर या अन्य में, क्योंकि गलत तरीके से कॉन्फ़िगर किया गया डिवाइस, शायद बूट न हो. अगर वेंडर इमेज में कॉन्फ़िगरेशन ओवरराइड हैं, तो सिस्टम इमेज में डेटा ऐप्लिकेशन (या डेटा ऐप्लिकेशन/अपडेटर ऐप्लिकेशन पैकेज के अलग-अलग नामों के साथ) को अपडेट करना गलत कॉन्फ़िगरेशन माना जाएगा.
एक्सटीएस टेस्टिंग
xTS का मतलब, OEM के हिसाब से बनाए गए किसी भी टेस्ट सुइट से है. यह Tradefed का इस्तेमाल करने वाले स्टैंडर्ड Android टेस्ट सुइट (जैसे, CTS और VTS) से मिलता-जुलता है. जिन OEM के पास ऐसे टेस्ट सुइट हैं वे Android टाइम ज़ोन अपडेट टेस्ट जोड़ सकते हैं. ये टेस्ट यहां दिए गए हैं:
packages/apps/TimeZoneData/testing/xtsमें, ऑटोमेटेड फ़ंक्शनल टेस्टिंग के लिए ज़रूरी कोड शामिल होता है.packages/apps/TimeZoneData/oem_template/xtsमें, Tradefed जैसे xTS सुइट में टेस्ट शामिल करने के लिए, डायरेक्ट्री स्ट्रक्चर का सैंपल शामिल है. अन्य टेंप्लेट डायरेक्ट्री की तरह ही, OEM को इन टेंप्लेट को कॉपी करके अपनी ज़रूरतों के हिसाब से बनाना होगा.packages/apps/TimeZoneData/oem_template/data_app_prebuiltमें, टेस्ट के लिए ज़रूरी पहले से बने टेस्ट APK को शामिल करने के लिए, बिल्ड के समय का कॉन्फ़िगरेशन होता है.
टाइम ज़ोन के अपडेट बनाएं
जब IANA, टाइम ज़ोन के नियमों का नया सेट रिलीज़ करता है, तो Android की मुख्य लाइब्रेरी टीम, AOSP में रिलीज़ को अपडेट करने के लिए पैच जनरेट करती है. स्टॉक Android सिस्टम और डिस्ट्रो फ़ाइलों का इस्तेमाल करने वाले OEM, इन कमिट को चुन सकते हैं. साथ ही, इनका इस्तेमाल अपने डेटा ऐप्लिकेशन का नया वर्शन बनाने के लिए कर सकते हैं. इसके बाद, अपने डिवाइसों को प्रोडक्शन में अपडेट करने के लिए, नया वर्शन रिलीज़ कर सकते हैं.
देखें.डेटा ऐप्लिकेशन में, Android वर्शन से जुड़ी डिस्ट्रो फ़ाइलें होती हैं. इसलिए, OEM को डेटा ऐप्लिकेशन का नया वर्शन बनाना होगा. यह वर्शन, Android के उन सभी वर्शन के लिए होना चाहिए जिन्हें OEM अपडेट करना चाहता है. उदाहरण के लिए, अगर कोई OEM, Android 8.1, 9, और 10 वाले डिवाइसों के लिए अपडेट उपलब्ध कराना चाहता है, तो उसे यह प्रोसेस तीन बार पूरी करनी होगी.
पहला चरण: सिस्टम/टाइमज़ोन और बाहरी/icu डेटा फ़ाइलों को अपडेट करना
इस चरण में, OEM, AOSP में रिलीज़-dev ब्रैंच से system/timezone और external/icu के लिए स्टॉक Android कमिट लेते हैं. इसके बाद, वे उन कमिट को Android सोर्स कोड की अपनी कॉपी पर लागू करते हैं.
system/timezone AOSP पैच में, system/timezone/input_data और system/timezone/output_data में अपडेट की गई फ़ाइलें शामिल हैं. जिन OEM को कुछ और स्थानीय सुधार करने हैं वे इनपुट फ़ाइलों में बदलाव कर सकते हैं. इसके बाद, output_data में फ़ाइलें जनरेट करने के लिए, system/timezone/input_data और external/icu की फ़ाइलों का इस्तेमाल कर सकते हैं.
सबसे अहम फ़ाइल system/timezone/output_data/distro/distro.zip है. डेटा ऐप्लिकेशन का APK बनने पर, यह फ़ाइल अपने-आप शामिल हो जाती है.
दूसरा चरण: डेटा ऐप्लिकेशन का वर्शन कोड अपडेट करना
इस चरण में, OEM, डेटा ऐप्लिकेशन का वर्शन कोड अपडेट करते हैं. बिल्ड, distro.zip को अपने-आप चुनता है. हालांकि, डेटा ऐप्लिकेशन के नए वर्शन में नया वर्शन कोड होना चाहिए, ताकि उसे नए वर्शन के तौर पर पहचाना जा सके. साथ ही, इसका इस्तेमाल, पहले से लोड किए गए डेटा ऐप्लिकेशन या किसी डिवाइस पर पिछले अपडेट से इंस्टॉल किए गए डेटा ऐप्लिकेशन को बदलने के लिए किया जाता है.
package/apps/TimeZoneData/oem_template/data_app से कॉपी की गई फ़ाइलों का इस्तेमाल करके डेटा ऐप्लिकेशन बनाते समय, Android.mk में APK पर लागू किया गया वर्शन कोड/वर्शन का नाम देखा जा सकता है:
TIME_ZONE_DATA_APP_VERSION_CODE := TIME_ZONE_DATA_APP_VERSION_NAME :=
testing/Android.mk में मिलती-जुलती एंट्री मिल सकती हैं. हालांकि,
टेस्ट वर्शन कोड, सिस्टम इमेज वर्शन के बाद वाले होने चाहिए. ज़्यादा जानकारी के लिए, वर्शन कोड की रणनीति का उदाहरण वाला स्कीम देखें. अगर उदाहरण वाले स्कीम या मिलते-जुलते स्कीम का इस्तेमाल किया जाता है, तो टेस्ट वर्शन कोड को अपडेट करने की ज़रूरत नहीं है. इसकी वजह यह है कि यह पक्का है कि ये कोड, असल वर्शन कोड से ज़्यादा होंगे.
तीसरा चरण: फिर से बनाना, हस्ताक्षर करना, जांच करना, और रिलीज़ करना
इस चरण में, OEM, tapas का इस्तेमाल करके APK को फिर से बनाते हैं. इसके बाद, जनरेट किए गए APK पर हस्ताक्षर करते हैं और फिर APK की जांच करके उसे रिलीज़ करते हैं:
- रिलीज़ नहीं किए गए डिवाइसों के लिए (या रिलीज़ किए गए डिवाइस के लिए सिस्टम अपडेट तैयार करते समय), डेटा ऐप्लिकेशन की पहले से बनी डायरेक्ट्री में नए APK सबमिट करें. इससे यह पक्का किया जा सकेगा कि सिस्टम इमेज और xTS टेस्ट में नए APK मौजूद हों. OEM को यह जांच करनी चाहिए कि नई फ़ाइल सही तरीके से काम करती है या नहीं. इसका मतलब है कि यह सीटीएस और OEM के लिए ऑटोमेटेड और मैन्युअल तरीके से किए जाने वाले सभी टेस्ट पास करती है.
- जिन डिवाइसों को अब सिस्टम अपडेट नहीं मिलते उनके लिए, साइन किया गया APK सिर्फ़ ऐप्लिकेशन स्टोर से रिलीज़ किया जा सकता है.
रिलीज़ से पहले, OEM अपने डिवाइसों पर अपडेट किए गए Data ऐप्लिकेशन की क्वालिटी अश्योरेंस और जांच करने के लिए ज़िम्मेदार होते हैं.
डेटा ऐप्लिकेशन वर्शन कोड की रणनीति
डेटा ऐप्लिकेशन में, वर्शन बनाने के लिए सही रणनीति होनी चाहिए, ताकि डिवाइसों को सही APK मिल सकें. उदाहरण के लिए, अगर कोई ऐसा सिस्टम अपडेट मिलता है जिसमें ऐप स्टोर से डाउनलोड किए गए एक से ज़्यादा पुराने APK शामिल हैं, तो ऐप स्टोर वर्शन को बनाए रखना चाहिए.
APK वर्शन कोड में यह जानकारी शामिल होनी चाहिए:
- डिस्ट्रिब्यूशन फ़ॉर्मैट का वर्शन (मेजर + माइनर)
- वर्शन का बढ़ता हुआ (अस्पष्ट) नंबर
फ़िलहाल, प्लैटफ़ॉर्म का एपीआई लेवल, Distro फ़ॉर्मैट वर्शन से जुड़ा है. ऐसा इसलिए, क्योंकि हर एपीआई लेवल आम तौर पर ICU के एक नए वर्शन से जुड़ा होता है. इस वर्शन में, डिस्ट्रो फ़ाइलें काम नहीं करतीं. आने वाले समय में, Android इस फ़ॉर्मैट में बदलाव कर सकता है, ताकि डिस्ट्रो फ़ाइल कई Android प्लैटफ़ॉर्म रिलीज़ पर काम कर सके. साथ ही, डेटा ऐप्लिकेशन के वर्शन कोड स्कीम में एपीआई लेवल का इस्तेमाल न किया जा सके.
वर्शन कोड की रणनीति का उदाहरण
वर्शन नंबर के इस उदाहरण से यह पक्का होता है कि डिस्ट्रिब्यूशन फ़ॉर्मैट के ज़्यादा वर्शन, डिस्ट्रिब्यूशन फ़ॉर्मैट के कम वर्शन की जगह ले लेते हैं.
AndroidManifest.xml, android:minSdkVersion का इस्तेमाल करके यह पक्का करता है कि पुराने डिवाइसों पर, डिस्ट्रिब्यूशन फ़ॉर्मैट के ऐसे वर्शन न भेजे जाएं जो उन पर काम न कर पाएं.
छठी इमेज. वर्शन कोड की रणनीति का उदाहरण.
| उदाहरण | वैल्यू | मकसद |
|---|---|---|
| Y | बुक किया हुआ | इससे आने वाले समय में, अन्य स्कीम/टेस्ट APK इस्तेमाल किए जा सकते हैं. शुरुआत में यह वैल्यू (अनजाने में) 0 होती है. अंडरलाइंग टाइप, साइन वाला 32-बिट int टाइप है. इसलिए, यह स्कीम आने वाले समय में नंबरिंग स्कीम में किए जाने वाले दो बदलावों के साथ काम करती है. |
| 01 | मेजर फ़ॉर्मैट वर्शन | यह दशमलव अंकों वाले मेजर फ़ॉर्मैट वर्शन को ट्रैक करता है. डिस्ट्रो फ़ॉर्मैट में दशमलव के तीन अंक इस्तेमाल किए जा सकते हैं, लेकिन यहां सिर्फ़ दो अंकों का इस्तेमाल किया जाता है. हर एपीआई लेवल के लिए, ज़्यादा संख्या में ऐप्लिकेशन के अपडेट होने की उम्मीद है. इसलिए, यह मुमकिन नहीं है कि यह संख्या 100 तक पहुंच जाए. मेजर वर्शन 1, एपीआई लेवल 27 के बराबर है. |
| 1 | फ़ॉर्मैट का माइनर वर्शन | दशमलव के तीन अंकों वाले माइनर वर्शन को ट्रैक करता है. डिस्ट्रो फ़ॉर्मैट में, दशमलव के बाद तीन अंक इस्तेमाल किए जा सकते हैं. हालांकि, यहां सिर्फ़ एक अंक का इस्तेमाल किया गया है. 10 तक पहुंचने की संभावना कम है. |
| X | बुक किया हुआ | प्रोडक्शन रिलीज़ के लिए 0 है. हालांकि, टेस्ट APK के लिए यह अलग हो सकता है. |
| 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 | major=001,minor=001,iana=2017a,revision=2 |
| 4 | 11000030 | O-MR1 | major=001,minor=001,iana=2017b,revision=1 |
| 5 | 21000020 | P | major=002,minor=001,iana=2017b,revision=1 |
| 6 | 11000040 | O-MR1 | मेजर=001,माइनर=001,इयाना=2018a,रिविज़न=1 |
| 7 | 21000030 | P | major=002,minor=001,iana=2018a,revision=1 |
| 8 | 1123456789 | - | - |
| 9 | 11000021 | O-MR1 | major=001,minor=001,iana=2017a,revision=2,respin=2 |
- पहले और दूसरे उदाहरण में, एक ही 2017a IANA रिलीज़ के लिए, अलग-अलग मेजर फ़ॉर्मैट वर्शन वाले दो APK वर्शन दिखाए गए हैं. संख्या के हिसाब से 2, 1 से ज़्यादा है. यह इसलिए ज़रूरी है, ताकि नए डिवाइसों को फ़ॉर्मैट के बेहतर वर्शन मिल सकें. कम से कम SDK वर्शन से यह पक्का होता है कि O डिवाइसों पर P वर्शन उपलब्ध नहीं कराया जाएगा.
- तीसरा उदाहरण, पहले उदाहरण में बदलाव/सुधार है. यह संख्या में पहले उदाहरण से ज़्यादा है.
- चौथे और पांचवें उदाहरण में, O-MR1 और P के लिए 2017b रिलीज़ दिखाई गई हैं. ये संख्या में ज़्यादा होने की वजह से, अपने पहले वर्शन के IANA रिलीज़/Android रिविज़न की जगह ले लेते हैं.
- छठे और सातवें उदाहरण में, O-MR1 और P के लिए 2018a रिलीज़ दिखाई गई हैं.
- आठवें उदाहरण में, Y=0 स्कीम को पूरी तरह से बदलने के लिए Y का इस्तेमाल दिखाया गया है.
- नौवें उदाहरण में, तीसरे और चौथे चरण के बीच बचे अंतर का इस्तेमाल करके, ऐप्लिकेशन को फिर से स्पिन करने का तरीका बताया गया है.
हर डिवाइस, सिस्टम इमेज में डिफ़ॉल्ट रूप से, सही वर्शन वाला APK के साथ शिप होता है. इसलिए, P डिवाइस पर O-MR1 वर्शन इंस्टॉल होने का कोई खतरा नहीं है, क्योंकि इसका वर्शन नंबर, P सिस्टम इमेज के वर्शन नंबर से कम है. /data में O-MR1 वर्शन इंस्टॉल किया गया डिवाइस, P पर सिस्टम अपडेट होने के बाद, /data में मौजूद O-MR1 वर्शन के बजाय /system वर्शन का इस्तेमाल करता है. इसकी वजह यह है कि P वर्शन, O-MR1 के लिए बनाए गए किसी भी ऐप्लिकेशन से हमेशा बेहतर होता है.
टापस का इस्तेमाल करके डेटा ऐप्लिकेशन बनाएं
टाइम ज़ोन डेटा ऐप्लिकेशन के ज़्यादातर पहलुओं को मैनेज करने और सिस्टम इमेज को सही तरीके से कॉन्फ़िगर करने की ज़िम्मेदारी OEM की होती है. डेटा ऐप्लिकेशन को tapas बिल्ड के साथ बनाया जाना चाहिए. इससे, शुरुआती रिलीज़ के लिए सिस्टम इमेज में जोड़े जाने वाले APK बनते हैं. साथ ही, बाद के अपडेट के लिए, ऐप्लिकेशन स्टोर के ज़रिए हस्ताक्षर किए जाते हैं और उन्हें डिस्ट्रिब्यूट किया जाता है.
Tapas, Android के बिल्ड सिस्टम का छोटा वर्शन है. यह ऐप्लिकेशन के डिस्ट्रिब्यूट किए जा सकने वाले वर्शन बनाने के लिए, कम सोर्स ट्री का इस्तेमाल करता है. सामान्य Android बिल्ड सिस्टम के बारे में जानने वाले OEM को, सामान्य Android प्लैटफ़ॉर्म बिल्ड से, बिल्ड फ़ाइलों को पहचानना चाहिए.
मेनिफ़ेस्ट बनाना
आम तौर पर, कम सोर्स ट्री बनाने के लिए कस्टम मेनिफ़ेस्ट फ़ाइल का इस्तेमाल किया जाता है. इसमें सिर्फ़ उन Git प्रोजेक्ट के बारे में बताया जाता है जो ऐप्लिकेशन बनाने और बिल्ड सिस्टम के लिए ज़रूरी होते हैं. डेटा ऐप्लिकेशन बनाना में दिए गए निर्देशों का पालन करने के बाद, OEM के पास कम से कम दो OEM-specific Git प्रोजेक्ट होने चाहिए. ये प्रोजेक्ट, packages/apps/TimeZoneData/oem_template में मौजूद टेंप्लेट फ़ाइलों का इस्तेमाल करके बनाए जाते हैं:
- एक Git प्रोजेक्ट में मेनिफ़ेस्ट जैसी ऐप्लिकेशन फ़ाइलें और
ऐप्लिकेशन APK फ़ाइल बनाने के लिए ज़रूरी बिल्ड फ़ाइलें (उदाहरण के लिए,
vendor/oem/apps/TimeZoneData) शामिल हैं. इस प्रोजेक्ट में परीक्षण APK के लिए बिल्ड नियम भी शामिल हैं, जिनका इस्तेमाल xTS परीक्षणों में किया जा सकता है. - एक Git प्रोजेक्ट में, सिस्टम इमेज बिल्ड और xTS टेस्ट में शामिल करने के लिए, ऐप्लिकेशन बिल्ड से जनरेट किए गए हस्ताक्षर किए गए APK शामिल होते हैं.
ऐप्लिकेशन बिल्ड, कई अन्य Git प्रोजेक्ट का फ़ायदा लेता है. ये प्रोजेक्ट, प्लैटफ़ॉर्म बिल्ड के साथ शेयर किए जाते हैं या इनमें OEM से स्वतंत्र कोड लाइब्रेरी होती हैं.
नीचे दिए गए मेनिफ़ेस्ट स्निपेट में टाइम ज़ोन डेटा ऐप्लिकेशन के O-MR1 बिल्ड के साथ काम करने के लिए ज़रूरी Git प्रोजेक्ट का कम से कम सेट शामिल है. OEM को इस मेनिफ़ेस्ट में अपने OEM-खास Git प्रोजेक्ट (जिसमें आम तौर पर एक ऐसा प्रोजेक्ट शामिल होता है जिसमें हस्ताक्षर का सर्टिफ़िकेट होता है) जोड़ना होगा और उसके हिसाब से अलग-अलग शाखाएं कॉन्फ़िगर की जा सकती हैं.
<!-- 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" />
tapas बिल्ड चलाना
सोर्स ट्री बन जाने के बाद, यहां दिए गए कमांड का इस्तेमाल करके tapas बिल्ड को शुरू करें:
source build/envsetup.shtapasmake -j30 showcommands dist TARGET_BUILD_APPS='TimeZoneData TimeZoneData_test1 TimeZoneData_test2' TARGET_BUILD_VARIANT=userdebug
बिल्ड पूरा होने पर, जांच के लिए out/dist डायरेक्ट्री में फ़ाइलें जनरेट होती हैं. इन फ़ाइलों को सिस्टम इमेज में शामिल करने और/या साथ काम करने वाले डिवाइसों के लिए ऐप स्टोर से डिस्ट्रिब्यूट करने के लिए, पहले से बनी हुई डायरेक्ट्री में रखा जा सकता है.