गड़बड़ी की रिपोर्ट पढ़ें

गड़बड़ियां किसी भी तरह के डेवलपमेंट में हकीकत हैं और गड़बड़ी की रिपोर्ट समस्याओं को पहचानने और उन्हें हल करने के लिए बहुत अहम है. Android के सभी वर्शन इस डिवाइस पर काम करते हैं Android की मदद से गड़बड़ी की रिपोर्ट कैप्चर की जा रही है डीबग ब्रिज (adb); Android 4.2 और उसके बाद के वर्शन डेवलपर गड़बड़ी की रिपोर्ट लेने और उन्हें ईमेल, Drive वगैरह से शेयर करने का विकल्प.

Android की गड़बड़ी की रिपोर्ट में dumpsys, dumpstate, और टेक्स्ट (.txt) फ़ॉर्मैट में logcat डेटा, जिससे आप आसानी से खोज कर सकते हैं एक अहम सोर्स होता है. नीचे दिए गए सेक्शन में, गड़बड़ी की रिपोर्ट के कॉम्पोनेंट के बारे में बताया गया है. आम तौर पर आने वाली समस्याओं के बारे में बताती हैं. साथ ही, काम की सलाह और grep निर्देश देती हैं का इस्तेमाल करें. ज़्यादातर सेक्शन में उदाहरण के साथ grep कमांड और आउटपुट और/या dumpsys आउटपुट के लिए.

Logcat

logcat लॉग, सभी logcat का स्ट्रिंग पर आधारित डंप होता है जानकारी. system वाला हिस्सा फ़्रेमवर्क के लिए रिज़र्व है और का इतिहास मुख्य से ज़्यादा है, जिसमें बाकी सब कुछ शामिल है. आम तौर पर, हर लाइन timestamp UID PID TID log-level से शुरू होती है, हालांकि, हो सकता है कि UID, Android के पुराने वर्शन की सूची में मौजूद न हो.

इवेंट लॉग देखना

इस लॉग में बाइनरी फ़ॉर्मैट वाले लॉग मैसेज की स्ट्रिंग दिखाई जाती है. यह logcat लॉग से कम शोर होता है, लेकिन पढ़ने में थोड़ा मुश्किल भी होता है. इवेंट लॉग देखते समय, इस सेक्शन में किसी खास प्रोसेस आईडी की खोज की जा सकती है (PID) की मदद से देखें कि प्रोसेस क्या चल रही है. बुनियादी फ़ॉर्मैट यह है: timestamp PID TID log-level log-tag tag-values.

लॉग लेवल में ये शामिल हैं:

  • V: ज़्यादा शब्दों में जानकारी देना
  • D: डीबग
  • I: जानकारी
  • W: चेतावनी
  • E: गड़बड़ी

 

अन्य काम के इवेंट लॉग टैग के लिए, यहां जाएं: /services/core/java/com/android/server/EventLogTag.logtag.

एएनआर और डेडलॉक

गड़बड़ी की रिपोर्ट की मदद से, समस्या की वजह का पता लगाया जा सकता है ऐप्लिकेशन नॉट रिस्पॉन्डिंग (ANR) गड़बड़ियां और डेडलॉक इवेंट.

काम न करने वाले ऐप्लिकेशन की पहचान करना

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

ANR in के लिए logcat के लॉग में, इसमें इस बारे में ज़्यादा जानकारी होती है कि ANR की गड़बड़ी के समय, सीपीयू का क्या इस्तेमाल हो रहा था.

स्टैक ट्रेस ढूंढना

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

  • मुख्य थ्रेड आपको सिर्फ़ यह बताती है कि थ्रेड शुरू होने के समय थ्रेड क्या कर रहा था एएनआर, जो ANR की असल वजह से जुड़ा हो भी सकता है और नहीं भी. (इसमें स्टैक की जानकारी गड़बड़ी की रिपोर्ट सही नहीं होगी; कोई और बात लंबे समय से अटकी हुई हो समय— लेकिन यह कि ANR की गड़बड़ी के लिए काफ़ी नहीं है—और आसानी से नहीं.)
  • स्टैक ट्रेस के एक से ज़्यादा सेट (VM TRACES JUST NOW और VM TRACES AT LAST ANR) मौजूद हो सकते हैं. पक्का करें कि आपको सही सेक्शन.

