फ़्लैश मेमोरी के इस्तेमाल को मॉनिटर करना

वॉचडॉग, सभी ऐप्लिकेशन और सेवाओं के डिस्क I/O लिखने की कुल संख्या को ट्रैक करके, फ़्लैश मेमोरी के इस्तेमाल पर नज़र रखता है. इसके लिए, वह `/proc/uid_io/stats` में मौजूद, हर यूआईडी के लिए डिस्क I/O के आंकड़ों का इस्तेमाल करता है. जब कोई ऐप्लिकेशन या सेवा, डिस्क I/O के इस्तेमाल की सीमा से ज़्यादा इस्तेमाल करती है, तो वॉचडॉग उस ऐप्लिकेशन या सेवा पर कार्रवाई करता है. डिस्क I/O के ज़्यादा इस्तेमाल से जुड़े थ्रेशोल्ड और ज़्यादा इस्तेमाल होने पर की जाने वाली कार्रवाई, डिस्क I/O के ज़्यादा इस्तेमाल से जुड़े कॉन्फ़िगरेशन में पहले से तय होती है.

बहुत ज़्यादा इस्तेमाल करने से जुड़े थ्रेशोल्ड

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

ज़रूरत से ज़्यादा इस्तेमाल करने से जुड़ी कार्रवाइयां

जब कोई ऐप्लिकेशन, डिस्क के I/O के ज़्यादा इस्तेमाल के लिए तय किए गए थ्रेशोल्ड को बार-बार पार करता है, तो वॉचडॉग, ज़्यादा इस्तेमाल के कॉन्फ़िगरेशन में बताई गई कार्रवाइयां करता है.

  • सभी वेंडर ऐप्लिकेशन और सेवाओं को सिस्टम के स्थिर रहने के लिए ज़रूरी माना जाता है. इसलिए, डिस्क के I/O के ज़्यादा इस्तेमाल पर इन्हें बंद नहीं किया जाता. हालांकि, ज़रूरत से ज़्यादा इस्तेमाल करने से, वेंडर ऐप्लिकेशन और सेवाओं को खत्म करने के लिए सुरक्षित की सूची तय हो सकती है.
  • तीसरे पक्ष के सभी ऐप्लिकेशन को बंद करना सुरक्षित रहता है.

जब किसी ऐप्लिकेशन या सेवा को खत्म करना सुरक्षित होता है, तो वॉचडॉग उस ऐप्लिकेशन या सेवा को बंद कर देता है जिसकी ऐप्लिकेशन कॉम्पोनेंट स्थिति PackageManager.COMPONENT_ENABLED_STATE_DISABLED_UNTIL_USED होती है.

कॉन्फ़िगरेशन का ज़रूरत से ज़्यादा इस्तेमाल करना

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

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

कॉन्फ़िगरेशन के गलत इस्तेमाल की परिभाषा

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

