टाइम ज़ोन के नियम

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 डिवाइसों पर, डेलाइट सेविंग टाइम (डीएसटी) और टाइम ज़ोन को अपडेट करता है. साथ ही, इस डेटा को स्टैंडर्ड बनाता है, जो धार्मिक, राजनैतिक, और भू-राजनैतिक वजहों से बार-बार बदल सकता है.

अपडेट करने के लिए, यह प्रोसेस अपनाई जाती है:

1. IANA, टाइम ज़ोन डेटाबेस में अपडेट रिलीज़ करता है. ऐसा तब किया जाता है, जब एक या उससे ज़्यादा सरकारें अपने देशों में टाइम ज़ोन के नियम में बदलाव करती हैं.
2. Google या Android पार्टनर, टाइम ज़ोन डेटा मॉड्यूल अपडेट (APEX फ़ाइल) तैयार करता है. इसमें अपडेट किए गए टाइम ज़ोन शामिल होते हैं.
3. उपयोगकर्ता का डिवाइस, अपडेट डाउनलोड करता है, रीबूट होता है, और फिर बदलाव लागू करता है. इसके बाद, डिवाइस के टाइम ज़ोन के डेटा में, अपडेट से मिला नया टाइम ज़ोन डेटा शामिल होता है.

मॉड्यूल के बारे में ज़्यादा जानने के लिए, मॉड्यूलर सिस्टम कॉम्पोनेंट लेख पढ़ें.