डेडलॉक खोजें

थ्रेड अटकने की वजह से, डेडलॉक सबसे पहले ANR की गड़बड़ी के तौर पर दिखते हैं. अगर आपने डेडलॉक सिस्टम सर्वर पर हिट करता है, वॉचडॉग उसे मार देता है, लॉग में इसके समान एक प्रविष्टि पर ले जाएगा: WATCHDOG KILLING SYSTEM PROCESS. उपयोगकर्ता के नज़रिए से, डिवाइस फिर से चालू होता है. हालांकि, तकनीकी तौर पर यह रनटाइम के दौरान रीस्टार्ट होता है, न कि डिवाइस को फिर से चालू करता है.

  • रनटाइम में रीस्टार्ट होने पर, सिस्टम सर्वर खत्म हो जाता है और रीस्टार्ट हुआ; जब कोई उपयोगकर्ता डिवाइस को फिर से बूट ऐनिमेशन पर देखता है.
  • रीबूट में, कर्नेल क्रैश हो गया है; जब उपयोगकर्ता यह देखता है डिवाइस को Google बूट के लोगो पर वापस भेज दिया जाएगा.

डेडलॉक खोजने के लिए, थ्रेड A के पैटर्न के लिए, वर्चुअल मशीन के ट्रेस सेक्शन देखें थ्रेड B में किसी चीज़ का इंतज़ार किया जा रहा है, जो किसी चीज़ का इंतज़ार कर रहा है थ्रेड A ने होल्ड पर रखा.

गतिविधियां

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

फ़ोकस की गई गतिविधियां देखें

फ़ोकस की गई गतिविधियों का इतिहास देखने के लिए, am_focused_activity.

व्यू की प्रोसेस शुरू हो गई है

प्रोसेस शुरू होने का इतिहास देखने के लिए, Start proc खोजें.

पता करें कि डिवाइस थ्रैशिंग है या नहीं

यह पता लगाने के लिए कि डिवाइस थ्रैशिंग, am_proc_died के आस-पास की गतिविधि में असामान्य वृद्धि की जांच करें और कम समय में am_proc_start.

मेमोरी

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

कम मेमोरी की पहचान करना

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

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

पुराने इंडिकेटर देखें

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

थ्रैशिंग इंडिकेटर देखें

सिस्टम थ्रैशिंग के अन्य इंडिकेटर (पेजिंग, सीधे तौर पर फिर से दावा करना वगैरह) में ये शामिल हैं kswapd, kworker, और mmcqd इस्तेमाल कर रहे हैं साइकल. (ध्यान रखें कि गड़बड़ी की जिस रिपोर्ट को इकट्ठा किया जाता है उससे थ्रैशिंग पर असर पड़ सकता है इंडिकेटर.)

ANR लॉग से मिलता-जुलता मेमोरी स्नैपशॉट मिल सकता है.

एक मेमोरी स्नैपशॉट पाएं

मेमोरी स्नैपशॉट एक डंपस्टेट है, जिसमें मौजूदा Java और नेटिव विज्ञापनों की सूची होती है (विवरण के लिए, देखना कुल मेमोरी का बंटवारा). ध्यान रखें कि स्नैपशॉट केवल राज्य किसी ख़ास समय पर; शायद सिस्टम बेहतर (या खराब) का आकार शामिल करें.

ब्रॉडकास्ट

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

ऐतिहासिक ब्रॉडकास्ट देखें

ऐतिहासिक प्रसारण वे हैं जिन्हें पहले ही भेजा जा चुका है, और जो ऑर्डर किया गया समय.

