Watchdog, फ़्लैश मेमोरी के इस्तेमाल की निगरानी करता है. इसके लिए, वह डिस्क I/O की कुल संख्या को ट्रैक करता है. यह संख्या, हर यूआईडी के हिसाब से डिस्क I/O के उन आंकड़ों से मिलती है जो कर्नेल, `/proc/uid_io/stats` लोकेशन पर दिखाता है. जब कोई ऐप्लिकेशन या सेवा, डिस्क 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 के इस्तेमाल के बारे में ज़्यादा जानकारी मिलने पर, इन थ्रेशोल्ड को अपडेट किया जाता है.
कॉन्फ़िगरेशन एक्सएमएल फ़ॉर्मैट का बहुत ज़्यादा इस्तेमाल किया गया है
डिफ़ॉल्ट वेंडर कॉन्फ़िगरेशन को बिल्ड इमेज में /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>
CarWatchdogManager सिस्टम एपीआई के ज़रिए, संसाधन के ज़्यादा इस्तेमाल को कॉन्फ़िगर करने की सुविधा को अपडेट करना
ऊपर दिया गया एक्सएमएल कॉन्फ़िगरेशन, सिर्फ़ बिल्ड इमेज में दिया जा सकता है. अगर कोई ओईएम, बिल्ड रिलीज़ होने के बाद डिवाइस पर मौजूद कॉन्फ़िगरेशन को अपडेट करता है, तो वह डिवाइस पर मौजूद कॉन्फ़िगरेशन में बदलाव करने के लिए, इन एपीआई का इस्तेमाल कर सकता है.
- कॉल करने वाले को
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 क्लाइंट
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, }
- 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
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 दिनों के बाद, यह सेटिंग अपने-आप डिफ़ॉल्ट पर रीसेट हो जाती है. 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>
परफ़ॉर्मेंस पर असर डालने वाले ऐप्लिकेशन की सेटिंग
सेटिंग ऐप्लिकेशन में, परफ़ॉर्मेंस पर असर डालने वाले ऐप्लिकेशन सेक्शन होता है (पहला फ़िगर देखें). इस पर टैप करने से, उन ऐप्लिकेशन की सूची दिखती है जिन पर फ़्लैश मेमोरी का ज़्यादा इस्तेमाल करने की वजह से पाबंदी लगाई गई है. साथ ही, इससे सिस्टम की परफ़ॉर्मेंस पर बुरा असर पड़ता है. यह सीडीडी 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
स्थिति में मौजूद किसी ऐप्लिकेशन पर क्लिक करता है, तो लॉन्चर ऐप्लिकेशन को ऐप्लिकेशन चालू करना होगा. इसके लिए, ऐप्लिकेशन की स्थिति को इस तरह सेट करना होगा: