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

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

समय क्षेत्र अपडेट (Android 10+)

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

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

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

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

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

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

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

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

Android समय क्षेत्र स्रोत कोड और डेटा

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

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

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

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

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

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

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

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

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

   

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

   

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

     

   • डिस्ट्रो के बारे में जानकारी प्राप्त करने के लिए एक अच्छी तरह से परिभाषित ContentProvider URL और कॉलम स्पेक्स को क्वेरी करके डेटा ऐप को क्वेरी करता है।
     
     

     

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

   

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

विश्वसनीयता

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

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

सुरक्षा

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

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

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

समय क्षेत्र अपडेट एकीकृत करना

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

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

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

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

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

डेटा ऐप बनाना

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

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

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

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

सिस्टम छवि में अपडेटर और डेटा ऐप्स सहित

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

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

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

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

config_enableUpdateableTimeZoneRules

config_timeZoneRulesUpdateTrackingEnabled

config_timeZoneRulesDataPackage

config_timeZoneRulesUpdaterPackage

config_timeZoneRulesCheckTimeMillisAllowed

config_timeZoneRulesCheckRetryCount

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

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

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

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

समय क्षेत्र अद्यतन बनाना

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

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

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

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

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

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

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

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

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

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

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

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

तपस का उपयोग करके डेटा ऐप बनाना

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

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

घोषणापत्र बनाना

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

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

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