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

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

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

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

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

बंद की गई सेवाओं/सुविधाओं से जुड़े नोट

Android ने अगस्त 2026 में, Android 10 के लिए टाइम ज़ोन पैच उपलब्ध कराना बंद कर दिया था. TZDB 2026c आखिरी पैच था. ओईएम के पास Android 10 के लिए सहायता जारी रखने का विकल्प होता है.

टाइम ज़ोन के अपडेट (Android 8.1–9)

ध्यान दें: APK पर आधारित टाइम ज़ोन के डेटा को अपडेट करने की सुविधा, Android 14 से पूरी तरह हटा दी गई है. यह सोर्स कोड में भी नहीं मिलती. पार्टनर को पूरी तरह से टाइम ज़ोन मेनलाइन मॉड्यूल पर माइग्रेट करना चाहिए.

Android 8.1 और Android 9 में, OEM, APK पर आधारित एक ऐसे सिस्टम का इस्तेमाल कर सकते हैं जिससे डिवाइसों पर अपडेट किए गए टाइम ज़ोन के नियमों का डेटा भेजा जा सकता है. इसके लिए, सिस्टम अपडेट करने की ज़रूरत नहीं होती. इस सुविधा की मदद से, उपयोगकर्ताओं को समय पर अपडेट मिलते हैं. इससे Android डिवाइस का इस्तेमाल लंबे समय तक किया जा सकता है. साथ ही, Android के पार्टनर, सिस्टम इमेज के अपडेट से अलग टाइम ज़ोन के अपडेट की जांच कर सकते हैं.

Android की कोर लाइब्रेरी टीम, स्टॉक Android डिवाइस पर टाइम ज़ोन के नियमों को अपडेट करने के लिए ज़रूरी डेटा फ़ाइलें उपलब्ध कराती है. ओईएम के पास यह विकल्प होता है कि वे अपने डिवाइसों के लिए टाइम ज़ोन के अपडेट बनाते समय, इन डेटा फ़ाइलों का इस्तेमाल करें. इसके अलावा, वे चाहें, तो अपनी डेटा फ़ाइलें भी बना सकते हैं. सभी मामलों में, ओईएम के पास यह कंट्रोल होता है कि वे अपने डिवाइसों के लिए, टाइम ज़ोन के नियमों से जुड़े अपडेट की क्वालिटी की जांच कब करें, उन्हें कब लॉन्च करें, और उनकी क्वालिटी कैसी हो.

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 के उन वर्शन के लिए डिस्ट्रो फ़ाइलें उपलब्ध कराता है जिन पर यह काम करता है. साथ ही, यह प्लैटफ़ॉर्म की सिस्टम फ़ाइलों को भी अपडेट करता है. अपने डिवाइसों को अप-टू-डेट रखने के लिए, ओईएम इन डिस्ट्रो फ़ाइलों का इस्तेमाल कर सकते हैं. इसके अलावा, वे Android सोर्स ट्री का इस्तेमाल करके अपनी डिस्ट्रो फ़ाइलें बना सकते हैं. Android सोर्स ट्री में, डिस्ट्रो फ़ाइलें जनरेट करने के लिए ज़रूरी स्क्रिप्ट और अन्य फ़ाइलें होती हैं.

टाइम ज़ोन अपडेट करने वाले कॉम्पोनेंट

टाइम ज़ोन के नियमों से जुड़े अपडेट में, डिस्ट्रो फ़ाइलों को किसी डिवाइस पर ट्रांसफ़र करना और उनमें मौजूद फ़ाइलों को सुरक्षित तरीके से इंस्टॉल करना शामिल है. ट्रांसफ़र और इंस्टॉल करने के लिए, ये ज़रूरी शर्तें पूरी होनी चाहिए:

