समय क्षेत्र नियम

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

समय क्षेत्र अपडेट (एंड्रॉइड 10+)

एंड्रॉइड 10 और उच्चतर में समर्थित टाइम ज़ोन डेटा मॉड्यूल एंड्रॉइड डिवाइस पर डेलाइट सेविंग टाइम (डीएसटी) और टाइम ज़ोन को अपडेट करता है, डेटा को मानकीकृत करता है जो धार्मिक, राजनीतिक और भू-राजनीतिक कारणों से बार-बार बदल सकता है।

अद्यतन निम्नलिखित प्रक्रिया का उपयोग करते हैं:

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

मॉड्यूल पर विवरण के लिए, मॉड्यूलर सिस्टम घटक देखें।

समय क्षेत्र अपडेट (एंड्रॉइड 8.1-9)

नोट: एपीके-आधारित समय क्षेत्र डेटा अपडेट तंत्र सुविधा को एंड्रॉइड 14 के बाद से पूरी तरह से हटा दिया गया है और इसे स्रोत कोड में नहीं पाया जा सकता है। साझेदारों को पूरी तरह से टाइम ज़ोन मेनलाइन मॉड्यूल में स्थानांतरित हो जाना चाहिए।

एंड्रॉइड 8.1 और एंड्रॉइड 9 में, ओईएम सिस्टम अपडेट की आवश्यकता के बिना डिवाइस पर अपडेट किए गए समय क्षेत्र नियम डेटा को पुश करने के लिए एपीके-आधारित तंत्र का उपयोग कर सकते हैं। यह तंत्र उपयोगकर्ताओं को समय पर अपडेट प्राप्त करने में सक्षम बनाता है (इस प्रकार एंड्रॉइड डिवाइस के उपयोगी जीवनकाल को बढ़ाता है) और एंड्रॉइड भागीदारों को सिस्टम छवि अपडेट से स्वतंत्र रूप से समय क्षेत्र अपडेट का परीक्षण करने में सक्षम बनाता है।

एंड्रॉइड कोर लाइब्रेरी टीम स्टॉक एंड्रॉइड डिवाइस पर समय क्षेत्र नियमों को अपडेट करने के लिए आवश्यक डेटा फ़ाइलें प्रदान करती है। ओईएम अपने उपकरणों के लिए समय क्षेत्र अपडेट बनाते समय इन डेटा फ़ाइलों का उपयोग करना चुन सकते हैं या यदि चाहें तो अपनी स्वयं की डेटा फ़ाइलें बना सकते हैं। सभी मामलों में, ओईएम अपने समर्थित उपकरणों के लिए गुणवत्ता आश्वासन/परीक्षण, समय और समय क्षेत्र नियम अपडेट के लॉन्च पर नियंत्रण बनाए रखते हैं।

एंड्रॉइड समय क्षेत्र स्रोत कोड और डेटा

सभी स्टॉक एंड्रॉइड डिवाइस, यहां तक ​​कि जो इस सुविधा का उपयोग नहीं कर रहे हैं, उन्हें समय क्षेत्र नियम डेटा की आवश्यकता होती है और उन्हें /system विभाजन में समय क्षेत्र नियम डेटा के डिफ़ॉल्ट सेट के साथ शिप करना होगा। इस डेटा का उपयोग एंड्रॉइड स्रोत ट्री में निम्नलिखित पुस्तकालयों के कोड द्वारा किया जाता है:

  • libcore/ से प्रबंधित कोड (उदाहरण के लिए, java.util.TimeZone ) tzdata और tzlookup.xml फ़ाइलों का उपयोग करता है।
  • bionic/ में नेटिव लाइब्रेरी कोड (उदाहरण के लिए, mktime , लोकलटाइम सिस्टम कॉल के लिए) tzdata फ़ाइल का उपयोग करता है।
  • external/icu/ में आईसीयू4जे/आईसीयू4सी लाइब्रेरी कोड आईसीयू .dat फ़ाइल का उपयोग करता है।

