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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

<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 अनुमति दें कॉलर है.
  • मौजूदा कॉन्फ़िगरेशन का इस्तेमाल करके, नए कॉन्फ़िगरेशन. एपीआई का इस्तेमाल करना पाने के लिए 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();
}

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

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

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

ऐप्लिकेशन, रिसोर्स का ज़रूरत से ज़्यादा इस्तेमाल करने वाले लिसनर को लागू कर सकते हैं. साथ ही, 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. carwatchdog_aidl_interface-ndk_platform को इसमें शामिल करें: बिल्ड नियम पर shared_libs डिपेंडेंसी.

    Android.bp

    cc_binary {
        name: "sample_native_client",
        srcs: [
            "src/*.cpp"
        ],
        shared_libs: [
            "carwatchdog_aidl_interface-ndk_platform",
            "libbinder_ndk",
        ],
        vendor: true,
    }
    
  2. वेंडर सर्विस डोमेन को बाइंडर का इस्तेमाल करने की अनुमति देने के लिए, SELinux नीति जोड़ें (binder_user मैक्रो) और वेंडर सेवा डोमेन को carwatchdog क्लाइंट डोमेन (carwatchdog_client_domain macro). 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);
    }
    

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

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

Java क्लाइंट

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

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>

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

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

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

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

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

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

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

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

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

उपयोगकर्ता की पहली सूचना (Drive के दौरान) को हेड-अप के तौर पर पोस्ट किया जाता है उस सूचना पर सूचना और अन्य सूचनाएं पोस्ट की जाती हैं बीच में.

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

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

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

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

Android SC V2 रिलीज़

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

    PackageManager.COMPONENT_ENABLED_STATE_ENABLED.