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

Android 10, APK पर आधारित टाइम ज़ोन के डेटा का इस्तेमाल नहीं करता अपडेट करने का तरीका (Android 8.1 और Android 9 में उपलब्ध) और इसे इससे बदल देता है APEX पर आधारित मॉड्यूल अपडेट करने का तरीका. एओएसपी 8.1 से 13 में, वह प्लैटफ़ॉर्म कोड शामिल होता है जो ओईएम को चालू करने के लिए ज़रूरी है APK पर आधारित अपडेट. इसलिए, Android 10 में अपग्रेड किए जा रहे डिवाइस APK से पार्टनर से मिले टाइम ज़ोन के डेटा के अपडेट अब भी मिल सकते हैं. हालांकि, प्रोडक्शन डिवाइस पर APK अपडेट तकनीक का इस्तेमाल नहीं किया जाना चाहिए जिसे मॉड्यूल अपडेट के रूप में भी APK-आधारित अपडेट की जगह APEX-आधारित अपडेट (इसका मतलब है कि ऐसा डिवाइस जिसे APK का अपडेट मिला है उसे अनदेखा किया जाएगा APEX पर आधारित अपडेट).

टाइम ज़ोन से जुड़े अपडेट (Android 10 और उसके बाद वाले वर्शन के लिए)

Android 10 और Android 10 पर काम करने वाला टाइम ज़ोन डेटा मॉड्यूल Android डिवाइसों पर डेलाइट सेविंग टाइम (डीएसटी) और टाइम ज़ोन के बेहतर अपडेट मिलते हैं, यह ऐसे डेटा का आकलन करता है जो धार्मिक, राजनैतिक, और वजहें हैं.

अपडेट करने के लिए, यह तरीका अपनाएं:

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

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

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

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

Android 8.1 और Android 9 में, OEM टाइम ज़ोन के नियमों का डेटा, डिवाइसों पर अपडेट कर दिया गया है. इसके लिए, सिस्टम अपडेट की ज़रूरत भी नहीं है. यह तरीका उपयोगकर्ताओं को समय-समय पर अपडेट पाने में मदद करता है. इससे उपयोगी लाइफ़टाइम) और Android पार्टनर को टाइम ज़ोन, सिस्टम की इमेज में होने वाले अपडेट से अलग अपडेट होता है.

Android की कोर लाइब्रेरी टीम, Google Search Console के लिए ज़रूरी डेटा फ़ाइलें स्टॉक वाले Android डिवाइस पर टाइम ज़ोन के नियम अपडेट कर रही हूँ. OEM इनका इस्तेमाल कर सकते हैं समय क्षेत्र अपडेट बनाते समय डेटा फ़ाइलें बना सकते हैं या अपने अपनी डेटा फ़ाइलों का उपयोग करने की अनुमति दें. सभी मामलों में, क्वालिटी पर OEM का कंट्रोल होता है उनके लिए टाइम ज़ोन के नियमों में हुए अपडेट का आश्वासन/जांच करना, समय क्षेत्र से जुड़े अपडेट पाना, इस्तेमाल किए जा सकते हैं.

Android टाइम ज़ोन का सोर्स कोड और डेटा

सभी स्टॉक Android डिवाइसों को टाइम ज़ोन की ज़रूरत होती है. इनमें वे डिवाइस भी शामिल हैं जो इस सुविधा का इस्तेमाल नहीं कर रहे हैं नियमों का डेटा शामिल होता है और इसे समय क्षेत्र के नियमों के डिफ़ॉल्ट सेट के साथ शिप किया जाना चाहिए /system विभाजन. इसके बाद, इस डेटा का इस्तेमाल इन लाइब्रेरी का इस्तेमाल करें:

  • libcore/ से मैनेज किया जा रहा कोड (उदाहरण के लिए, java.util.TimeZone), tzdata और tzlookup.xml फ़ाइलें.
  • bionic/ में नेटिव लाइब्रेरी कोड (उदाहरण के लिए, mktime, लोकल-टाइम सिस्टम कॉल) 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, सभी उपयोगकर्ताओं और Android के साथ काम करने वाले रिलीज़ के लिए डिस्ट्रो फ़ाइलें उपलब्ध कराता है आईएएनए अपडेट (प्लैटफ़ॉर्म सिस्टम फ़ाइलों को अपडेट करने के अलावा). अपने डिवाइस अप-टू-डेट हैं, OEMs इन डिस्ट्रो फ़ाइलों को इस्तेमाल कर सकते हैं या Android सोर्स ट्री (जिसमें स्क्रिप्ट और अन्य फ़ाइलें होती हैं. डिस्ट्रो फ़ाइलें जनरेट करना शामिल है).

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

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

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

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

डिस्ट्रो इंस्टॉलेशन

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

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

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

    पहला डायग्राम. ऐप्लिकेशन के अपडेट का डेटा.

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

    ट्रिगर अपडेट

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

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

      नियम मैनेजर सेवा को कॉल करें

      तीसरी इमेज. डेटा ऐप्लिकेशन के अपडेट, RuleManagerService को कॉल करने की सुविधा.

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

      डिस्ट्रो की जानकारी पाएं

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

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

    जांच पूरी हुई

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

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