ये लाइब्रेरीज़ उन ओवरले फ़ाइलों का ट्रैक रखती हैं जो /data/misc/zoneinfo/current निर्देशिका में मौजूद हो सकती हैं। ओवरले फ़ाइलों में बेहतर समय क्षेत्र नियम डेटा शामिल होने की उम्मीद है, जिससे /system को बदले बिना डिवाइस को अपडेट किया जा सकेगा।

एंड्रॉइड सिस्टम घटक जिन्हें समय क्षेत्र नियम डेटा की आवश्यकता होती है, वे पहले निम्नलिखित स्थानों की जांच करें:

  • libcore/ और bionic/ कोड tzdata और tzlookup.xml फ़ाइलों की /data कॉपी का उपयोग करते हैं।
  • आईसीयू4जे/आईसीयू4सी कोड /data में मौजूद फाइलों का उपयोग करता है और जो डेटा मौजूद नहीं है उसके लिए /system फाइलों पर वापस आ जाता है (प्रारूपों, स्थानीयकृत स्ट्रिंग्स आदि के लिए)।

डिस्ट्रो फ़ाइलें

डिस्ट्रो .zip फ़ाइलों में /data/misc/zoneinfo/current निर्देशिका को पॉप्युलेट करने के लिए आवश्यक डेटा फ़ाइलें होती हैं। डिस्ट्रो फ़ाइलों में मेटाडेटा भी होता है जो उपकरणों को संस्करण संबंधी समस्याओं का पता लगाने की अनुमति देता है।

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

समय क्षेत्र अद्यतन घटक

समय क्षेत्र नियम अद्यतन में एक डिवाइस में डिस्ट्रो फ़ाइलों का प्रसारण और उसके भीतर मौजूद फ़ाइलों की सुरक्षित स्थापना शामिल होती है। स्थानांतरण और स्थापना के लिए निम्नलिखित की आवश्यकता होती है:

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

एंड्रॉइड स्रोत ट्री में उपरोक्त घटकों के लिए सामान्य स्रोत कोड होता है, जिसे OEM बिना संशोधन के उपयोग करना चुन सकता है। ओईएम को स्वचालित रूप से यह जांचने में सक्षम करने के लिए परीक्षण कोड प्रदान किया जाता है कि उन्होंने सुविधा को सही ढंग से सक्षम किया है।

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

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

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

    डेटा ऐप अपडेट
    चित्र 1. डेटा ऐप अपडेट
  2. सिस्टम सर्वर प्रक्रिया अपडेटर ऐप पर एक अद्वितीय, एकल-उपयोग टोकन के साथ लक्षित इरादे को प्रसारित करके अपडेट जांच को ट्रिगर करती है । सिस्टम सर्वर अपने द्वारा उत्पन्न नवीनतम टोकन का ट्रैक रखता है ताकि यह निर्धारित कर सके कि उसके द्वारा ट्रिगर किया गया सबसे हालिया चेक कब पूरा हुआ है; किसी भी अन्य टोकन को नजरअंदाज कर दिया जाता है।

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

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

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

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

विश्वसनीयता

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

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

सुरक्षा

सक्षम होने पर, सिस्टम सर्वर में रूल्समैनेजर सर्विस कोड यह सुनिश्चित करने के लिए कई जांच करता है कि सिस्टम उपयोग करने के लिए सुरक्षित है।

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

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

समय क्षेत्र अद्यतनों को एकीकृत करना

समय क्षेत्र अद्यतन सुविधा को सक्षम करने के लिए, OEM आमतौर पर:

  • अपना स्वयं का डेटा ऐप बनाएं.
  • सिस्टम इमेज बिल्ड में अपडेटर और डेटा ऐप्स शामिल करें।
  • रूल्समैनेजर सर्विस को सक्षम करने के लिए सिस्टम सर्वर को कॉन्फ़िगर करें।

तैयार कर रहे हैं