खास जानकारी वाले सेक्शन में, पिछले 300 दस्तावेज़ों की खास जानकारी होती है फ़ोरग्राउंड ब्रॉडकास्ट और पिछले 300 बैकग्राउंड ब्रॉडकास्ट होंगे.

detail सेक्शन में, पिछले 50 फ़ोरग्राउंड ब्रॉडकास्ट और पिछले 50 बैकग्राउंड ब्रॉडकास्ट हर ब्रॉडकास्ट के लिए रिसीवर. ऐसे रिसीवर जिनके पास:

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

चालू ब्रॉडकास्ट देखें

चालू ब्रॉडकास्ट वे हैं जिन्हें अभी तक नहीं भेजा गया है. दुनिया भर में सूची का मतलब है कि सिस्टम इतना तेज़ी से ब्रॉडकास्ट नहीं भेज सकता कि उस पर बने रहें.

ब्रॉडकास्ट लिसनर देखें

ब्रॉडकास्ट को सुनने वाले लोगों की सूची देखने के लिए, रिसीवर को चेक करें dumpsys activity broadcasts में मौजूद रिज़ॉल्वर टेबल. नीचे दिए गए उदाहरण में, उन सभी लोगों को दिखाया गया है जो USER_PRESENT को सुन रहे हैं.

विवाद की निगरानी करें

निगरानी के लिए होने वाले विवाद को लॉग करने से कभी-कभी यह पता चल सकता है कि मॉनिटर करने के लिए किए गए असल किस तरह के विवाद हैं. लेकिन अक्सर यह बताता है कि सिस्टम इतना लोड है कि सब कुछ धीमा हो गया है. आपको सिस्टम या इवेंट लॉग में ART से लॉग किए गए लंबे मॉनिटर इवेंट दिखाई दे सकते हैं.

सिस्टम लॉग में:

10-01 18:12:44.343 29761 29914 W art     : Long monitor contention event with owner method=void android.database.sqlite.SQLiteClosable.acquireReference() from SQLiteClosable.java:52 waiters=0 for 3.914s

इवेंट लॉग में:

10-01 18:12:44.364 29761 29914 I dvm_lock_sample: [com.google.android.youtube,0,pool-3-thread-9,3914,ScheduledTaskMaster.java,138,SQLiteClosable.java,52,100]

बैकग्राउंड कंपाइलेशन

कंपाइल करना महंगा हो सकता है और डिवाइस लोड हो सकता है.

Google Play Store के अपडेट होने पर, बैकग्राउंड में कंपाइलेशन किया जा सकता है डाउनलोड हो रहा है. इस स्थिति में, Google Play Store ऐप्लिकेशन के मैसेज (finsky) और installd इससे पहले दिखते हैं dex2oat मैसेज.

ऐप्लिकेशन लोड होने के दौरान, बैकग्राउंड में कंपाइलेशन भी हो सकता है dex फ़ाइल, जिसे अभी तक कंपाइल नहीं किया गया है. इस मामले में, आपको यह नहीं दिखेगा finsky या installd लॉगिंग.

कहानी सुनाने की कला

किसी समस्या की कहानी को स्थापित करना (यह कैसे शुरू हुआ, क्या हुआ, कैसे हुआ सिस्टम ने प्रतिक्रिया दी है) इवेंट की एक सटीक समयावधि की ज़रूरत है. Google आपके यूआरएल पैरामीटर को कैसे इस्तेमाल करेगा, यह तय करने के लिए गड़बड़ी की रिपोर्ट में दी गई जानकारी का इस्तेमाल करें, ताकि कई लॉग में टाइमलाइन सिंक हो सके और गड़बड़ी की रिपोर्ट का सटीक टाइमस्टैंप तय करें.

टाइमलाइन सिंक करें