विश्वसनीयता

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

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

सुरक्षा

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

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

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

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

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

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

वीडियो की रणनीति

शुरू करने से पहले, OEM को इस नीति, क्वालिटी अश्योरेंस, और सुरक्षा से जुड़ी बातें:

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

Data ऐप्लिकेशन बनाना

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

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

Data ऐप्लिकेशन को टैप बिल्ड की मदद से बनाया गया हो जो ऐसे APK बनाती है जो सिस्टम इमेज में जोड़े जाने के लिए सही होते हैं ( रिलीज़) और इस पर हस्ताक्षर करके, उसे ऐप स्टोर से डिस्ट्रिब्यूट किया जाएगा (बाद में इस्तेमाल करने के लिए) अपडेट). तपस का उपयोग करने के बारे में विवरण के लिए, बिल्डिंग में टापस का इस्तेमाल करने वाला डेटा ऐप्लिकेशन.

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

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

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

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

सिस्टम सर्वर कॉन्फ़िगर करें

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

प्रॉपर्टी ब्यौरा क्या ओवरराइड करना ज़रूरी है? 
config_enableUpdateableTimeZoneRules
 नियम मैनेजर सेवा चालू करने के लिए, true पर सेट होना चाहिए. हां 
config_timeZoneRulesUpdateTrackingEnabled
 true पर सेट होना चाहिए, ताकि सिस्टम बदलाव को सुन सके Data ऐप्लिकेशन. हां 
config_timeZoneRulesDataPackage
 OEM के लिए बने डेटा ऐप्लिकेशन का पैकेज नाम. हां 
config_timeZoneRulesUpdaterPackage
 डिफ़ॉल्ट Updater ऐप्लिकेशन के लिए कॉन्फ़िगर किया गया. केवल तभी बदलें, जब अपडेटर ऐप्लिकेशन को अलग-अलग तरीके से लागू करना. नहीं 
config_timeZoneRulesCheckTimeMillisAllowed
 अपडेट की जांच के बीच लगने वाला समय, EssentialsManagerService को इंस्टॉल, अनइंस्टॉल या कुछ न करने का जवाब दिया जाता है. इस तारीख के बाद ऐसा होने पर, अपने-आप भरोसेमंद होने का ट्रिगर जनरेट हो सकता है. नहीं 
config_timeZoneRulesCheckRetryCount
 क्रम में होने वाली असफल अपडेट की जांचों की संख्या: नियम मैनेजर सेवा और जनरेट करना बंद कर देती है. नहीं

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

एक्सटीएस टेस्टिंग

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

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

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

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

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

पहला चरण: सिस्टम/टाइमज़ोन और External/icu डेटा फ़ाइलों को अपडेट करना

इस चरण में, OEM system/timezone और external/icu एओएसपी में डेव की ब्रांच रिलीज़ करें और उन लाइसेंस की कॉपी को Android सोर्स कोड के बारे में ज़्यादा जानें.

सिस्टम/टाइमज़ोन AOSP पैच में अपडेट की गई फ़ाइलें system/timezone/input_data और system/timezone/output_data. ऐसे OEM जिन्हें अतिरिक्त स्थानीय इन्वेंट्री की ज़रूरत होती है फ़िक्सेस इनपुट फ़ाइलों में बदलाव कर सकते हैं, फिर फ़ाइलों का system/timezone/input_data और external/icu को output_data में फ़ाइलें जनरेट करें.

सबसे महत्वपूर्ण फ़ाइल है system/timezone/output_data/distro/distro.zip, जो कि डेटा ऐप्लिकेशन APK के बनने पर, अपने-आप शामिल हो जाता है.

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

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

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

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

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

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

अपडेट किए गए अपडेट की क्वालिटी की जांच और क्वालिटी की जांच करने की ज़िम्मेदारी OEM की है डेटा ऐप्लिकेशन को रिलीज़ से पहले अपने डिवाइसों पर इंस्टॉल करना होगा.

डेटा ऐप्लिकेशन वर्शन कोड की रणनीति

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

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

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

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

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

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

वर्शन की जांच

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