वेंडर कॉन्फ़िगरेशन

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

  • वेंडर पैकेज के प्रीफ़िक्स. वेंडर सेगमेंट में इंस्टॉल किए गए सभी पैकेज को वेंडर पैकेज माना जाता है. इनके अलावा, वेंडर पहले से इंस्टॉल किए गए पैकेज को वेंडर पैकेज के तौर पर भी बांट सकते हैं. इसके लिए, उन्हें वेंडर पैकेज के प्रीफ़िक्स कॉन्फ़िगरेशन में पैकेज के प्रीफ़िक्स जोड़ने होंगे. यह कॉन्फ़िगरेशन, रेगुलर एक्सप्रेशन स्वीकार नहीं करता.
  • पैकेज खत्म करना सुरक्षित है. वेंडर यह तय कर सकते हैं कि किन वेंडर पैकेज को बंद किया जा सकता है. इसके लिए, वे safe-to-terminate packages कॉन्फ़िगरेशन में, पैकेज के पूरे नाम जोड़ सकते हैं.
  • ऐप्लिकेशन कैटगरी मैपिंग. वेंडर किसी भी पैकेज (तीसरे पक्ष के पैकेज के साथ) को, इस्तेमाल किए जा सकने वाले दो ऐप्लिकेशन कैटगरी - मैप और मीडिया ऐप्लिकेशन में से मैप कर सकते हैं. यह मैपिंग, Maps और मीडिया ऐप्लिकेशन के लिए डिस्क के I/O के ज़्यादा इस्तेमाल के थ्रेशोल्ड तय करने के लिए की जाती है. ऐसा इसलिए किया जाता है, क्योंकि ये ऐप्लिकेशन, अन्य ऐप्लिकेशन के मुकाबले ज़्यादा डेटा डाउनलोड करते हैं और डिस्क में ज़्यादा डेटा सेव करते हैं.
  • कॉम्पोनेंट लेवल के थ्रेशोल्ड. सभी वेंडर पैकेज के लिए सामान्य थ्रेशोल्ड तय करता है. इसका मतलब है कि पैकेज के हिसाब से तय किए गए थ्रेशोल्ड या ऐप्लिकेशन कैटगरी के हिसाब से तय किए गए थ्रेशोल्ड में शामिल नहीं किए गए पैकेज के लिए, ये थ्रेशोल्ड लागू होते हैं. डिस्क के I/O के ज़्यादा इस्तेमाल से जुड़े कॉन्फ़िगरेशन तय करते समय, वेंडर को कॉम्पोनेंट-लेवल के थ्रेशोल्ड तय करने होंगे. ये थ्रेशोल्ड शून्य से ज़्यादा होने चाहिए.
  • पैकेज से जुड़े खास थ्रेशोल्ड. वेंडर किसी खास वेंडर पैकेज के लिए, खास थ्रेशोल्ड तय कर सकते हैं. मैपिंग में, पैकेज के पूरे नाम शामिल होने चाहिए. इस कॉन्फ़िगरेशन में तय किए गए थ्रेशोल्ड को, किसी दिए गए पैकेज के लिए, अन्य कॉन्फ़िगरेशन में तय किए गए थ्रेशोल्ड के मुकाबले ज़्यादा अहमियत दी जाती है.
  • ऐप्लिकेशन की कैटगरी के लिए थ्रेशोल्ड. वेंडर, ऐप्लिकेशन की खास कैटगरी के लिए, खास थ्रेशोल्ड तय कर सकते हैं. ऐप्लिकेशन की कैटगरी, इस्तेमाल की जा सकने वाली कैटगरी में से एक होनी चाहिए - Maps और मीडिया ऐप्लिकेशन. इस कॉन्फ़िगरेशन में तय किए गए थ्रेशोल्ड, ऐप्लिकेशन कैटगरी मैपिंग का इस्तेमाल करके, खास पैकेज पर मैप किए जाते हैं.
  • सिस्टम के लिए थ्रेशोल्ड. वेंडर को इस कॉन्फ़िगरेशन की जानकारी नहीं देनी चाहिए.

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

ज़्यादा इस्तेमाल की थ्रेशोल्ड में, इन दौरान लिखे जाने वाले बाइट की संख्या शामिल होती है:

  • ऐप्लिकेशन या सेवा के लिए फ़ोरग्राउंड मोड और बैकग्राउंड मोड
  • सिस्टम गैरेज मोड

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

सिस्टम और तीसरे पक्ष के कॉन्फ़िगरेशन

OEM को सिस्टम और तीसरे पक्ष के कॉन्फ़िगरेशन नहीं अपडेट करने चाहिए.

  • सिस्टम कॉन्फ़िगरेशन की मदद से, यह तय किया जाता है कि सिस्टम के ऐप्लिकेशन और सेवाओं के लिए, I/O से जुड़े थ्रेशोल्ड और कार्रवाइयां क्या होंगी.
    • इस कॉन्फ़िगरेशन से, ऐप्लिकेशन कैटगरी मैपिंग भी अपडेट की जा सकती हैं. इसलिए, यह कॉन्फ़िगरेशन फ़ील्ड, सिस्टम और वेंडर के कॉन्फ़िगरेशन के बीच शेयर किया जाता है.
  • तीसरे पक्ष के कॉन्फ़िगरेशन से, तीसरे पक्ष के सभी ऐप्लिकेशन के लिए थ्रेशोल्ड तय होते हैं. सिस्टम में पहले से इंस्टॉल नहीं किए गए सभी ऐप्लिकेशन, तीसरे पक्ष के ऐप्लिकेशन होते हैं.
    • तीसरे पक्ष के सभी ऐप्लिकेशन को एक ही थ्रेशोल्ड मिलता है. उदाहरण के लिए, तीसरे पक्ष के किसी भी ऐप्लिकेशन को खास थ्रेशोल्ड नहीं मिलता. हालांकि, मैप और मीडिया ऐप्लिकेशन के लिए थ्रेशोल्ड, वेंडर कॉन्फ़िगरेशन के हिसाब से तय किए जाते हैं.
    • डिस्क के I/O के गलत इस्तेमाल की सीमा के लिए, यहां दिए गए थ्रेशोल्ड डिफ़ॉल्ट रूप से लागू होते हैं. ये थ्रेशोल्ड, तीसरे पक्ष के ऐप्लिकेशन के लिए होते हैं. ये थ्रेशोल्ड, सिस्टम इमेज के साथ शिप किए जाते हैं.
      • ऐप्लिकेशन के फ़ोरग्राउंड मोड में 3 गीबी डेटा लिखने की अनुमति.
      • ऐप्लिकेशन के बैकग्राउंड मोड में 2 गीबी लिखने की सुविधा.
      • सिस्टम गैरेज मोड में 4 गीबी लिखें.
    • ये बुनियादी थ्रेशोल्ड हैं. डिस्क के I/O इस्तेमाल के बारे में ज़्यादा जानकारी मिलने पर, ये थ्रेशोल्ड अपडेट हो जाते हैं.

