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

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

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

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

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

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

मॉड्यूल पर जानकारी के लिए, मॉड्यूलर प्रणाली घटकों

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

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

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

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

सभी शेयर 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/ कोड का उपयोग /data की कॉपी tzdata और tzlookup.xml फ़ाइलें।
  • ICU4J / ICU4C कोड प्रयोग में फ़ाइलें /data और पीछे हटना /system डेटा जो मौजूद नहीं है के लिए फ़ाइलें (प्रारूपों, स्थानीय तार, आदि के लिए)।

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

विश्वसनीयता

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

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

सुरक्षा

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

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

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

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

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

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

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

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

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

डेटा ऐप बनाना

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

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

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

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

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

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

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

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

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

संपत्ति विवरण ओवरराइड की आवश्यकता है?
config_enableUpdateableTimeZoneRules
करने के लिए सेट किया जाना चाहिए true RulesManagerService सक्षम करने के लिए। हां
config_timeZoneRulesUpdateTrackingEnabled
करने के लिए सेट किया जाना चाहिए true प्रणाली के लिए डाटा एप्लिकेशन के परिवर्तन सुनता। हां
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 Tradefed की तरह कमरे में परीक्षण सहित के लिए एक नमूना निर्देशिका संरचना में शामिल है। अन्य टेम्प्लेट निर्देशिकाओं की तरह, ओईएम से अपेक्षा की जाती है कि वे अपनी आवश्यकताओं के अनुसार कॉपी और कस्टमाइज़ करें।
  • packages/apps/TimeZoneData/oem_template/data_app_prebuilt परीक्षण के लिए आवश्यक पहले से बने परीक्षण किए गए APK सहित के लिए निर्माण समय विन्यास में शामिल है।

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

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

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

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

इस चरण में, ओईएम के लिए शेयर एंड्रॉयड प्रतिबद्ध ले system/timezone और external/icu AOSP में रिलीज -dev शाखाओं से और 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 बनाया गया है जो स्वचालित रूप से शामिल है।

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

इस चरण में, ओईएम डेटा ऐप के वर्जन कोड को अपडेट करते हैं। निर्माण स्वचालित रूप से ऊपर उठाता है distro.zip , लेकिन डाटा एप्लिकेशन का नया संस्करण है, तो यह नए रूप में मान्यता प्राप्त है और पिछले अपडेट द्वारा एक पहले से लोड डाटा ऐप्लिकेशन या डाटा ऐप्स किसी डिवाइस पर स्थापित की जगह प्रयोग किया जाता है एक नया संस्करण कोड होना चाहिए।

जब से नकल फ़ाइलों का उपयोग कर डेटा एप्लिकेशन बनाने package/apps/TimeZoneData/oem_template/data_app , आप संस्करण कोड / संस्करण नाम पर APK के लिए आवेदन किया पा सकते हैं Android.mk :

TIME_ZONE_DATA_APP_VERSION_CODE :=
TIME_ZONE_DATA_APP_VERSION_NAME :=

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

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

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

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

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

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

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

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

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

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

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

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

संस्करण जांच
चित्रा 6. उदाहरण संस्करण कोड रणनीति
उदाहरण मूल्य प्रयोजन
यू सुरक्षित भविष्य की वैकल्पिक योजनाओं/परीक्षण APK के लिए अनुमति देता है। यह प्रारंभ में (निहित रूप से) 0 है। क्योंकि अंतर्निहित प्रकार एक हस्ताक्षरित 32-बिट int प्रकार है, यह योजना दो भावी क्रमांकन योजना संशोधनों का समर्थन करती है।
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 ११००००१० ओ-एमआर1 मेजर=001,माइनर=001,इयाना=2017ए,संशोधन=1
2 २१००००१० पी मेजर = 002, माइनर = 001, इयाना = 2017 ए, संशोधन = 1
3 ११००००२० ओ-एमआर1 मेजर=001,माइनर=001,इयाना=2017ए,संशोधन=2
4 ११००००३० ओ-एमआर1 मेजर=001,माइनर=001,इयाना=2017बी,संशोधन=1
5 २१००००२० पी मेजर = ००२, माइनर = ००१, इयाना = २०१७ बी, संशोधन = १
6 ११००००४० ओ-एमआर1 प्रमुख=001,मामूली=001,इयाना=2018a,संशोधन=1
7 २१००००३० पी मेजर = ००२, माइनर = ००१, इयाना = २०१८ ए, संशोधन = १
8 1123456789 - -
9 ११००००२१ ओ-एमआर1 मेजर=001,माइनर=001,इयाना=2017ए,संशोधन=2,रेस्पिन=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 है कि तब पी करने के लिए एक सिस्टम अपडेट प्राप्त करता है का उपयोग करता है /system में O-MR1 संस्करण के लिए वरीयता में संस्करण /data हमेशा उच्च किसी भी अनुप्रयोग O- के लिए इच्छित स्थान से है, क्योंकि पी संस्करण एमआर1.

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

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

तापस एक slimmed डाउन एंड्रॉयड निर्माण प्रणाली एक कम स्रोत पेड़ का उपयोग करता है क्षुधा के वितरण योग्य संस्करणों का निर्माण का संस्करण है। सामान्य एंड्रॉइड बिल्ड सिस्टम से परिचित ओईएम को सामान्य एंड्रॉइड प्लेटफॉर्म बिल्ड से बिल्ड फाइलों को पहचानना चाहिए।

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

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

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