उदाहरण वैल्यू मकसद
हां बुक किया हुआ यह नीति, आने वाले समय में लागू होने वाली वैकल्पिक स्कीम/टेस्ट APKs को अनुमति देती है. यह शुरुआत में है (इसका मतलब है कि 0. दिया गया टाइप, साइन किया हुआ 32-बिट इंंट टाइप है, इसलिए यह स्कीम भविष्य में नंबरिंग स्कीम में अधिकतम दो संशोधन.
01 मेजर फ़ॉर्मैट वर्शन यह दशमलव अंकों वाले मेजर फ़ॉर्मैट वर्शन को ट्रैक करता है. डिस्ट्रो फ़ॉर्मैट यहां दशमलव के बाद तीन अंक इस्तेमाल किए गए हैं. हालांकि, इसमें सिर्फ़ दो अंकों का इस्तेमाल किया गया है. इसके 100 तक पहुंचने की संभावना नहीं है एपीआई लेवल के हिसाब से अनुमानित बढ़ोतरी देखी गई. मेजर वर्शन 1, इसके बराबर है एपीआई लेवल 27 तक सीमित नहीं है.
1 माइनर फ़ॉर्मैट वर्शन यह दशमलव के तीन अंकों वाले माइनर फ़ॉर्मैट वर्शन को ट्रैक करता है. डिस्ट्रो फ़ॉर्मैट इसमें तीन दशमलव अंक होते हैं. हालांकि, यहां सिर्फ़ एक अंक का इस्तेमाल किया जाता है. इसके 10 तक पहुंचने की संभावना नहीं है.
X बुक किया हुआ प्रोडक्शन रिलीज़ के लिए 0 होता है (और यह टेस्ट APK के लिए अलग हो सकता है).
ज़ीज़ेडज़ेड ओपेक वर्शन नंबर मांग पर तय की गई दशमलव संख्या. इसमें, पेज पर अचानक दिखने वाले विज्ञापनों को दिखाने की अनुमति नहीं है ज़रूरत पड़ने पर, इन्हें अपडेट किया जा सकता है.

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

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

# वर्शन का कोड minSdkVersion {Major Format version},{माइनर फ़ॉर्मैट वर्शन},{आईएएनए के नियम version},{Revision}
1 11000010 ओ-एमआर1 मेजर=001,माइनर=001,इयाना=2017a,बदलाव=1
2 21000010 P मेजर=002,माइनर=001,इयाना=2017a,बदलाव=1
3 11000020 ओ-एमआर1 मेजर=001,माइनर=001,इयाना=2017a,बदलाव=2
4 11000030 ओ-एमआर1 मेजर=001,माइनर=001,इयाना=2017b,रिविज़न=1
5 21000020 P मेजर=002,माइनर=001,इयाना=2017b,रिविज़न=1
6 11000040 ओ-एमआर1 मेजर=001,माइनर=001,इयाना=2018a,रिविज़न=1
7 21000030 P मेजर=002,माइनर=001,इयाना=2018a,रिविज़न=1
8 1123456789 - -
9 11000021 ओ-एमआर1 मुख्य=001,minor=001,iana=2017a,revision=2,respin=2
  • उदाहरण 1 और 2 में, 2017 की एक ही IANA रिलीज़ के लिए दो APK वर्शन दिखाए गए हैं जिसमें अलग-अलग मुख्य फ़ॉर्मैट के वर्शन हैं. संख्या के हिसाब से 2, 1 से ज़्यादा होता है, जो कि यह पक्का करना ज़रूरी है कि नए डिवाइसों को बेहतर फ़ॉर्मैट वाले वर्शन मिलें. कॉन्टेंट बनाने minSdkVersion यह पक्का करता है कि O डिवाइसों को P वर्शन न दिया जाए.
  • तीसरा उदाहरण 1 की वैल्यू में बदलाव/सुधार करना है और संख्या के हिसाब से एक से ज़्यादा है.
  • उदाहरण 4 और 5 में O-MR1 और P के लिए 2017b की रिलीज़ के बारे में बताया गया है. अंकों के हिसाब से वे IANA की पिछली रिलीज़/Android के वर्शन में किए गए बदलावों को बदल देते हैं. पूर्वज.
  • उदाहरण 6 और 7 में O-MR1 और P के लिए 2018a की रिलीज़ दिखाए गए हैं.
  • उदाहरण 8 में, Y=0 स्कीम को पूरी तरह से बदलने के लिए Y का इस्तेमाल करने का तरीका बताया गया है.
  • उदाहरण 9 में, 3 और 4 के बीच के बचे हुए अंतर को री-स्पिन करने के तरीके के बारे में बताया गया है apk.

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

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

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

तपस, Android बिल्ड का एक स्लिम-डाउन वर्शन है एक ऐसा सिस्टम है जो कम सोर्स ट्री का इस्तेमाल करके, दिखाई देता है. Android के लिए सामान्य बिल्ड सिस्टम की जानकारी रखने वाले OEM को सामान्य Android प्लैटफ़ॉर्म बिल्ड से फ़ाइलें बनाने में मदद करता है.

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

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

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

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

नीचे दिए गए मेनिफ़ेस्ट स्निपेट में Git प्रोजेक्ट का कम से कम सेट शामिल है को टाइम ज़ोन वाले डेटा ऐप्लिकेशन के O-MR1 बिल्ड की सुविधा का इस्तेमाल करना ज़रूरी है. 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" />

टापस बिल्ड का इस्तेमाल करें

सोर्स ट्री इंस्टॉल होने के बाद, तपस बिल्ड को शुरू करें ऐसा करने के लिए यहाँ दिए गए निर्देशों का पालन करें:

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

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