कॉन्फ़िगरेशन एक्सएमएल फ़ॉर्मैट का ज़रूरत से ज़्यादा इस्तेमाल करना

डिफ़ॉल्ट वेंडर कॉन्फ़िगरेशन को बिल्ड इमेज में /vendor/etc/automotive/watchdog/resource_overuse_configuration.xml वाली जगह पर रखा जा सकता है. हालांकि, ऐसा करना ज़रूरी नहीं है. अगर इस कॉन्फ़िगरेशन की जानकारी नहीं दी जाती है, तो वेंडर के ऐप्लिकेशन और सेवाओं के लिए भी, सिस्टम से तय किया गया कॉन्फ़िगरेशन लागू होता है.

एक्सएमएल फ़ाइल में हर कॉन्फ़िगरेशन फ़ील्ड के लिए सिर्फ़ एक टैग होना चाहिए. एक्सएमएल फ़ाइल में, I/O के ज़्यादा इस्तेमाल से जुड़ा कॉन्फ़िगरेशन तय करना ज़रूरी है. थ्रेशोल्ड की सभी वैल्यू, एमबी यूनिट में बताई जानी चाहिए.

एक्सएमएल कॉन्फ़िगरेशन का सैंपल यहां दिया गया है:

<resourceOveruseConfiguration version="1.0">
      <componentType> VENDOR </componentType>

      <!-- List of safe to kill vendor packages. -->
      <safeToKillPackages>
            <package> com.vendor.package.A </package>
            <package> com.vendor.package.B </package>
      </safeToKillPackages>

      <!-- List of vendor package prefixes. -->
      <vendorPackagePrefixes>
            <packagePrefix> com.vendor.package </packagePrefix>
      </vendorPackagePrefixes>

      <!-- List of unique package names to app category mappings. -->
      <packagesToAppCategoryTypes>
            <packageAppCategory type="MEDIA"> com.vendor.package.A </packageAppCategory>
            <packageAppCategory type="MAPS"> com.google.package.B </packageAppCategory>
            <packageAppCategory type="MEDIA"> com.third.party.package.C </packageAppCategory>
      </packagesToAppCategoryTypes>

      <ioOveruseConfiguration>
        <!-- Thresholds in MiB for all vendor packages that don't have package specific thresholds. -->
            <componentLevelThresholds>
                  <state id="foreground_mode"> 1024 </state>
                  <state id="background_mode"> 512 </state>
                  <state id="garage_mode"> 3072 </state>
            </componentLevelThresholds>

            <packageSpecificThresholds>
                  <!-- IDs must be unique -->
                  <perStateThreshold id="com.vendor.package.C">
                    <state id="foreground_mode"> 400 </state>
                    <state id="background_mode"> 100 </state>
                    <state id="garage_mode"> 200 </state>
                  </perStateThreshold>

                  <perStateThreshold id="com.vendor.package.D">
                    <state id="foreground_mode"> 1024 </state>
                    <state id="background_mode"> 500 </state>
                    <state id="garage_mode"> 2048 </state>
                  </perStateThreshold>
            </packageSpecificThresholds>

            <!-- Application category specific thresholds. -->
            <appCategorySpecificThresholds>
                  <!-- One entry per supported application category -->
                  <perStateThreshold id="MEDIA">
                    <state id="foreground_mode"> 600 </state>
                    <state id="background_mode"> 700 </state>
                    <state id="garage_mode"> 1024 </state>
                  </perStateThreshold>

                  <perStateThreshold id="MAPS">
                    <state id="foreground_mode"> 800 </state>
                    <state id="background_mode"> 900 </state>
                    <state id="garage_mode"> 2048 </state>
                  </perStateThreshold>
            </appCategorySpecificThresholds>
      </ioOveruseConfiguration>
</resourceOveruseConfiguration>

CarWatchDoManager सिस्टम एपीआई की मदद से, ज़रूरत से ज़्यादा इस्तेमाल किए जाने वाले कॉन्फ़िगरेशन को अपडेट करें

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

  • कॉल करने वाले को Car.PERMISSION_CONTROL_CAR_WATCHDOG_CONFIG की अनुमति दें.
  • नए कॉन्फ़िगरेशन को अपडेट करने और सेट करने के लिए, मौजूदा कॉन्फ़िगरेशन का इस्तेमाल करना होगा. मौजूदा कॉन्फ़िगरेशन पाने के लिए, API CarWatchdogManager.getResourceOveruseConfigurations का इस्तेमाल करें. अगर मौजूदा कॉन्फ़िगरेशन का इस्तेमाल नहीं किया गया है, तो सभी कॉन्फ़िगरेशन ओवरराइट हो जाते हैं. इनमें सिस्टम और तीसरे पक्ष के कॉन्फ़िगरेशन शामिल हैं. हालांकि, हमारा सुझाव है कि ऐसा न करें.
  • डेल्टा बदलावों के साथ मौजूदा कॉन्फ़िगरेशन अपडेट करें और नए कॉन्फ़िगरेशन सेट करें. सिस्टम और तीसरे पक्ष के कॉम्पोनेंट के कॉन्फ़िगरेशन न अपडेट करें.
  • नए कॉन्फ़िगरेशन सेट करने के लिए, एपीआई CarWatchdogManager.setResourceOveruseConfigurations का इस्तेमाल करें.
  • डिस्क के I/O के ज़्यादा इस्तेमाल से जुड़े कॉन्फ़िगरेशन पाने और उन्हें सेट करने के लिए, फ़्लैग का इस्तेमाल करें CarWatchdogManager.FLAG_RESOURCE_OVERUSE_IO.

यहां संसाधन के ज़्यादा इस्तेमाल से जुड़े कॉन्फ़िगरेशन को अपडेट करने का एक सैंपल दिया गया है:

