साल 2026 से, हम अपने ट्रंक स्टेबल डेवलपमेंट मॉडल के साथ अलाइन होने के लिए, दूसरी और चौथी तिमाही में AOSP पर सोर्स कोड पब्लिश करेंगे. इससे यह पक्का किया जा सकेगा कि प्लैटफ़ॉर्म, पूरे सिस्टम के लिए स्थिर बना रहे. हमारा सुझाव है कि AOSP को बनाने और उसमें योगदान देने के लिए, aosp-main के बजाय android-latest-release का इस्तेमाल करें. android-latest-release मेनिफ़ेस्ट ब्रांच, हमेशा AOSP पर पुश की गई सबसे नई रिलीज़ का रेफ़रंस देगी. ज़्यादा जानकारी के लिए, AOSP में हुए बदलाव लेख पढ़ें.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

फ़्लैश मेमोरी के इस्तेमाल पर नज़र रखना

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

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

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

बहुत ज़्यादा इस्तेमाल होने पर की जाने वाली कार्रवाइयां

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

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

जब किसी ऐप्लिकेशन या सेवा को बंद किया जा सकता है, तो Watchdog उस ऐप्लिकेशन या सेवा को बंद कर देता है. इस दौरान, ऐप्लिकेशन कॉम्पोनेंट की स्थिति PackageManager.COMPONENT_ENABLED_STATE_DISABLED_UNTIL_USED होती है.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ज़रूरी नहीं: Android 16 और इसके बाद वाले वर्शन में, बिल्ड इमेज में /vendor/etc/io-watchdog/resource_overuse_configuration.xml में, वेंडर के डिफ़ॉल्ट कॉन्फ़िगरेशन को रखा जा सकता है.

Android 15 और इससे पहले वाले वर्शन में, बिल्ड इमेज में /vendor/etc/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>

CarWatchdogManager के सिस्टम एपीआई के ज़रिए, बहुत ज़्यादा इस्तेमाल के कॉन्फ़िगरेशन को अपडेट करना

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

कॉल करने वाले को 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();
}

अपने रिसॉर्स के बहुत ज़्यादा इस्तेमाल की निगरानी करने वाले ऐप्लिकेशन

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

रिसॉर्स के बहुत ज़्यादा इस्तेमाल की सूचनाएं सुनना

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

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

Java क्लाइंट

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()
            }
      }
}

को कॉल करके, लिसनर इंस्टेंस रजिस्टर करें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);
}

जब ऐप्लिकेशन, इन चीज़ों को सुनना बंद कर दे, तो लिसनर इंस्टेंस को अनरजिस्टर करें:

private void removeResourceOveruseListener() {
    CarWatchdogManager manager =
            (CarWatchdogManager) car.getCarManager(Car.CAR_WATCHDOG_SERVICE);
    mCarWatchdogManager.removeResourceOveruseListener(
          mListenerImpl);
}

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

बिल्ड नियम की 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,
}

वेंडर सेवा के डोमेन को बाइंडर (binder_user मैक्रो) का इस्तेमाल करने की अनुमति देने के लिए, SELinux नीति जोड़ें. साथ ही, वेंडर सेवा के डोमेन को 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
```

रिसॉर्स के बहुत ज़्यादा इस्तेमाल का लिसनर लागू करें.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();
}

बाइंडर थ्रेड पूल शुरू करें और वॉचडॉग सर्वर के साथ, रिसॉर्स के बहुत ज़्यादा इस्तेमाल का लिसनर रजिस्टर करें. वॉचडॉग सर्वर, सेवा के नाम से रजिस्टर किया जाता है 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);
}

रिसॉर्स के बहुत ज़्यादा इस्तेमाल के आंकड़े पोल करना

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

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 दिनों के बाद, यह सेटिंग अपने-आप डिफ़ॉल्ट पर रीसेट हो जाती है. RRO ओवरले ऐप्लिकेशन का इस्तेमाल करके, दिनों की सीमा में बदलाव किया जा सकता है. इसके लिए, watchdogUserPackageSettingsResetDays का इस्तेमाल करें. दिनों की सीमा को ज़्यादा से ज़्यादा 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} सेक्शन मौजूद होता है पहली इमेज देखें. इस पर टैप करने पर, उन ऐप्लिकेशन की सूची दिखती है जिन पर फ़्लैश मेमोरी के बहुत ज़्यादा इस्तेमाल की वजह से पाबंदी लगाई गई है. साथ ही, इन ऐप्लिकेशन की वजह से सिस्टम की परफ़ॉर्मेंस पर बुरा असर पड़ता है. यह, सीडीडी 3.5.1 की ज़रूरी शर्त [C-1-1] के मुताबिक है.

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

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

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

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

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

उपयोगकर्ता को दी जाने वाली सूचना

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

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

उदाहरण के लिए, जब कोई ऐप्लिकेशन, डिस्क 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.