• प्लैटफ़ॉर्म सेवा की सुविधा (timezone.RulesManagerService), जो डिफ़ॉल्ट रूप से बंद होती है. OEM को कॉन्फ़िगरेशन के ज़रिए इस सुविधा को चालू करना होगा. RulesManagerService, सिस्टम सर्वर प्रोसेस में चलता है और /data/misc/zoneinfo/staged में लिखकर, टाइम ज़ोन अपडेट करने की कार्रवाइयों को स्टेज करता है. RulesManagerService पहले से स्टेज की गई कार्रवाइयों को बदल भी सकता है या मिटा भी सकता है.
• TimeZoneUpdater, एक ऐसा सिस्टम ऐप्लिकेशन जिसे अपडेट नहीं किया जा सकता (इसे Updater ऐप्लिकेशन भी कहा जाता है). OEM को इस ऐप्लिकेशन को, इस सुविधा का इस्तेमाल करने वाले डिवाइसों की सिस्टम इमेज में शामिल करना होगा.
• ओईएम TimeZoneData, अपडेट किया जा सकने वाला सिस्टम ऐप्लिकेशन (इसे डेटा ऐप्लिकेशन भी कहा जाता है). यह डिवाइस पर डिस्ट्रो फ़ाइलें भेजता है और उन्हें Updater ऐप्लिकेशन के लिए उपलब्ध कराता है. ओईएम को इस ऐप्लिकेशन को, इस सुविधा का इस्तेमाल करने वाले डिवाइसों की सिस्टम इमेज में शामिल करना होगा.
• tzdatacheck, यह बूट-टाइम बाइनरी है. इसकी ज़रूरत, टाइम ज़ोन के अपडेट को सही और सुरक्षित तरीके से लागू करने के लिए होती है.

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

Distro installation

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

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

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

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

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

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

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

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

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

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

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

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

विश्वसनीयता

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

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

सुरक्षा

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

• सिस्टम इमेज के गलत तरीके से कॉन्फ़िगर होने की वजह से, डिवाइस बूट नहीं हो पाता. उदाहरण के लिए, Updater या Data ऐप्लिकेशन का कॉन्फ़िगरेशन गलत होना या Updater या Data ऐप्लिकेशन का /system/priv-app में मौजूद न होना.
• डेटा ऐप्लिकेशन के इंस्टॉल होने से जुड़ी समस्याओं की वजह से, डिवाइस बूट होने में कोई रुकावट नहीं आती. हालांकि, अपडेट की जांच ट्रिगर नहीं होती. उदाहरण के लिए, सिस्टम की ज़रूरी अनुमतियों का न होना या डेटा ऐप्लिकेशन का, अनुमानित यूआरआई पर ContentProvider को उपलब्ध न कराना.

SELinux के नियमों का इस्तेमाल करके, /data/misc/zoneinfo डायरेक्ट्री के लिए फ़ाइल की अनुमतियां लागू की जाती हैं. किसी भी APK की तरह, डेटा ऐप्लिकेशन को उसी कुंजी से साइन किया जाना चाहिए जिसका इस्तेमाल /system/priv-app वर्शन को साइन करने के लिए किया गया था. डेटा ऐप्लिकेशन के लिए, ओईएम के हिसाब से पैकेज का नाम और पासकोड होना चाहिए.

टाइम ज़ोन अपडेट को इंटिग्रेट करना

टाइम ज़ोन अपडेट करने की सुविधा चालू करने के लिए, ओईएम आम तौर पर:

• अपना खुद का डेटा ऐप्लिकेशन बना सकते हैं.
• सिस्टम इमेज बिल्ड में Updater और Data ऐप्लिकेशन शामिल करें.
• RulesManagerService को चालू करने के लिए, सिस्टम सर्वर को कॉन्फ़िगर करें.

तैयारी

शुरू करने से पहले, ओईएम को यहां दी गई नीति, क्वालिटी अश्योरेंस, और सुरक्षा से जुड़ी बातों की समीक्षा करनी चाहिए:

• अपने डेटा ऐप्लिकेशन के लिए, ऐप्लिकेशन के हिसाब से साइनिंग की खास कुंजी बनाएं.
• टाइम ज़ोन के अपडेट के लिए, रिलीज़ और वर्शनिंग की रणनीति बनाएं. इससे यह समझने में मदद मिलेगी कि किन डिवाइसों को अपडेट किया जाएगा. साथ ही, यह भी पता चलेगा कि यह कैसे पक्का किया जा सकता है कि अपडेट सिर्फ़ उन डिवाइसों पर इंस्टॉल किए जाएं जिन पर इनकी ज़रूरत है. उदाहरण के लिए, ओईएम अपने सभी डिवाइसों के लिए एक ही डेटा ऐप्लिकेशन का इस्तेमाल कर सकते हैं. इसके अलावा, वे अलग-अलग डिवाइसों के लिए अलग-अलग डेटा ऐप्लिकेशन का इस्तेमाल भी कर सकते हैं. इस फ़ैसले से पैकेज के नाम, इस्तेमाल किए गए वर्शन कोड, और क्वालिटी अश्योरेंस (क्यूए) की रणनीति पर असर पड़ता है.
• यह समझें कि उन्हें एओएसपी से स्टॉक Android के टाइमज़ोन डेटा का इस्तेमाल करना है या अपना डेटा बनाना है.

डेटा ऐप्लिकेशन बनाना