void updateResourceOveruseConfigurations() {
    CarWatchdogManager manager =
        (CarWatchdogManager) car.getCarManager(Car.CAR_WATCHDOG_SERVICE);

    List<ResourceOveruseConfiguration> resourceOveruseConfigurations =
        manager.getResourceOveruseConfigurations(
            CarWatchdogManager.FLAG_RESOURCE_OVERUSE_IO);

    List<ResourceOveruseConfiguration> newResourceOveruseConfigurations =
            new List<>();
    ResourceOveruseConfiguration vendorConfiguration;
    for(ResourceOveruseConfiguration config : resourceOveruseConfigurations) {
        // Do not update the configurations of the system and third-party component types.
        if (config.getComponentType()
            != ResourceOveruseConfiguration.COMPONENT_TYPE_VENDOR) {
            newResourceOveruseConfigurations.add(config);
            continue;
        }
        vendorConfiguration = config;
    }

    if (vendorConfiguration == null) {
        ResourceOveruseConfiguration.Builder vendorConfigBuilder =
            new ResourceOveruseConfiguration.Builder();
        initializeConfig(vendorConfigBuilder);
        newResourceOveruseConfigurations.add(vendorConfigBuilder.build());
    } else {
        ResourceOveruseConfiguration newVendorConfig =
            updateConfig(vendorConfiguration);
        newResourceOveruseConfigurations.add(newVendorConfig);
    }
    int result = manager.setResourceOveruseConfigurations(
        newResourceOveruseConfigurations,

    if (result != CarWatchdogManager.RETURN_CODE_SUCCESS) {
        // Failed to set the resource overuse configurations.
    }
}

/** Sets the delta between the old configuration and the new configuration. */
ResourceOveruseConfiguration updateConfig(
    ResourceOveruseConfiguration oldConfiguration) {
    // Replace com.vendor.package.A with com.vendor.package.B in the safe-to-kill list.
    List<String> safeToKillPackages = oldConfiguration.getSafeToKillPackages();
    safeToKillPackages.remove("com.vendor.package.A");
    safeToKillPackages.add("com.vendor.package.B");

    ResourceOveruseConfiguration.Builder configBuilder =
        new ResourceOveruseConfiguration.Builder(
            oldConfiguration.getComponentType(),
            safeToKillPackages,
            oldConfiguration.getVendorPackagePrefixes(),
            oldConfiguration.getPackagesToAppCategoryTypes());

    configBuilder.addVendorPackagePrefixes("com.vendor.");
    configBuilder.addPackagesToAppCategoryTypes("com.vendor.package.B",
        ResourceOveruseConfiguration.APPLICATION_CATEGORY_TYPE_MAPS);

    IoOveruseConfiguration oldIoConfiguration = oldConfiguration.getIoOveruseConfiguration();
    IoOveruseConfiguration.Builder ioConfigBuilder =
        new IoOveruseConfiguration.Builder(
            oldIoConfiguration.getComponentLevelThresholds(),
            oldIoConfiguration.getPackageSpecificThresholds(),
            oldIoConfiguration.getAppCategorySpecificThresholds(),
            oldIoConfiguration.getSystemWideThresholds());

    // Define the amount of bytes based on the flash memory specification, expected lifetime,
    // and estimated average amount of bytes written by a package during different modes.
    ioConfigBuilder.addPackageSpecificThresholds("com.vendor.package.B",
        new PerStateBytes(/* foregroundModeBytes= */ 2 * 1024 * 1024 * 1024,
                          /* backgroundModeBytes= */ 500 * 1024 * 1024,
                          /* garageModeBytes= */ 3 * 1024 * 1024 * 1024));


    return configBuilder.setIoOveruseConfiguration(ioConfigBuilder.build()).build();
}

ऐसे ऐप्लिकेशन जो ज़रूरत से ज़्यादा रिसॉर्स इस्तेमाल करने पर नज़र रखते हैं

वेंडर और तीसरे पक्ष के ऐप्लिकेशन, Watchdog से ऐप्लिकेशन के लिए संसाधन के ज़्यादा इस्तेमाल की सूचनाएं सुन सकते हैं. इसके अलावा, वे पिछले 30 दिनों तक के लिए, ऐप्लिकेशन के लिए संसाधन के ज़्यादा इस्तेमाल के आंकड़ों के लिए CarWatchdogManager को पोल कर सकते हैं.

ज़्यादा इस्तेमाल होने वाली सूचनाओं को सुनें

ऐप्लिकेशन, संसाधन के ज़रूरत से ज़्यादा इस्तेमाल होने की सूचना देने वाले टूल को लागू कर सकते हैं. साथ ही, CarWatchdogManager के साथ इस टूल को रजिस्टर कर सकते हैं, ताकि डिस्क के I/O के ज़रूरत से ज़्यादा इस्तेमाल होने की सीमा 80% या 100% तक पहुंचने पर, ऐप्लिकेशन से जुड़ी सूचनाएं मिल सकें. ऐप्लिकेशन इन सूचनाओं का इस्तेमाल इन कामों के लिए कर सकते हैं:

  • ऑफ़लाइन विश्लेषण के लिए, डिस्क के I/O के ज़्यादा इस्तेमाल के आंकड़ों को लॉग करें. ऐप्लिकेशन डेवलपर, डिस्क के I/O के ज़्यादा इस्तेमाल से जुड़ी समस्या को डीबग करने के लिए, इस लॉगिंग का इस्तेमाल कर सकते हैं.
  • डिस्क के I/O लिखने की संख्या को तब तक कम करें, जब तक कि ज़्यादा इस्तेमाल के काउंटर रीसेट न हो जाएं.

Java क्लाइंट

  1. CarWatchdogManager.ResourceOveruseListener को इनहेरिट करके, लिसनर लागू करें: 
    class ResourceOveruseListenerImpl implements
      CarWatchdogManager.ResourceOveruseListener {
            @Override
            public void onOveruse(
                  @NonNull ResourceOveruseStats resourceOveruseStats) {
                  // 1. Log/Upload resource overuse metrics.
                  // 2. Reduce writes until the counters reset.

                  IoOveruseStats ioOveruseStats = resourceOveruseStats.getIoOveruseStats();
                  // Stats period - [ioOveruseStats.getStartTime(), ioOveruseStats.getStartTime()
                  //   + ioOveruseStats.getDurationInSeconds()]
                  // Total I/O overuses - ioOveruseStats.getTotalOveruses()
                  // Total bytes written - ioOveruseStats.getTotalBytesWritten()
                  // Remaining write bytes for the current UTC calendar day -
                  //    ioOveruseStats.getRemainingWriteBytes()
            }
      }
}
  2. CarWatchdogManager.addResourceOveruseListener 
    private void addResourceOveruseListener() {
      CarWatchdogManager manager =
            (CarWatchdogManager) car.getCarManager(Car.CAR_WATCHDOG_SERVICE);
      // Choose a proper executor to handle resource overuse notifications.
      Executor executor = mContext.getMainExecutor();
      manager.addResourceOveruseListener(
            executor, CarWatchdogManager.FLAG_RESOURCE_OVERUSE_IO,
            mListenerImpl);
}
    को कॉल करके लिसनर इंस्टेंस रजिस्टर करें
  3. ऐप्लिकेशन के इन ऑडियो को सुनने के बाद, लिसनर इंस्टेंस को अनरजिस्टर करें: 
    private void removeResourceOveruseListener() {
    CarWatchdogManager manager =
            (CarWatchdogManager) car.getCarManager(Car.CAR_WATCHDOG_SERVICE);
    mCarWatchdogManager.removeResourceOveruseListener(
          mListenerImpl);
}

नेटिव क्लाइंट

  1. बिल्ड नियम की shared_libs डिपेंडेंसी में carwatchdog_aidl_interface-ndk_platform शामिल करें.

    Android.bp

    cc_binary {
    name: "sample_native_client",
    srcs: [
        "src/*.cpp"
    ],
    shared_libs: [
        "carwatchdog_aidl_interface-ndk_platform",
        "libbinder_ndk",
    ],
    vendor: true,
}
  2. वेंडर सेवा डोमेन को बाइंडर (binder_user मैक्रो) का इस्तेमाल करने और वेंडर सेवा डोमेन को carwatchdog क्लाइंट डोमेन (carwatchdog_client_domain macro) में जोड़ने की अनुमति देने के लिए, SELinux नीति जोड़ें. sample_client.te और file_contexts के लिए, नीचे दिया गया कोड देखें.

    sample_client.te

    type sample_client, domain;