गड़बड़ी की रिपोर्ट में एक साथ कई टाइमलाइन दिखती हैं: सिस्टम लॉग, इवेंट लॉग, कर्नेल लॉग, और ब्रॉडकास्ट के लिए कई ख़ास टाइमलाइन, बैटरी के आंकड़े, माफ़ करें, समय की जानकारी देने वाली रिपोर्ट अक्सर अलग-अलग समय के आधार पर दिखाई जाती है.

सिस्टम और इवेंट लॉग के टाइमस्टैंप, उपयोगकर्ता के समय क्षेत्र में ही होने चाहिए (जैसा कि ज़्यादातर टाइमस्टैंप पर होते हैं). उदाहरण के लिए, जब उपयोगकर्ता होम बटन पर टैप करता है, सिस्टम लॉग की रिपोर्ट:

10-03 17:19:52.939  1963  2071 I ActivityManager: START u0 {act=android.intent.action.MAIN cat=[android.intent.category.HOME] flg=0x10200000 cmp=com.google.android.googlequicksearchbox/com.google.android.launcher.GEL (has extras)} from uid 1000 on display 0

उसी कार्रवाई के लिए, इवेंट लॉग रिपोर्ट करता है:

10-03 17:19:54.279  1963  2071 I am_focused_activity: [0,com.google.android.googlequicksearchbox/com.google.android.launcher.GEL]

Kernel (dmesg) लॉग अलग समय आधार का इस्तेमाल करते हैं, जिसमें लॉग आइटम टैग किए जाते हैं बूटलोडर के पूरा होने के बाद सेकंड में. इस टाइमस्केल को दूसरे डिवाइस पर रजिस्टर करने के लिए टाइमस्केल, सस्पेंड एग्ज़िट और सस्पेंड एंट्री मैसेज खोजें:

<6>[201640.779997] PM: suspend exit 2015-10-03 19:11:06.646094058 UTC
…
<6>[201644.854315] PM: suspend entry 2015-10-03 19:11:10.720416452 UTC

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

गड़बड़ी की रिपोर्ट के समय का पता लगाएं

यह पता लगाने के लिए कि गड़बड़ी की रिपोर्ट कब ली गई थी, सबसे पहले सिस्टम लॉग (Logcat) की जांच करें dumpstate: begin के लिए:

10-03 17:19:54.322 19398 19398 I dumpstate: begin

इसके बाद, Starting service 'bugreport' मैसेज के लिए कर्नेल लॉग (dmesg) के टाइमस्टैंप देखें:

<5>[207064.285315] init: Starting service 'bugreport'...

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

पावर

इवेंट लॉग में स्क्रीन पावर की स्थिति शामिल होती है, जहां 0 का मतलब स्क्रीन बंद है और 1 का मतलब है स्क्रीन चालू है और 2 का काम कीगार्ड पूरा करने के लिए है.

गड़बड़ी की रिपोर्ट में, वेक लॉक के आंकड़े भी शामिल होते हैं. इस तकनीक का इस्तेमाल किया जाता है ऐप्लिकेशन डेवलपर को यह बताना होगा कि उनके ऐप्लिकेशन के पास डिवाइस की ज़रूरत है का भी इस्तेमाल किया जा सकता है. (वेक लॉक के बारे में जानने के लिए, PowerManager.वेकलॉक और रखें सीपीयू को चालू किया जाता है.)

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

पावर की स्थिति को विज़ुअलाइज़ करने के लिए, इसका इस्तेमाल करें बैटरी इतिहासकार, Android गड़बड़ी की रिपोर्ट का इस्तेमाल करके बैटरी का इस्तेमाल करने वाले उपभोक्ताओं का विश्लेषण करने के लिए Google ओपन सोर्स टूल फ़ाइलें शामिल हैं.

पैकेज

DUMP OF SERVICE package सेक्शन में ऐप्लिकेशन के वर्शन (और काम के अन्य) शामिल हैं जानकारी).

प्रक्रियाएं