शुरू करने से पहले, ओईएम को निम्नलिखित नीति, गुणवत्ता आश्वासन और सुरक्षा संबंधी विचारों की समीक्षा करनी चाहिए:

  • उनके डेटा ऐप के लिए एक समर्पित ऐप-विशिष्ट हस्ताक्षर कुंजी बनाएं।
  • यह समझने के लिए कि कौन से डिवाइस अपडेट किए जाने वाले हैं और वे यह कैसे सुनिश्चित कर सकते हैं कि अपडेट केवल उन डिवाइस पर इंस्टॉल किए जाएं जिन्हें उनकी आवश्यकता है, समय क्षेत्र अपडेट के लिए एक रिलीज और वर्जनिंग रणनीति बनाएं। उदाहरण के लिए, ओईएम अपने सभी डिवाइसों के लिए एक ही डेटा ऐप रखना चाह सकते हैं या अलग-अलग डिवाइसों के लिए अलग-अलग डेटा ऐप रखना चुन सकते हैं। निर्णय पैकेज नाम की पसंद, संभवतः उपयोग किए गए संस्करण कोड और क्यूए रणनीति को प्रभावित करता है।
  • समझें कि क्या वे AOSP से स्टॉक एंड्रॉइड टाइमज़ोन डेटा का उपयोग करना चाहते हैं या अपना स्वयं का डेटा बनाना चाहते हैं।

एक डेटा ऐप बनाना

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

ओईएम डेटा ऐप को अपने स्वयं के आइकन, नाम, अनुवाद और अन्य विवरणों के साथ अनुकूलित कर सकते हैं। हालाँकि, चूंकि डेटा ऐप लॉन्च नहीं किया जा सकता है, आइकन केवल सेटिंग्स > ऐप्स स्क्रीन में दिखाई देता है।

डेटा ऐप को एक टैपस बिल्ड के साथ बनाने का इरादा है जो सिस्टम छवि (प्रारंभिक रिलीज के लिए) में जोड़े जाने के लिए उपयुक्त एपीके तैयार करता है और ऐप स्टोर के माध्यम से हस्ताक्षरित और वितरित किया जाता है (बाद के अपडेट के लिए)। टैपस का उपयोग करने के विवरण के लिए, टैपस का उपयोग करके डेटा ऐप बनाना देखें।

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

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

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

अपडेटर ऐप को प्लेटफ़ॉर्म कुंजी के साथ हस्ताक्षरित किया जाना चाहिए और किसी अन्य सिस्टम ऐप के रूप में शामिल किया जाना चाहिए। लक्ष्य को packages/apps/TimeZoneUpdater में TimeZoneUpdater के रूप में परिभाषित किया गया है। डेटा ऐप समावेशन OEM-विशिष्ट है और प्रीबिल्ड के लिए चुने गए लक्ष्य नाम पर निर्भर करता है।

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

समय क्षेत्र अपडेट को सक्षम करने के लिए, ओईएम frameworks/base/core/res/res/values/config.xml में परिभाषित कॉन्फ़िगरेशन गुणों को ओवरराइड करके सिस्टम सर्वर को कॉन्फ़िगर कर सकते हैं।

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

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

एक्सटीएस परीक्षण

xTS किसी भी OEM-विशिष्ट परीक्षण सूट को संदर्भित करता है जो ट्रेडफेड (जैसे CTS और VTS) का उपयोग करने वाले मानक एंड्रॉइड परीक्षण सूट के समान है। जिन ओईएम के पास ऐसे परीक्षण सूट हैं, वे निम्नलिखित स्थानों पर प्रदान किए गए एंड्रॉइड टाइम ज़ोन अपडेट परीक्षण जोड़ सकते हैं:

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

समय क्षेत्र अपडेट बनाना

जब IANA समय क्षेत्र नियमों का एक नया सेट जारी करता है, तो एंड्रॉइड कोर लाइब्रेरी टीम AOSP में रिलीज़ को अपडेट करने के लिए पैच तैयार करती है। स्टॉक एंड्रॉइड सिस्टम और डिस्ट्रो फ़ाइलों का उपयोग करने वाले ओईएम इन कमिट्स को उठा सकते हैं, उनका उपयोग अपने डेटा ऐप का एक नया संस्करण बनाने के लिए कर सकते हैं, फिर उत्पादन में अपने उपकरणों को अपडेट करने के लिए नया संस्करण जारी कर सकते हैं।

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

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