type sample_client_exec, exec_type, file_type, vendor_file_type;

carwatchdog_client_domain(sample_client)

init_daemon_domain(sample_client)
binder_use(sample_client)

    file_contexts

    /vendor/bin/sample_native_client  u:object_r:sample_client_exec:s0
  3. BnResourceOveruseListener को इनहेरिट करके, संसाधन के ज़्यादा इस्तेमाल को सुनने की सुविधा लागू करें. संसाधन ज़्यादा इस्तेमाल होने की सूचनाओं को मैनेज करने के लिए, BnResourceOveruseListener::onOveruse को बदलें.

    ResourceOveruseListenerImpl.h

    class ResourceOveruseListenerImpl : public BnResourceOveruseListener {
public:
    ndk::ScopedAStatus onOveruse(
        ResourceOveruseStats resourceOveruseStats) override;

private:
    void initialize();
    void terminate();

    std::shared_ptr<ICarWatchdog> mWatchdogServer;
    std::shared_ptr<IResourceOveruseListener> mListener;
}

    ResourceOveruseListenerImpl.cpp

    ndk::ScopedAStatus ResourceOveruseListenerImpl::onOveruse(
      ResourceOveruseStats resourceOveruseStats) {

      // 1. Log/Upload resource overuse metrics.
      // 2. Reduce writes until the counters reset.

      if (stats.getTag() != ResourceOveruseStats::ioOveruseStats) {
            // Received resourceOveruseStats doesn't contain I/O overuse stats.
      }

      const IoOveruseStats& ioOveruseStats = stats.get();
      // Stats period - [ioOveruseStats.startTime,
      //   ioOveruseStats.startTime + ioOveruseStats.durationInSeconds]
      // Total I/O overuses - ioOveruseStats.totalOveruses
      // Total bytes written - ioOveruseStats.writtenBytes
      // Remaining write bytes for the current UTC calendar day -
      //    ioOveruseStats.remainingWriteBytes

      return ndk::ScopedAStatus::ok();
}
  4. बाइंडर थ्रेड पूल शुरू करें और संसाधन के ज़्यादा इस्तेमाल को सुनने वाले प्रोसेस को, वॉचडॉग सर्वर के साथ रजिस्टर करें. वॉचडॉग सर्वर, सेवा के नाम android.automotive.watchdog.ICarWatchdog/default के तहत रजिस्टर किया गया है.

    main.cpp

    int main(int argc, char** argv) {
    ABinderProcess_setThreadPoolMaxThreadCount(1);
    ABinderProcess_startThreadPool();
    std::shared_ptr<ResourceOveruseListenerImpl> listener =
        ndk::SharedRefBase::make<ResourceOveruseListenerImpl>();

    // The listener is added in initialize().
    listener->initialize();

    ... Run service ...

    // The listener is removed in terminate().
    listener->terminate();
}

    ResourceOveruseListenerImpl.cpp

    void ResourceOveruseListener::initialize() {
    ndk::SpAIBinder binder(AServiceManager_getService(
            "android.automotive.watchdog.ICarWatchdog/default"));
    std::shared_ptr<ICarWatchdog> server = ICarWatchdog::fromBinder(binder);
    mWatchdogServer = server;

    std::shared_ptr<IResourceOveruseListener> listener =
        IResourceOveruseListener::fromBinder(this->asBinder());
    mWatchdogServer->addResourceOveruseListener(
      std::vector<int>{ResourceType.IO}, listener);
    mListener = listener;
}

void ResourceOveruseListener::terminate() {
    mWatchdogServer->removeResourceOveruseListener(mListener);
}

संसाधन के ज़्यादा इस्तेमाल के आंकड़े

ऐप्लिकेशन, पिछले 30 दिनों के लिए, किसी खास I/O आंकड़ों के एटीएस के ज़्यादा इस्तेमाल के लिए CarWatchdogfoodManager को पोल कर सकते हैं.

Java क्लाइंट

रिसॉर्स के ज़्यादा इस्तेमाल से जुड़े आंकड़े पाने के लिए, CarWatchdogManager.getResourceOveruseStats का इस्तेमाल करें. डिस्क के I/O के ज़्यादा इस्तेमाल के आंकड़े पाने के लिए, CarWatchdogManager.FLAG_RESOURCE_OVERUSE_IO फ़्लैग पास करें.

