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

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 8.1–9)

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

Android 8.1 और Android 9 में, ओईएम 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 फ़ाइलों का इस्तेमाल करते हैं. जैसे, फ़ॉर्मैट, स्थानीय भाषा में अनुवादित स्ट्रिंग वगैरह.

Distro फ़ाइलें

डिस्ट्रो .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 ऐप्लिकेशन से क्वेरी करता है. इसके लिए, यह ContentProvider के तय किए गए यूआरएल और कॉलम के स्पेसिफ़िकेशन से क्वेरी करता है, ताकि डिस्ट्रो के बारे में जानकारी मिल सके.
     
     

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

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

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

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

विश्वसनीयता

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

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

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

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

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

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

Updater ऐप्लिकेशन पर प्लैटफ़ॉर्म की से साइन किया जाना चाहिए. साथ ही, इसे किसी अन्य सिस्टम ऐप्लिकेशन की तरह शामिल किया जाना चाहिए. टारगेट को 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 बनाते समय, अपने-आप शामिल हो जाती है.

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

इस चरण में, ओईएम, Data ऐप्लिकेशन के वर्शन कोड को अपडेट करते हैं. बिल्ड अपने-आप distro.zip को चुन लेता है. हालांकि, Data ऐप्लिकेशन के नए वर्शन का वर्शन कोड नया होना चाहिए, ताकि इसे नए ऐप्लिकेशन के तौर पर पहचाना जा सके. साथ ही, इसका इस्तेमाल पहले से लोड किए गए Data ऐप्लिकेशन या पिछले अपडेट के ज़रिए डिवाइस पर इंस्टॉल किए गए Data ऐप्लिकेशन को बदलने के लिए किया जा सके.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

वर्शन का नाम, जानकारी को इस तरह से दिखाता है कि उसे कोई भी व्यक्ति आसानी से पढ़ सकता है. उदाहरण के लिए: 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 वर्शन की जगह ले लेते हैं.
• उदाहरण 6 और 7 में, O-MR1 और P के लिए 2018a रिलीज़ दिखाई गई हैं.
• आठवें उदाहरण में, Y=0 स्कीम को पूरी तरह से बदलने के लिए Y का इस्तेमाल दिखाया गया है.
• उदाहरण 9 में, APK को फिर से स्पिन करने के लिए, 3 और 4 के बीच छोड़ी गई जगह का इस्तेमाल करने का तरीका दिखाया गया है.

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

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

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

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

मेनिफ़ेस्ट बनाना

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