इस चरण में, ओईएम एओएसपी में रिलीज -डेव शाखाओं से system/timezone और external/icu के लिए स्टॉक एंड्रॉइड कमिट लेते हैं और उन कमिट को एंड्रॉइड सोर्स कोड की अपनी कॉपी पर लागू करते हैं।

सिस्टम/टाइमज़ोन एओएसपी पैच में system/timezone/input_data और system/timezone/output_data में अद्यतन फ़ाइलें शामिल हैं। जिन OEM को अतिरिक्त स्थानीय सुधार करने की आवश्यकता है, वे इनपुट फ़ाइलों को संशोधित कर सकते हैं, फिर output_data में फ़ाइलें उत्पन्न करने के लिए system/timezone/input_data और external/icu में फ़ाइलों का उपयोग कर सकते हैं।

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

चरण 2: डेटा ऐप का संस्करण कोड अपडेट करना

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

package/apps/TimeZoneData/oem_template/data_app से कॉपी की गई फ़ाइलों का उपयोग करके डेटा ऐप बनाते समय, आप Android.mk में एपीके पर लागू संस्करण कोड/संस्करण नाम पा सकते हैं:

TIME_ZONE_DATA_APP_VERSION_CODE :=
TIME_ZONE_DATA_APP_VERSION_NAME :=

इसी तरह की प्रविष्टियाँ testing/Android.mk में पाई जा सकती हैं (हालाँकि, परीक्षण संस्करण कोड सिस्टम छवि संस्करण से अधिक होना चाहिए)। विवरण के लिए, उदाहरण संस्करण कोड रणनीति योजना देखें; यदि उदाहरण योजना या समान योजना का उपयोग किया जाता है, तो परीक्षण संस्करण कोड को अद्यतन करने की आवश्यकता नहीं है क्योंकि वे वास्तविक संस्करण कोड से अधिक होने की गारंटी देते हैं।

चरण 3: पुनर्निर्माण, हस्ताक्षर करना, परीक्षण करना और जारी करना

इस चरण में, OEM टैपस का उपयोग करके एपीके का पुनर्निर्माण करते हैं, जेनरेट किए गए एपीके पर हस्ताक्षर करते हैं, फिर एपीके का परीक्षण करते हैं और जारी करते हैं:

  • अप्रकाशित डिवाइसों के लिए (या किसी रिलीज़ किए गए डिवाइस के लिए सिस्टम अपडेट तैयार करते समय), डेटा ऐप प्रीबिल्ट डायरेक्टरी में नए एपीके सबमिट करें ताकि यह सुनिश्चित हो सके कि सिस्टम छवि और एक्सटीएस परीक्षणों में नवीनतम एपीके हैं। ओईएम को परीक्षण करना चाहिए कि नई फ़ाइल सही ढंग से काम करती है (अर्थात, यह सीटीएस और किसी भी ओईएम-विशिष्ट स्वचालित और मैन्युअल परीक्षण पास करती है)।
  • जारी किए गए डिवाइसों के लिए जो अब सिस्टम अपडेट प्राप्त नहीं करते हैं, हस्ताक्षरित एपीके केवल ऐप स्टोर के माध्यम से जारी किया जा सकता है।

ओईएम गुणवत्ता आश्वासन और रिलीज से पहले अपने उपकरणों पर अपडेटेड डेटा ऐप का परीक्षण करने के लिए जिम्मेदार हैं।

डेटा ऐप संस्करण कोड रणनीति

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

एपीके संस्करण कोड में निम्नलिखित जानकारी शामिल होनी चाहिए:

  • डिस्ट्रो प्रारूप संस्करण (प्रमुख + लघु)
  • एक वृद्धिशील (अपारदर्शी) संस्करण संख्या