private void getResourceOveruseStats() {
      CarWatchdogManager manager =
            (CarWatchdogManager) car.getCarManager(Car.CAR_WATCHDOG_SERVICE);

      // Returns resource overuse stats with I/O overuse stats for the past
      // 7 days. Stats are available for up to the past 30 days.
      ResourceOveruseStats resourceOveruseStats =
            mCarWatchdogManager.getResourceOveruseStats(
                  CarWatchdogManager.FLAG_RESOURCE_OVERUSE_IO,
                  CarWatchdogManager.STATS_PERIOD_PAST_7_DAYS);

      IoOveruseStats ioOveruseStats = resourceOveruseStats.getIoOveruseStats();
      // Stats period - [ioOveruseStats.getStartTime(), ioOveruseStats.getStartTime()
      //   + ioOveruseStats.getDurationInSeconds()]
      // Total I/O overuses - ioOveruseStats.getTotalOveruses()
      // Total bytes written - ioOveruseStats.getTotalBytesWritten()
      // Remaining write bytes for the UTC calendar day -
      //    ioOveruseStats.getRemainingWriteBytes()
}

नेटिव क्लाइंट

संसाधन के ज़्यादा इस्तेमाल के आंकड़े पाने के लिए, CarWatchdogServer.getResourceOveruseStats का इस्तेमाल करें. डिस्क I/O के बहुत ज़्यादा इस्तेमाल किए गए आंकड़े फ़ेच करने के लिए ResourceType.IO enum को पास करें.

void getResourceOveruseStats() {
      ndk::SpAIBinder binder(AServiceManager_getService(
            "android.automotive.watchdog.ICarWatchdog/default"));
      std::shared_ptr<ICarWatchdog> server = ICarWatchdog::fromBinder(binder);
      // Returns the stats only for the current UTC calendar day.
      const std::vector<ResourceOveruseStats> resourceOveruseStats;
      ndk::ScopedAStatus status = server.getResourceOveruseStats(
            std::vector<int>{ResourceType.IO}, &resourceOveruseStats);
      if (!status.isOk()) {
            // Failed to get the resource overuse stats.
            return;
      }

      for (const auto& stats : resourceOveruseStats) {
            if (stats.getTag() != ResourceOveruseStats::ioOveruseStats) {
                  continue;
            }
            const IoOveruseStats& ioOveruseStats = stats.get();
            // Stats period - [ioOveruseStats.startTime,
            //   ioOveruseStats.startTime + ioOveruseStats.durationInSeconds]
            // Total I/O overuses - ioOveruseStats.totalOveruses
            // Total bytes written - ioOveruseStats.writtenBytes
            // Remaining write bytes for the current UTC calendar day -
            //   ioOveruseStats.remainingWriteBytes
      }
}

संसाधन के ज़्यादा इस्तेमाल से जुड़ा उपयोगकर्ता अनुभव

यहां दिए गए सेक्शन में, संसाधन के ज़रूरत से ज़्यादा इस्तेमाल होने पर उपयोगकर्ता अनुभव के बारे में बताया गया है.

ऐप्लिकेशन की परफ़ॉर्मेंस की सेटिंग को प्राथमिकता दें

ऐप्लिकेशन के सेटिंग पेज पर,Prioritize app performance (नीचे दी गई इमेज देखें) की सेटिंग होती हैं. इनकी मदद से, उपयोगकर्ता सिस्टम और हार्डवेयर की लंबे समय तक की परफ़ॉर्मेंस के बजाय, ऐप्लिकेशन की परफ़ॉर्मेंस को प्राथमिकता दे सकते हैं. यह सेटिंग सिर्फ़ उन ऐप्लिकेशन के लिए उपलब्ध है जिन्हें संसाधनों के ज़्यादा इस्तेमाल पर बंद करना सुरक्षित है. अगर ऐसा नहीं है, तो यह सेटिंग बंद हो जाती है. जब किसी ऐप्लिकेशन के लिए यह सेटिंग बंद (डिफ़ॉल्ट सेटिंग) होती है, तो संसाधन का ज़रूरत से ज़्यादा इस्तेमाल करने पर ऐप्लिकेशन को बंद किया जा सकता है. ऐसा न करने पर, संसाधनों के ज़्यादा इस्तेमाल की वजह से ऐप्लिकेशन को बंद नहीं किया जाता.

जब उपयोगकर्ता इस सेटिंग को टॉगल करता है, तो पुष्टि करने वाला यह डायलॉग बॉक्स दिखता है. इसमें, सेटिंग को टॉगल करने के असर के बारे में बताया गया है:

90 दिनों के बाद, यह सेटिंग अपने-आप डिफ़ॉल्ट पर रीसेट हो जाती है. watchdogUserPackageSettingsResetDays का इस्तेमाल करके, दिन की सीमा में RRO ओवरले ऐप्लिकेशन की मदद से, 180 दिनों तक बदलाव किया जा सकता है. ज़्यादा जानने के लिए, रनटाइम के दौरान ऐप्लिकेशन के संसाधनों की वैल्यू बदलना देखें. AndroidManifest.xml में, ओवरले टैग का यह उदाहरण शामिल किया जा सकता है:

<overlay android:priority="<insert-value>"
      android:targetPackage="com.android.car.updatable"
      android:targetName="CarServiceCustomization"
      android:resourcesMap="@xml/overlays" />

res/values/config.xml में:

<resources>
  <integer name="watchdogUserPackageSettingsResetDays">value</integer>
</resources>

res/xml/overlays.xml में:

<overlay>
  <item target="integer/watchdogUserPackageSettingsResetDays" value="@integer/watchdogUserPackageSettingsResetDays" />
</overlay>

परफ़ॉर्मेंस पर असर डालने वाले ऐप्लिकेशन की सेटिंग

सेटिंग ऐप्लिकेशन में, परफ़ॉर्मेंस पर असर डालने वाले ऐप्लिकेशन सेक्शन होता है (पहला इलस्ट्रेशन देखें). टैप करने पर, उन ऐप्लिकेशन की सूची दिखती है जिन पर फ़्लैश मेमोरी का ज़्यादा इस्तेमाल होने और सिस्टम की परफ़ॉर्मेंस पर बुरा असर पड़ता है. यह सीडीडी 3.5.1 की ज़रूरी शर्त [C-1-1] के मुताबिक है.

परफ़ॉर्मेंस पर असर डालने वाले ऐप्लिकेशन

पहली इमेज. परफ़ॉर्मेंस पर असर डालने वाले ऐप्लिकेशन.

संसाधनों का ज़रूरत से ज़्यादा इस्तेमाल करने की वजह से बंद किए गए ऐप्लिकेशन की सूची यहां दी गई है (दूसरा चित्र देखें). सूची में दिए गए ऐप्लिकेशन को प्राथमिकता दी जा सकती है. ज़्यादा जानने के लिए, ऐप्लिकेशन की परफ़ॉर्मेंस सेटिंग को प्राथमिकता देना लेख पढ़ें.

संसाधनों का ज़रूरत से ज़्यादा इस्तेमाल करने की वजह से बंद किए गए ऐप्लिकेशन की सूची

दूसरी इमेज. उन ऐप्लिकेशन की सूची जिन्हें संसाधन के ज़्यादा इस्तेमाल की वजह से बंद कर दिया गया.

उपयोगकर्ता के लिए सूचना

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

ड्राइव के दौरान, उपयोगकर्ता को पहली सूचना हेड्स-अप सूचना के तौर पर भेजी जाती है. इसके बाद, अन्य सूचनाएं नोटिफ़िकेशन सेंटर पर भेजी जाती हैं.

उदाहरण के लिए, जब कोई ऐप्लिकेशन बार-बार डिस्क I/O का ज़्यादा इस्तेमाल करता है, तो उपयोगकर्ता को यह सूचना मिलती है:

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

लॉन्चर लागू करने के लिए सुझाव

संसाधन के ज़्यादा इस्तेमाल की वजह से जब ऐप्लिकेशन बंद हो जाते हैं, तो डिफ़ॉल्ट लॉन्चर ऐप्लिकेशन से ऐप्लिकेशन गायब हो जाते हैं. ऐसा इसलिए होता है, क्योंकि CarService, ऐप्लिकेशन की चालू स्थिति को PackageManager.COMPONENT_ENABLED_STATE_DISABLED_UNTIL_USED के तौर पर अपडेट करता है. OEM को इन ऐप्लिकेशन को असामान्य के तौर पर दिखाने के लिए, डिवाइस में पहले से मौजूद लॉन्चर को अपडेट करना होगा, ताकि उपयोगकर्ता ज़रूरत पड़ने पर इनका इस्तेमाल कर सकें. बिल्ड रिलीज़ के आधार पर ये सुझाव देखें.

Android SC V2 रिलीज़

  • लॉन्चर पर दिखाने के लिए पैकेज की सूची हासिल करते समय, लॉन्चर लागू करने के लिए MATCH_DISABLED_UNTIL_USED_COMPONENTS फ़्लैग का इस्तेमाल किया जाना चाहिए.
  • जब उपयोगकर्ता किसी ऐसे ऐप्लिकेशन पर क्लिक करता है जो PackageManager.COMPONENT_ENABLED_STATE_DISABLED_UNTIL_USED स्थिति में है, तो लॉन्चर ऐप्लिकेशन को ऐप्लिकेशन को चालू करना चाहिए. इसके लिए, चालू होने की स्थिति को इस तरह से सेट करना होगा:

    PackageManager.COMPONENT_ENABLED_STATE_ENABLED.