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

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

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

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

अपडेट करने के लिए, यह प्रोसेस अपनाई जाती है:

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

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

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

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

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

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

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

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

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

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

Android सिस्टम के जिन कॉम्पोनेंट को टाइम ज़ोन के नियम के डेटा की ज़रूरत होती है वे सबसे पहले इन जगहों पर डेटा की जाँच करते हैं:

  • libcore/ और bionic/ कोड, tzdata और tzlookup.xml फ़ाइलों की /data कॉपी का इस्तेमाल करते हैं.
  • ICU4J/ICU4C कोड, /data में मौजूद फ़ाइलों का इस्तेमाल करते हैं. साथ ही, जो डेटा मौजूद नहीं है उसके लिए /system फ़ाइलों का इस्तेमाल करते हैं. जैसे, फ़ॉर्मैट, स्थानीय भाषा में अनुवादित स्ट्रिंग वगैरह.

Distro फ़ाइलें

डिस्ट्रो .zip फ़ाइलों में, /data/misc/zoneinfo/current डायरेक्ट्री को भरने के लिए ज़रूरी डेटा फ़ाइलें होती हैं. डिस्ट्रो फ़ाइलों में ऐसा मेटाडेटा भी होता है जिससे डिवाइसों को वर्शन से जुड़ी समस्याओं का पता चलता है.

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

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

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

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

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

Distro installation

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

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

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

    पहली इमेज. ऐप्लिकेशन के डेटा से जुड़े अपडेट.

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

    अपडेट ट्रिगर करना

    दूसरी इमेज. अपडेट की जांच करने की सुविधा ट्रिगर करें.

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

      Call RulesManagerService

      तीसरी इमेज. डेटा ऐप्लिकेशन अपडेट, RulesManagerService को कॉल कर रहा है.

    • यह Data ऐप्लिकेशन से क्वेरी करता है. इसके लिए, यह ContentProvider के तय किए गए यूआरएल और कॉलम के स्पेसिफ़िकेशन से क्वेरी करता है, ताकि डिस्ट्रो के बारे में जानकारी मिल सके.

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

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

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

    जांच पूरी हुई

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

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

विश्वसनीयता

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

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

सुरक्षा

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

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

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

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

समय क्षेत्र अपडेट करने की सुविधा चालू करने के लिए, ओईएम आम तौर पर ये काम करते हैं:

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

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

शुरू करने से पहले, ओईएम को यहां दी गई नीति, क्वालिटी अश्योरेंस, और सुरक्षा से जुड़ी बातों की समीक्षा करनी चाहिए:

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

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

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

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

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

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

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

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

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

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

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

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

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

xTS टेस्टिंग

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

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

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

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

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

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

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

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

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

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

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

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

TIME_ZONE_DATA_APP_VERSION_CODE :=
TIME_ZONE_DATA_APP_VERSION_NAME :=

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

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

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

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

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

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

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

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

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

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

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

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

वर्शन की जांच करना

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

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

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

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

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

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

tapas का इस्तेमाल करके, Data ऐप्लिकेशन बनाना

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

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

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

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

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

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

यहां दिए गए मेनिफ़ेस्ट स्निपेट में, Git प्रोजेक्ट का वह सबसे छोटा सेट शामिल है जो टाइम ज़ोन डेटा ऐप्लिकेशन के O-MR1 बिल्ड के लिए ज़रूरी है. ओईएम को इस मेनिफ़ेस्ट में, ओईएम के हिसाब से Git प्रोजेक्ट जोड़ने होंगे. इनमें आम तौर पर, ऐसा प्रोजेक्ट शामिल होता है जिसमें हस्ताक्षर करने का सर्टिफ़िकेट होता है. साथ ही, वे इसके हिसाब से अलग-अलग ब्रांच कॉन्फ़िगर कर सकते हैं.

   <!-- Tapas Build -->
    <project
        path="build"
        name=">platform/<build"
        copyfile src="core/r>oot.m<k" >dest=<"Makefile" /
    /project
    project
        path="prebuilts/build-tools"
        name="pl>atfor<m/prebuilts/build-tools"
        clone-depth="1" /
    project
        path="prebuilts/go/linux-x8>6&quo<t;
        name="platform/prebuilts/go/linux-x86"
        clone-depth=>"<;1" /
    project
        path="build/blueprint"
      >  nam<e="platform/build/blueprint" /
    project
        path=&quo>t;build/k<ati"
        name="platform/buil>d/kati&qu<ot; /
    project
        path="build/soong">;
   <     nam>e=&quo<t;platform/build/soong"
        lin>kfile< src="root.bp" dest="Android.bp" /
        linkfile src="bootstrap.bash&quo>t; de<st="bootstra>p.bas<h" /
    /project

    !-- SDK for system / public API stubs --
    project>
    <    path="prebuilts/sdk"
        name="platform/prebuilts/sdk"
        clone-depth>=&quo<t;1" /
    !-- App> sour<ce --
    project
        path="system/timezone"
        name="platform/system/timezone" /
    project
     >   pa<th="packages/apps/TimeZoneData"
        name="platform/packages/apps/TimeZone>Data" /
    !-- Enable repohooks --
    project
        path="tools/repohooks"
        name="platform/tools/repohooks"
        revision="main"
        clone_depth="1" /
    repo-hooks
        in-project="platform/tools/repohooks"
        enabled-list="pre-upload" /

तपास बिल्ड को रन करें

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

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

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