वर्तमान में, प्लेटफ़ॉर्म एपीआई स्तर दृढ़ता से डिस्ट्रो प्रारूप संस्करण से संबंधित है क्योंकि प्रत्येक एपीआई स्तर आमतौर पर आईसीयू के एक नए संस्करण से जुड़ा होता है (जो डिस्ट्रो फ़ाइलों को असंगत बनाता है)। भविष्य में, एंड्रॉइड इसे बदल सकता है ताकि एक डिस्ट्रो फ़ाइल कई एंड्रॉइड प्लेटफ़ॉर्म रिलीज़ पर काम कर सके (और डेटा ऐप संस्करण कोड योजना में एपीआई स्तर का उपयोग नहीं किया जाता है)।

उदाहरण संस्करण कोड रणनीति

यह उदाहरण संस्करण संख्या योजना यह सुनिश्चित करती है कि उच्च डिस्ट्रो प्रारूप संस्करण निम्न डिस्ट्रो प्रारूप संस्करणों का स्थान ले लें। AndroidManifest.xml यह सुनिश्चित करने के लिए android:minSdkVersion उपयोग करता है कि पुराने डिवाइसों को उनकी क्षमता से अधिक डिस्ट्रो प्रारूप वाले संस्करण प्राप्त न हों।

संस्करण की जाँच करें
चित्र 6. उदाहरण संस्करण कोड रणनीति
उदाहरण कीमत उद्देश्य
वाई सुरक्षित भविष्य की वैकल्पिक योजनाओं/परीक्षण एपीके के लिए अनुमति देता है। यह प्रारंभ में (स्पष्ट रूप से) 0 है। क्योंकि अंतर्निहित प्रकार एक हस्ताक्षरित 32-बिट पूर्णांक प्रकार है, यह योजना भविष्य में दो नंबरिंग योजना संशोधनों का समर्थन करती है।
01 प्रमुख प्रारूप संस्करण 3 दशमलव अंक प्रमुख प्रारूप संस्करण को ट्रैक करता है। डिस्ट्रो प्रारूप 3 दशमलव अंकों का समर्थन करता है लेकिन यहां केवल 2 अंकों का उपयोग किया जाता है। प्रति एपीआई स्तर पर अपेक्षित बड़ी वृद्धि को देखते हुए इसके 100 तक पहुंचने की संभावना नहीं है। प्रमुख संस्करण 1 एपीआई स्तर 27 के बराबर है।
1 लघु प्रारूप संस्करण 3 दशमलव अंक लघु प्रारूप संस्करण को ट्रैक करता है। डिस्ट्रो प्रारूप 3 दशमलव अंकों का समर्थन करता है लेकिन यहां केवल 1 अंक का उपयोग किया जाता है। इसके 10 तक पहुंचने की संभावना नहीं है.
एक्स सुरक्षित उत्पादन रिलीज़ के लिए 0 है (और परीक्षण APK के लिए भिन्न हो सकता है)।
ZZZZZ अपारदर्शी संस्करण संख्या मांग पर दशमलव संख्या आवंटित की गई। यदि आवश्यक हो तो अंतरालीय अद्यतन करने की अनुमति देने के लिए अंतराल शामिल हैं।

यदि दशमलव के स्थान पर बाइनरी का उपयोग किया जाता तो योजना को बेहतर तरीके से पैक किया जा सकता था, लेकिन इस योजना में मानव-पठनीय होने का लाभ है। यदि पूर्ण संख्या सीमा समाप्त हो जाती है, तो डेटा ऐप पैकेज का नाम बदल सकता है।

संस्करण का नाम विवरण का मानव-पठनीय प्रतिनिधित्व है, उदाहरण के लिए: major=001,minor=001,iana=2017a, revision=1,respin=2 उदाहरण निम्न तालिका में दिखाए गए हैं.