AOSP में, packages/apps/TimeZoneData में डेटा ऐप्लिकेशन बनाने के लिए ज़रूरी सभी सोर्स कोड और बिल्ड नियम शामिल होते हैं. साथ ही, AndroidManifest.xml और packages/apps/TimeZoneData/oem_template में मौजूद अन्य फ़ाइलों के लिए निर्देश और उदाहरण टेंप्लेट भी शामिल होते हैं. उदाहरण के तौर पर दिए गए टेंप्लेट में, Data ऐप्लिकेशन के असली APK के लिए बिल्ड टारगेट और Data ऐप्लिकेशन के टेस्ट वर्शन बनाने के लिए अतिरिक्त टारगेट, दोनों शामिल हैं.

OEM, Data app को अपने आइकॉन, नाम, अनुवाद, और अन्य जानकारी के हिसाब से पसंद के मुताबिक बना सकते हैं. हालांकि, Data ऐप्लिकेशन को लॉन्च नहीं किया जा सकता. इसलिए, यह आइकॉन सिर्फ़ सेटिंग > ऐप्लिकेशन स्क्रीन पर दिखता है.

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

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

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

OEM को Updater और Data ऐप्लिकेशन के APK, सिस्टम इमेज की /system/priv-app डायरेक्ट्री में रखने होंगे. इसके लिए, सिस्टम इमेज बिल्ड में Updater ऐप्लिकेशन और Data ऐप्लिकेशन के प्रीबिल्ट टारगेट को साफ़ तौर पर शामिल करना होगा.

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

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

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

config_enableUpdateableTimeZoneRules

config_timeZoneRulesUpdateTrackingEnabled

config_timeZoneRulesDataPackage

config_timeZoneRulesUpdaterPackage

config_timeZoneRulesCheckTimeMillisAllowed

config_timeZoneRulesCheckRetryCount

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

xTS टेस्टिंग

xTS का मतलब, ओईएम के हिसाब से बनाए गए किसी ऐसे टेस्ट सुइट से है जो Tradefed का इस्तेमाल करने वाले स्टैंडर्ड Android टेस्ट सुइट (जैसे, CTS और VTS) के जैसा हो. जिन ओईएम के पास इस तरह की टेस्ट सुइट हैं वे यहां दिए गए Android टाइम ज़ोन अपडेट टेस्ट जोड़ सकते हैं:

• packages/apps/TimeZoneData/testing/xts में, बुनियादी ऑटोमेटेड फ़ंक्शनल टेस्टिंग के लिए ज़रूरी कोड शामिल होता है.
• packages/apps/TimeZoneData/oem_template/xts में, Tradefed जैसी xTS सुइट में टेस्ट शामिल करने के लिए, सैंपल डायरेक्ट्री स्ट्रक्चर मौजूद है. अन्य टेंप्लेट डायरेक्ट्री की तरह, ओईएम से उम्मीद की जाती है कि वे अपनी ज़रूरतों के हिसाब से टेंप्लेट को कॉपी करें और उनमें बदलाव करें.
• packages/apps/TimeZoneData/oem_template/data_app_prebuilt में, टेस्ट के लिए ज़रूरी पहले से बनाए गए टेस्ट APK को शामिल करने के लिए, बिल्ड-टाइम कॉन्फ़िगरेशन होता है.

टाइम ज़ोन के अपडेट बनाना

जब IANA, टाइम ज़ोन के नियमों का नया सेट रिलीज़ करता है, तब Android की कोर लाइब्रेरी टीम, AOSP में रिलीज़ को अपडेट करने के लिए पैच जनरेट करती है. स्टॉक Android सिस्टम और डिस्ट्रो फ़ाइलों का इस्तेमाल करने वाले ओईएम, इन कमिट को चुन सकते हैं. इनका इस्तेमाल करके, वे अपने डेटा ऐप्लिकेशन का नया वर्शन बना सकते हैं. इसके बाद, वे इस नए वर्शन को रिलीज़ करके, प्रोडक्शन में अपने डिवाइसों को अपडेट कर सकते हैं.

डेटा ऐप्लिकेशन में डिस्ट्रो फ़ाइलें होती हैं, जो Android के वर्शन से जुड़ी होती हैं. इसलिए, ओईएम को Android के हर उस वर्शन के लिए डेटा ऐप्लिकेशन का नया वर्शन बनाना होगा जिसे ओईएम अपडेट करना चाहता है. उदाहरण के लिए, अगर किसी ओईएम को Android 8.1, 9, और 10 वर्शन वाले डिवाइसों के लिए अपडेट उपलब्ध कराने हैं, तो उसे यह प्रोसेस तीन बार पूरी करनी होगी.