टाइम ज़ोन से जुड़े अपडेट (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, ऐसा सिस्टम ऐप्लिकेशन जिसे अपडेट नहीं किया जा सकता (इसे अपडेटर ऐप्लिकेशन भी कहा जाता है). OEM को इस सुविधा का इस्तेमाल करने वाले डिवाइसों की सिस्टम इमेज में, यह ऐप्लिकेशन शामिल करना होगा.
• OEM TimeZoneData, यह एक अपडेट किया जा सकने वाला सिस्टम ऐप्लिकेशन है. इसे डेटा ऐप्लिकेशन भी कहा जाता है. यह डिवाइस में डिस्ट्रिब्यूशन फ़ाइलें ले जाता है और उन्हें Updater ऐप्लिकेशन के लिए उपलब्ध कराता है. OEM को इस ऐप्लिकेशन को, इस सुविधा का इस्तेमाल करने वाले डिवाइसों की सिस्टम इमेज में शामिल करना होगा.
• tzdatacheck, टाइम ज़ोन के अपडेट को सही और सुरक्षित तरीके से लागू करने के लिए, बूट-टाइम बाइनरी की ज़रूरत होती है.

Android सोर्स ट्री में ऊपर दिए गए कॉम्पोनेंट के लिए सामान्य सोर्स कोड होता है. OEM, बिना किसी बदलाव के इसका इस्तेमाल कर सकता है. टेस्ट कोड, OEM को यह अपने-आप जांचने की सुविधा देता है कि उन्होंने सुविधा को सही तरीके से चालू किया है या नहीं.

डिस्ट्रिब्यूशन इंस्टॉल करना

डिस्ट्रो इंस्टॉल करने की प्रोसेस में ये चरण शामिल हैं:

1. ऐप्लिकेशन स्टोर से डाउनलोड करने या साइडलोड करने के ज़रिए, डेटा ऐप्लिकेशन अपडेट हो जाता है. सिस्टम सर्वर प्रोसेस (timezone.RulesManagerServer/timezone.PackageTracker क्लास के ज़रिए), कॉन्फ़िगर किए गए, OEM के हिसाब से, डेटा ऐप्लिकेशन पैकेज के नाम में होने वाले बदलावों को देखती है.
   
   

   पहली इमेज. डेटा ऐप्लिकेशन के अपडेट.

2. सिस्टम सर्वर प्रोसेस, अपडेट की जांच को ट्रिगर करता है. इसके लिए, वह Updater ऐप्लिकेशन पर एक यूनीक और एक बार इस्तेमाल होने वाले टोकन के साथ टारगेट किया गया इंटेंट ब्रॉडकास्ट करता है. सिस्टम सर्वर, जनरेट किए गए सबसे नए टोकन को ट्रैक करता है, ताकि यह पता लगाया जा सके कि ट्रिगर की गई सबसे नई जांच कब पूरी हुई. किसी भी दूसरे टोकन को अनदेखा कर दिया जाता है.
   
   

   दूसरी इमेज. अपडेट की जांच करने की सुविधा को ट्रिगर करें.

3. अपडेट की जांच के दौरान, Updater ऐप्लिकेशन ये काम करता है:
   • RulesManagerService को कॉल करके, डिवाइस की मौजूदा स्थिति के बारे में क्वेरी करता है.
     
     

     तीसरी इमेज. डेटा ऐप्लिकेशन के अपडेट, RulesManagerService को कॉल कर रहे हैं.

   • डिस्ट्रिब्यूशन के बारे में जानकारी पाने के लिए, Data ऐप्लिकेशन को क्वेरी भेजता है. इसके लिए, यह अच्छी तरह से तय किए गए ContentProvider यूआरएल और कॉलम के स्पेसिफ़िकेशन की क्वेरी करता है.
     
     

     चौथी इमेज. डेटा ऐप्लिकेशन के अपडेट, डिस्ट्रिब्यूशन के बारे में जानकारी पाएं.

4. अपडेटर ऐप्लिकेशन, अपनी जानकारी के आधार पर सही कार्रवाई करता है. उपलब्ध कार्रवाइयों में ये शामिल हैं:
   • इंस्टॉल करने का अनुरोध करें. डिस्ट्रो डेटा को Data ऐप्लिकेशन से पढ़ा जाता है और सिस्टम सर्वर में RulesManagerService को भेजा जाता है. RulesManagerService, डिस्ट्रिब्यूशन फ़ॉर्मैट के वर्शन और कॉन्टेंट की फिर से पुष्टि करता है कि यह डिवाइस के लिए सही है या नहीं. इसके बाद, वह इंस्टॉल की प्रोसेस शुरू करता है.
   • अनइंस्टॉल करने का अनुरोध करें (ऐसा बहुत कम होता है). उदाहरण के लिए, अगर /data में अपडेट किया गया APK बंद किया जा रहा है या अनइंस्टॉल किया जा रहा है और डिवाइस /system में मौजूद वर्शन पर वापस आ रहा है.
   • कुछ न करें. यह तब होता है, जब डेटा ऐप्लिकेशन डिस्ट्रिब्यूशन अमान्य हो.
   सभी मामलों में, Updater ऐप्लिकेशन, जांच करने वाले टोकन के साथ RulesManagerService को कॉल करता है, ताकि सिस्टम सर्वर को पता चल सके कि जांच पूरी हो गई है और वह सही है.
   
   

   पांचवीं इमेज. जांच पूरी हो गई.

5. डिवाइस को रीबूट करें और tzdatacheck चलाएं. डिवाइस को अगली बार बूट करने पर, tzdatacheck बाइनरी, किसी भी स्टेज वाले ऑपरेशन को पूरा करता है. tzdatacheck बाइनरी, ये काम कर सकती है:
   • सिस्टम के अन्य कॉम्पोनेंट के खुलने और फ़ाइलों का इस्तेमाल शुरू करने से पहले, /data/misc/zoneinfo/current फ़ाइलों को बनाने, बदलने, और/या मिटाने की प्रोसेस को मैनेज करके, चरणों में की जाने वाली कार्रवाई को पूरा करें.
   • देखें कि /data में मौजूद फ़ाइलें, प्लैटफ़ॉर्म के मौजूदा वर्शन के लिए सही हैं या नहीं. ऐसा तब नहीं हो सकता, जब डिवाइस को हाल ही में सिस्टम अपडेट मिला हो और डिस्ट्रिब्यूशन फ़ॉर्मैट का वर्शन बदल गया हो.
   • पक्का करें कि IANA के नियमों का वर्शन, /system में मौजूद वर्शन के बराबर या उससे नया हो. इससे, सिस्टम अपडेट होने पर, डिवाइस पर /system इमेज में मौजूद समय क्षेत्र के नियमों के पुराने डेटा के बजाय, नए डेटा के सेव होने से बचा जा सकता है.

विश्वसनीयता

इंस्टॉल करने की पूरी प्रोसेस एसिंक्रोनस होती है और इसे ओएस की तीन प्रोसेस में बांटा जाता है. इंस्टॉलेशन के दौरान, डिवाइस की बैटरी खत्म हो सकती है, डिस्क का स्टोरेज भर सकता है या कोई दूसरी समस्या आ सकती है. इस वजह से, इंस्टॉलेशन की जांच पूरी नहीं हो पाती. अपडेट न हो पाने के सबसे अच्छे मामले में, Updater ऐप्लिकेशन, सिस्टम सर्वर को बताता है कि अपडेट नहीं हो सका; अपडेट न हो पाने के सबसे बुरे मामले में, RulesManagerService को कोई कॉल नहीं मिलता.

इसे मैनेज करने के लिए, सिस्टम सर्वर कोड यह ट्रैक करता है कि ट्रिगर किया गया अपडेट की जांच पूरा हो गया है या नहीं. साथ ही, यह भी ट्रैक करता है कि Data ऐप्लिकेशन का पिछला जांचा गया वर्शन कोड क्या है. जब डिवाइस इस्तेमाल में नहीं है और चार्ज हो रहा है, तब सिस्टम सर्वर कोड मौजूदा स्थिति की जांच कर सकता है. अगर यह पता चलता है कि अपडेट की जांच अधूरी है या Data Studio ऐप्लिकेशन का वर्शन गलत है, तो यह अपने-आप अपडेट की जांच शुरू कर देता है.

सुरक्षा

चालू होने पर, सिस्टम सर्वर में मौजूद RulesManagerService कोड कई जांच करता है. इससे यह पक्का किया जाता है कि सिस्टम का इस्तेमाल करना सुरक्षित है.

• गलत तरीके से कॉन्फ़िगर की गई सिस्टम इमेज से जुड़ी समस्याओं की वजह से, डिवाइस को बूट होने में समस्या आती है. उदाहरण के लिए, अपडेटर या डेटा ऐप्लिकेशन का गलत कॉन्फ़िगरेशन या अपडेटर या डेटा ऐप्लिकेशन का /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, डेटा ऐप्लिकेशन को अपने आइकॉन, नाम, अनुवाद, और अन्य जानकारी के साथ पसंद के मुताबिक बना सकते हैं. हालांकि, डेटा ऐप्लिकेशन को लॉन्च नहीं किया जा सकता. इसलिए, आइकॉन सिर्फ़ सेटिंग > ऐप्लिकेशन स्क्रीन पर दिखता है.

डेटा ऐप्लिकेशन को tapas बिल्ड के साथ बनाया जाना चाहिए. इससे, शुरुआती रिलीज़ के लिए सिस्टम इमेज में जोड़े जाने वाले APK बनते हैं. साथ ही, बाद के अपडेट के लिए, ऐप्लिकेशन स्टोर के ज़रिए उन्हें साइन और डिस्ट्रिब्यूट किया जाता है. tapas का इस्तेमाल करने के बारे में ज़्यादा जानने के लिए, tapas का इस्तेमाल करके डेटा ऐप्लिकेशन बनाना लेख पढ़ें.

OEM को /system/priv-app में, डिवाइस की सिस्टम इमेज में पहले से मौजूद डेटा ऐप्लिकेशन को इंस्टॉल करना होगा. सिस्टम इमेज में पहले से बने APKs (tapas के ज़रिए जनरेट किए गए) शामिल करने के लिए, OEM packages/apps/TimeZoneData/oem_template/data_app_prebuilt में मौजूद उदाहरण फ़ाइलों को कॉपी कर सकते हैं. उदाहरण के तौर पर दिए गए टेंप्लेट में, टेस्ट सुइट में Data ऐप्लिकेशन के टेस्ट वर्शन शामिल करने के लिए, बिल्ड टारगेट भी शामिल होते हैं.

सिस्टम इमेज में Updater और Data ऐप्लिकेशन शामिल करना

OEM को अपडेटर और डेटा ऐप्लिकेशन के APK, सिस्टम इमेज की /system/priv-app डायरेक्ट्री में डालने होंगे. ऐसा करने के लिए, सिस्टम इमेज के बिल्ड में, अपडेटर ऐप्लिकेशन और डेटा ऐप्लिकेशन के पहले से बने टारगेट शामिल होने चाहिए.

Updater ऐप्लिकेशन को प्लैटफ़ॉर्म पासकोड से साइन किया जाना चाहिए और किसी भी दूसरे सिस्टम ऐप्लिकेशन की तरह शामिल किया जाना चाहिए. टारगेट को packages/apps/TimeZoneUpdater में TimeZoneUpdater के तौर पर दिखाया गया है. डेटा ऐप्लिकेशन को शामिल करने की सुविधा, OEM के हिसाब से तय होती है. यह सुविधा, पहले से बने वर्शन के लिए चुने गए टारगेट के नाम पर निर्भर करती है.

सिस्टम सर्वर को कॉन्फ़िगर करना

टाइम ज़ोन के अपडेट की सुविधा चालू करने के लिए, OEM, frameworks/base/core/res/res/values/config.xml में बताई गई कॉन्फ़िगरेशन प्रॉपर्टी को बदलकर, सिस्टम सर्वर को कॉन्फ़िगर कर सकते हैं.

config_enableUpdateableTimeZoneRules

config_timeZoneRulesUpdateTrackingEnabled

config_timeZoneRulesDataPackage

config_timeZoneRulesUpdaterPackage

config_timeZoneRulesCheckTimeMillisAllowed

config_timeZoneRulesCheckRetryCount

कॉन्फ़िगरेशन बदलने की सुविधा, सिस्टम इमेज में होनी चाहिए, न कि वेंडर या किसी अन्य में, क्योंकि गलत तरीके से कॉन्फ़िगर किया गया डिवाइस, शायद बूट न हो. अगर कॉन्फ़िगरेशन बदलने की सुविधा, वेंडर इमेज में थी, तो डेटा ऐप्लिकेशन के बिना (या अलग-अलग डेटा ऐप्लिकेशन/अपडेटर ऐप्लिकेशन पैकेज के नामों के साथ) सिस्टम इमेज पर अपडेट करने को गलत कॉन्फ़िगरेशन माना जाएगा.

xTS टेस्टिंग

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 शामिल है, तो ऐप्लिकेशन स्टोर का वर्शन ही इस्तेमाल किया जाना चाहिए.

APK वर्शन कोड में यह जानकारी शामिल होनी चाहिए:

• डिस्ट्रिब्यूशन फ़ॉर्मैट का वर्शन (मेजर + माइनर)
• वर्शन का बढ़ता हुआ (अस्पष्ट) नंबर

फ़िलहाल, प्लैटफ़ॉर्म के एपीआई लेवल का डिस्ट्रो फ़ॉर्मैट के वर्शन से काफ़ी गहरा संबंध है. ऐसा इसलिए है, क्योंकि आम तौर पर हर एपीआई लेवल, ICU के नए वर्शन से जुड़ा होता है. इस वजह से, डिस्ट्रो फ़ाइलें काम नहीं करतीं. आने वाले समय में, Android इस फ़ॉर्मैट में बदलाव कर सकता है, ताकि डिस्ट्रो फ़ाइल कई Android प्लैटफ़ॉर्म रिलीज़ पर काम कर सके. साथ ही, डेटा ऐप्लिकेशन के वर्शन कोड स्कीम में एपीआई लेवल का इस्तेमाल न किया जा सके.

वर्शन कोड की रणनीति का उदाहरण

वर्शन नंबर के इस उदाहरण से यह पक्का होता है कि डिस्ट्रिब्यूशन फ़ॉर्मैट के ज़्यादा वर्शन, डिस्ट्रिब्यूशन फ़ॉर्मैट के कम वर्शन की जगह ले लेते हैं. AndroidManifest.xml, android:minSdkVersion का इस्तेमाल करके यह पक्का करता है कि पुराने डिवाइसों पर, डिस्ट्रिब्यूशन फ़ॉर्मैट के ऐसे वर्शन न भेजे जाएं जो उन पर काम न कर पाएं.

छठी इमेज. वर्शन कोड की रणनीति का उदाहरण.

दशमलव के बजाय बाइनरी का इस्तेमाल करने पर, स्कीम को बेहतर तरीके से पैक किया जा सकता है. हालांकि, इस स्कीम का फ़ायदा यह है कि इसे कोई भी व्यक्ति पढ़ सकता है. अगर पूरी संख्या सीमा खत्म हो जाती है, तो डेटा ऐप्लिकेशन के पैकेज का नाम बदल सकता है.

वर्शन का नाम, जानकारी का ऐसा वर्शन होता है जिसे कोई भी व्यक्ति आसानी से पढ़ सकता है. उदाहरण के लिए: major=001,minor=001,iana=2017a, revision=1,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 के लिए बनाए गए किसी भी ऐप्लिकेशन से हमेशा बेहतर होता है.

tapas का इस्तेमाल करके डेटा ऐप्लिकेशन बनाना

टाइम ज़ोन डेटा ऐप्लिकेशन के ज़्यादातर पहलुओं को मैनेज करने और सिस्टम इमेज को सही तरीके से कॉन्फ़िगर करने की ज़िम्मेदारी 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 प्रोजेक्ट जोड़ने होंगे. आम तौर पर, इनमें ऐसा प्रोजेक्ट शामिल होता है जिसमें हस्ताक्षर करने का सर्टिफ़िकेट होता है. साथ ही, 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" />

tapas बिल्ड चलाना

सोर्स ट्री सेट अप होने के बाद, इन कमांड का इस्तेमाल करके tapas बिल्ड को शुरू करें:

source build/envsetup.sh
tapas
make -j30 showcommands dist TARGET_BUILD_APPS='TimeZoneData TimeZoneData_test1 TimeZoneData_test2'  TARGET_BUILD_VARIANT=userdebug

बिल्ड पूरा होने पर, जांच के लिए out/dist डायरेक्ट्री में फ़ाइलें जनरेट होती हैं. इन फ़ाइलों को सिस्टम इमेज में शामिल करने के लिए, पहले से बनी डायरेक्ट्री में रखा जा सकता है और/या काम करने वाले डिवाइसों के लिए, ऐप्लिकेशन स्टोर से डिस्ट्रिब्यूट किया जा सकता है.