# संस्करण कोड minSdkसंस्करण {प्रमुख प्रारूप संस्करण}, {लघु प्रारूप संस्करण}, {आईएएनए नियम संस्करण}, {संशोधन}
1 11000010 O-MR1 प्रमुख=001, लघु=001, ियाना=2017ए, संशोधन=1
2 21000010 पी प्रमुख=002, लघु=001, ियाना=2017ए, संशोधन=1
3 11000020 O-MR1 प्रमुख=001, लघु=001, ियाना=2017ए, संशोधन=2
4 11000030 O-MR1 प्रमुख=001, लघु=001, ियाना=2017बी, संशोधन=1
5 21000020 पी प्रमुख=002, लघु=001, ियाना=2017बी, संशोधन=1
6 11000040 O-MR1 प्रमुख=001, लघु=001, ियाना=2018ए, संशोधन=1
7 21000030 पी प्रमुख=002, लघु=001, ियाना=2018ए, संशोधन=1
8 1123456789 - -
9 11000021 O-MR1 प्रमुख=001, लघु=001, ियाना=2017ए, संशोधन=2, प्रतिक्रिया=2
  • उदाहरण 1 और 2 एक ही 2017ए आईएएनए रिलीज़ के लिए विभिन्न प्रमुख प्रारूप संस्करणों के साथ दो एपीके संस्करण दिखाते हैं। 2 संख्यात्मक रूप से 1 से अधिक है, जो यह सुनिश्चित करने के लिए आवश्यक है कि नए उपकरणों को उच्च प्रारूप संस्करण प्राप्त हों। MinSdkVersion सुनिश्चित करता है कि P संस्करण O डिवाइसों को आपूर्ति नहीं किया जाएगा।
  • उदाहरण 3, 1 के लिए एक संशोधन/समाधान है और संख्यात्मक रूप से 1 से अधिक है।
  • उदाहरण 4 और 5 ओ-एमआर1 और पी के लिए 2017बी रिलीज़ दिखाते हैं। संख्यात्मक रूप से अधिक होने के कारण, वे अपने संबंधित पूर्ववर्तियों के पूर्व आईएएनए रिलीज़/एंड्रॉइड संशोधनों को प्रतिस्थापित करते हैं।
  • उदाहरण 6 और 7 ओ-एमआर1 और पी के लिए 2018ए रिलीज़ दिखाते हैं।
  • उदाहरण 8 Y=0 योजना को पूरी तरह से बदलने के लिए Y के उपयोग को दर्शाता है।
  • उदाहरण 9 एपीके को फिर से स्पिन करने के लिए 3 और 4 के बीच छोड़े गए अंतर के उपयोग को दर्शाता है।

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

तपस का उपयोग करके डेटा ऐप का निर्माण

ओईएम समय क्षेत्र डेटा ऐप के अधिकांश पहलुओं को प्रबंधित करने और सिस्टम छवि को सही ढंग से कॉन्फ़िगर करने के लिए जिम्मेदार हैं। डेटा ऐप को एक टैपस बिल्ड के साथ बनाने का इरादा है जो सिस्टम छवि (प्रारंभिक रिलीज के लिए) में जोड़े जाने के लिए उपयुक्त एपीके तैयार करता है और ऐप स्टोर के माध्यम से हस्ताक्षरित और वितरित किया जाता है (बाद के अपडेट के लिए)।

तापस एंड्रॉइड बिल्ड सिस्टम का एक पतला-डाउन संस्करण है जो ऐप्स के वितरण योग्य संस्करण तैयार करने के लिए कम स्रोत ट्री का उपयोग करता है। सामान्य एंड्रॉइड बिल्ड सिस्टम से परिचित OEM को सामान्य एंड्रॉइड प्लेटफ़ॉर्म बिल्ड से बिल्ड फ़ाइलों को पहचानना चाहिए।

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

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

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

ऐप बिल्ड कई अन्य Git प्रोजेक्ट्स का लाभ उठाता है जो प्लेटफ़ॉर्म बिल्ड के साथ साझा किए जाते हैं या जिनमें OEM-स्वतंत्र कोड लाइब्रेरीज़ होती हैं।

निम्नलिखित मेनिफेस्ट स्निपेट में समय क्षेत्र डेटा ऐप के O-MR1 बिल्ड का समर्थन करने के लिए आवश्यक 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 डायरेक्टरी में फ़ाइलें उत्पन्न करता है। इन फ़ाइलों को सिस्टम छवि में शामिल करने के लिए प्रीबिल्ट्स निर्देशिका में रखा जा सकता है और/या संगत उपकरणों के लिए ऐप स्टोर के माध्यम से वितरित किया जा सकता है।