पहला चरण: सिस्टम/टाइमज़ोन और बाहरी/आईसीयू डेटा फ़ाइलों को अपडेट करना

इस चरण में, ओईएम, AOSP में release-dev ब्रांच से system/timezone और external/icu के लिए स्टॉक Android कमिट लेते हैं. इसके बाद, वे इन कमिट को 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 बनाते समय, अपने-आप शामिल हो जाती है.

दूसरा चरण: डेटा ऐक्सेस करने वाले ऐप्लिकेशन का वर्शन कोड अपडेट करना

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

तीसरा चरण: फिर से बनाना, हस्ताक्षर करना, टेस्ट करना, और रिलीज़ करना

इस चरण में, ओईएम, टपास का इस्तेमाल करके APK को फिर से बनाते हैं. इसके बाद, जनरेट किए गए APK पर हस्ताक्षर करते हैं. फिर, APK की जांच करते हैं और उसे रिलीज़ करते हैं:

• रिलीज़ नहीं किए गए डिवाइसों के लिए या रिलीज़ किए गए डिवाइस के लिए सिस्टम अपडेट तैयार करते समय, डेटा ऐप्लिकेशन की प्रीबिल्ट डायरेक्ट्री में नए APK सबमिट करें. इससे यह पक्का किया जा सकेगा कि सिस्टम इमेज और xTS टेस्ट में नए APK मौजूद हैं. OEM को यह जांच करनी चाहिए कि नई फ़ाइल ठीक से काम कर रही है या नहीं. इसका मतलब है कि वह सीटीएस और OEM के हिसाब से बनाए गए किसी भी ऑटोमेटेड और मैन्युअल टेस्ट को पास करती हो.
• जिन डिवाइसों के लिए सिस्टम अपडेट अब नहीं मिलते हैं उनके लिए, साइन किए गए APK को सिर्फ़ ऐप्लिकेशन स्टोर के ज़रिए रिलीज़ किया जा सकता है.

ओईएम, अपडेट किए गए Data app की क्वालिटी अश्योरेंस और उसे रिलीज़ करने से पहले अपने डिवाइसों पर टेस्ट करने के लिए ज़िम्मेदार होते हैं.

ऐप्लिकेशन के वर्शन कोड से जुड़ी डेटा स्ट्रैटेजी

डेटा ऐप्लिकेशन में वर्शनिंग की सही रणनीति होनी चाहिए, ताकि यह पक्का किया जा सके कि डिवाइसों को सही APK मिलें. उदाहरण के लिए, अगर कोई सिस्टम अपडेट मिलता है, जिसमें ऐप्लिकेशन स्टोर से डाउनलोड किए गए APK से पुराना APK शामिल है, तो ऐप्लिकेशन स्टोर से डाउनलोड किए गए APK को ही बनाए रखा जाना चाहिए.

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

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

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

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

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

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

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

वर्शन का नाम, जानकारी को इस तरह से दिखाता है कि उसे कोई भी व्यक्ति आसानी से पढ़ सकता है. उदाहरण के लिए: major=001,minor=001,iana=2017a, revision=1,respin=2. उदाहरण के लिए, यहां दी गई टेबल देखें.

• पहले और दूसरे उदाहरण में, IANA के 2017a वर्शन के लिए दो APK वर्शन दिखाए गए हैं. इनमें फ़ॉर्मैट के अलग-अलग मेजर वर्शन हैं. 2, 1 से ज़्यादा है. इससे यह पक्का किया जा सकता है कि नए डिवाइसों को फ़ॉर्मैट के नए वर्शन मिलें. minSdkVersion यह पक्का करता है कि P वर्शन को O डिवाइसों पर उपलब्ध न कराया जाए.
• तीसरा उदाहरण, पहले उदाहरण का संशोधन/सुधार है और संख्या के हिसाब से पहले उदाहरण से ज़्यादा है.
• उदाहरण 4 और 5 में, O-MR1 और P के लिए 2017b रिलीज़ दिखाई गई हैं. इनके नंबर ज़्यादा होने की वजह से, ये अपने पूर्ववर्ती वर्शन की IANA रिलीज़/Android वर्शन की जगह ले लेते हैं.
• छठे और सातवें उदाहरण में, O-MR1 और P के लिए 2018a रिलीज़ दिखाई गई हैं.
• उदाहरण 8 में, Y=0 स्कीम को पूरी तरह से बदलने के लिए Y का इस्तेमाल दिखाया गया है.
• उदाहरण 9 में, एपीके को फिर से स्पिन करने के लिए, 3 और 4 के बीच छोड़े गए गैप का इस्तेमाल दिखाया गया है.