गड़बड़ी की रिपोर्ट में, अलग-अलग प्रोसेस के लिए बहुत ज़्यादा डेटा मौजूद होता है. स्टॉप का समय, रनटाइम की अवधि, उससे जुड़ी सेवाएं, oom_adj स्कोर वगैरह. Android प्रोसेस को कैसे मैनेज करता है, इस बारे में जानने के लिए यहां जाएं प्रोसेस और Threads.

प्रोसेस रनटाइम तय करना

procstats सेक्शन में, समयावधि से जुड़े सभी आंकड़े दिए गए हैं और उससे जुड़ी सेवाएं लगातार चल रही हैं. लोग आसानी से और आसानी से पढ़ सकें सारांश, दोनों में से किसी एक का डेटा देखने के लिए AGGREGATED OVER की खोज करें पिछले तीन या 24 घंटे में बंद करें. इसके बाद सूची देखने के लिए Summary: पर खोजें अलग-अलग प्राथमिकताओं के हिसाब से प्रोसेस कितनी देर तक चलती हैं. इसके अलावा, रैम के इस्तेमाल को कम से कम औसत औसत पीएसएस/कम से कम औसत यूएसएस के हिसाब से फ़ॉर्मैट किया गया है.

प्रोसेस चलने की वजहें

dumpsys activity processes सेक्शन में, मौजूदा सभी oom_adj स्कोर के हिसाब से क्रम में लगाई गई मौजूदा प्रोसेस (Android संकेत देता है) प्रोसेस को एक oom_adj वैल्यू असाइन करके, डेटा को अहमियत दी जाती है. ऐक्टिविटी मैनेजर की मदद से डाइनैमिक रूप से अपडेट किया जा सकता है). आउटपुट इसके जैसा है एक मेमोरी स्नैपशॉट, लेकिन उसमें अतिरिक्त प्रक्रिया के चलने की वजह के बारे में जानकारी. नीचे दिए गए उदाहरण में, बोल्ड की गई एंट्री बताती हैं कि gms.persistent प्रोसेस चल रही है vis (दृष्टिहीन) प्राथमिकता पर है क्योंकि सिस्टम प्रक्रिया यह NetworkLocationService है.

स्कैन

बहुत ज़्यादा परफ़ॉर्म करने वाले ऐप्लिकेशन की पहचान करने के लिए, नीचे दिया गया तरीका अपनाएं ब्लूटूथ कम ऊर्जा (BLE) स्कैन करता है:

  • BluetoothLeScanner के लॉग मैसेज ढूंढें:
    $ grep 'BluetoothLeScanner' ~/downloads/bugreport.txt
    07-28 15:55:19.090 24840 24851 D BluetoothLeScanner: onClientRegistered() - status=0 clientIf=5
    
  • लॉग मैसेज में पीआईडी ढूंढें. इस उदाहरण में, "24840" और "24851 में" पीआईडी (प्रोसेस आईडी) और टीआईडी (थ्रेड आईडी) हैं.
  • पीआईडी से जुड़े ऐप्लिकेशन का पता लगाएं:
    PID #24840: ProcessRecord{4fe996a 24840:com.badapp/u0a105}
    
    अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है

    इस उदाहरण में, पैकेज का नाम com.badapp है.

  • Google Play पर पैकेज का नाम देखकर, उन समस्याओं का पता लगाएं जो आपके ऐप्लिकेशन का इस्तेमाल कर रहे हैं ऐप्लिकेशन: https://play.google.com/store/apps/details?id=com.badapp.

ध्यान दें: Android 7.0 वर्शन वाले डिवाइसों के लिए, यह सिस्टम, BLE स्कैन के लिए डेटा इकट्ठा करता है और इन गतिविधियों को जोड़ता है शुरुआती ऐप्लिकेशन के साथ. जानकारी के लिए, यह देखें कम ऊर्जा (एलई) साथ ही, ब्लूटूथ स्कैन भी किया जा सकता है.