हर डिवाइस में सिस्टम इमेज के साथ, डिफ़ॉल्ट रूप से सही वर्शन वाला APK शामिल होता है. इसलिए, P डिवाइस पर O-MR1 वर्शन इंस्टॉल होने का कोई खतरा नहीं होता. ऐसा इसलिए, क्योंकि इसका वर्शन नंबर, P सिस्टम इमेज वर्शन से कम होता है. /data में O-MR1 वर्शन वाला डिवाइस, सिस्टम अपडेट के बाद P वर्शन का इस्तेमाल /system करता है. ऐसा इसलिए होता है, क्योंकि P वर्शन हमेशा O-MR1 वर्शन वाले किसी भी ऐप्लिकेशन से बेहतर होता है /data.

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

टाइम ज़ोन डेटा ऐप्लिकेशन के ज़्यादातर पहलुओं को मैनेज करने और सिस्टम इमेज को सही तरीके से कॉन्फ़िगर करने की ज़िम्मेदारी ओईएम की होती है. Data ऐप्लिकेशन को tapas बिल्ड के साथ बनाया जाना चाहिए. इससे ऐसे APK तैयार होते हैं जिन्हें सिस्टम इमेज (शुरुआती रिलीज़ के लिए) में जोड़ा जा सकता है. साथ ही, इन्हें ऐप्लिकेशन स्टोर के ज़रिए साइन और डिस्ट्रिब्यूट किया जा सकता है (बाद के अपडेट के लिए).

Tapas, Android बिल्ड सिस्टम का छोटा वर्शन है. यह सोर्स ट्री का इस्तेमाल करके, ऐप्लिकेशन के डिस्ट्रिब्यूट किए जा सकने वाले वर्शन बनाता है. जो OEM सामान्य एंड्रॉइड बिल्ड सिस्टम से परिचित हैं, उन्हें सामान्य एंड्रॉइड प्लेटफॉर्म बिल्ड से बिल्ड फाइलों को पहचानना चाहिए.

मैनिफेस्ट बनाएं

सोर्स ट्री को कम करने के लिए, आम तौर पर कस्टम मेनिफ़ेस्ट फ़ाइल का इस्तेमाल किया जाता है. यह फ़ाइल, सिर्फ़ उन Git प्रोजेक्ट को रेफ़र करती है जिनकी ज़रूरत बिल्ड सिस्टम को होती है और जिनकी मदद से ऐप्लिकेशन बनाया जाता है. डेटा ऐप्लिकेशन बनाना में दिए गए निर्देशों का पालन करने के बाद, ओईएम के पास कम से कम दो ओईएम-विशिष्ट Git प्रोजेक्ट होने चाहिए. ये प्रोजेक्ट, packages/apps/TimeZoneData/oem_template में मौजूद टेंप्लेट फ़ाइलों का इस्तेमाल करके बनाए जाने चाहिए:

• एक Git प्रोजेक्ट में ऐप फ़ाइलें होती हैं, जैसे कि मैनिफ़ेस्ट और ऐप APK फ़ाइल बनाने के लिए आवश्यक बिल्ड फ़ाइलें (उदाहरण के लिए, vendor/oem/apps/TimeZoneData). इस प्रोजेक्ट में टेस्ट APK के लिए बिल्ड नियम भी होते हैं जिनका उपयोग xTS टेस्ट द्वारा किया जा सकता है.
• एक Git प्रोजेक्ट में, ऐप्लिकेशन बिल्ड से जनरेट किए गए ऐसे हस्ताक्षरित APK शामिल होते हैं जिन्हें सिस्टम इमेज बिल्ड और xTS टेस्ट में शामिल किया जाता है.

ऐप्लिकेशन बिल्ड, कई अन्य Git प्रोजेक्ट का इस्तेमाल करता है. ये प्रोजेक्ट, प्लैटफ़ॉर्म बिल्ड के साथ शेयर किए जाते हैं या इनमें ओईएम से जुड़ी कोड लाइब्रेरी होती हैं.

यहां दिए गए मेनिफ़ेस्ट स्निपेट में, टाइम ज़ोन डेटा ऐप्लिकेशन के O-MR1 बिल्ड के लिए ज़रूरी Git प्रोजेक्ट का सबसे छोटा सेट शामिल है. ओईएम को इस मेनिफ़ेस्ट में, ओईएम के हिसाब से 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 बिल्ड को शुरू करें:

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

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