इस पेज पर, Android Studio और Android Gradle प्लग-इन से जुड़ी समस्याओं को ट्रैक किया जाता है. अगर आपको कोई ऐसी समस्या आ रही है जो यहां शामिल नहीं है, तो कृपया बग की शिकायत करें.
झलक देखने के लिए अपग्रेड करें: Android Studio और Android Gradle प्लगिन की हर रिलीज़ का मकसद, स्थिरता और परफ़ॉर्मेंस को बेहतर बनाना और नई सुविधाएं जोड़ना है. आने वाली रिलीज़ के फ़ायदों का अभी अनुभव करने के लिए, Android Studio की झलक डाउनलोड और इंस्टॉल करें.
Android Studio से जुड़ी सामान्य समस्याएं
इस सेक्शन में, Android Studio में मौजूद आम समस्याओं के बारे में बताया गया है.
Android Studio Panda 3, IntelliJ Develocity प्लगिन 1.2.0 के साथ काम नहीं करता
Android Studio Panda 3 Canary 1 से, Develocity IDE प्लगिन v1.2.0 का इस्तेमाल करने पर, रन ऐक्शन काम नहीं करता. साथ ही, यह गड़बड़ी (समस्या #492439205) दिखती है:
Found interface com.android.tools.idea.gradle.project.build.invoker.GradleBuildInvoker$Request, but class was expected
Develocity के डेवलपर, नए वर्शन के लिए इस समस्या को ठीक करने पर काम कर रहे हैं.
समस्या हल करने का तरीका: Develocity IDE प्लग इन के v1.2.0 वर्शन को बंद करने से समस्या हल हो जाती है. हालांकि, ऐसा तब तक ही होता है, जब तक प्लग इन के नए वर्शन में इस समस्या को ठीक नहीं कर दिया जाता.
Kotlin 2.0: लेआउट इंस्पेक्टर में लैम्डा रिज़ॉल्व नहीं किए जा सकते
Kotlin 2.0 का इस्तेमाल करने पर, लैम्डा को रिज़ॉल्व नहीं किया जा सकता. साथ ही, लेआउट इंस्पेक्टर, लैम्डा के सोर्स कोड पर सामान्य तरीके से नेविगेट नहीं कर सकता.
समस्या हल करने का तरीका: जब तक यह समस्या ठीक नहीं हो जाती, तब तक समस्या हल करने के लिए, नीचे दिया गया कंपाइलर विकल्प जोड़ें:
kotlin {
compilerOptions {
freeCompilerArgs.add("-Xlambdas=class")
}
}
"लॉन्च करने से पहले" Gradle-अवेयर मेक के बिना कॉन्फ़िगरेशन चलाने पर, डिप्लॉयमेंट से जुड़ी गड़बड़ी होती है
Android Studio Ladybug Feature Drop Canary 9 में एक समस्या थी. इसकी वजह से, इस वर्शन में खोले गए प्रोजेक्ट से रन कॉन्फ़िगरेशन की जानकारी हट जाती थी. अगर आपने कभी उस वर्शन के साथ अपना प्रोजेक्ट खोला है और ऐप्लिकेशन को चलाने पर "बिल्ड आर्टफ़ैक्ट लोड हो रहे हैं" गड़बड़ी दिखती है, तो पुष्टि करें कि चालू रन कॉन्फ़िगरेशन के "लॉन्च करने से पहले" सेक्शन में "Gradle-aware Make" चरण मौजूद हो. इसकी पुष्टि करने के लिए, रन/डीबग कॉन्फ़िगरेशन > कॉन्फ़िगरेशन में बदलाव करें पर क्लिक करें. इसके बाद, चालू रन कॉन्फ़िगरेशन पर क्लिक करें और पुष्टि करें कि "लॉन्च करने से पहले" सेक्शन में "Gradle-अवेयर मेक" चरण मौजूद है. माफ़ करें, Android Studio इस समस्या को अपने-आप ठीक नहीं कर सकता. इसकी वजह यह है कि कुछ रन कॉन्फ़िगरेशन को जान-बूझकर "Gradle-aware Make" चरण के बिना सेट अप किया गया हो.
एपीआई लेवल 35 वाले डिवाइसों या एम्युलेटर पर, 'बदलाव लागू करें और ऐक्टिविटी रीस्टार्ट करें' सुविधा, ऐक्टिविटी को रीस्टार्ट नहीं करती
जब एपीआई 35 वाले डिवाइस पर, 'बदलाव लागू करें और गतिविधि रीस्टार्ट करें' सुविधा का इस्तेमाल करके कोड में किए गए बदलावों को डिप्लॉय किया जाता है, तो ऐप्लिकेशन रीस्टार्ट नहीं होगा. साथ ही, आपको बदलावों का असर नहीं दिखेगा. ऐप्लिकेशन को फिर से चलाने पर, आपको कोड में किए गए बदलावों का असर दिखेगा. हमारी टीम इसकी जांच कर रही है.
Firebase Assistant की विंडो में गड़बड़ी का मैसेज दिखना
अगर Firebase Assistant विंडो (मुख्य मेन्यू में टूल > Firebase) में गड़बड़ी का कोई मैसेज दिखता है, तो गड़बड़ी को ठीक करने के लिए, कैश मेमोरी को अमान्य करें और Android Studio को रीस्टार्ट करें.
लेआउट इंस्पेक्टर का इस्तेमाल करके, किसी व्यू को अलग नहीं किया जा सकता
एम्बेड किए गए लेआउट इंस्पेक्टर का इस्तेमाल करके, किसी व्यू को अलग करने की सुविधा कुछ समय के लिए उपलब्ध नहीं है. हम आने वाले समय में इस समस्या को ठीक करने के लिए काम कर रहे हैं.
लेआउट इंस्पेक्टर का इस्तेमाल करके, Compose के सभी नोड की जांच नहीं की जा सकती
अगर आपको लेआउट इंस्पेक्टर का इस्तेमाल करते समय, Compose के सभी नोड की जांच करने का विकल्प नहीं दिखता है, तो ऐसा किसी गड़बड़ी की वजह से हो सकता है. इस गड़बड़ी को Compose के 1.5.0-alpha04 वर्शन में ठीक कर दिया गया है. अगर आपको यह समस्या आ रही है, तो पक्का करें कि आपने Compose के वर्शन 1.5.0-alpha04 या इसके बाद के वर्शन पर अपग्रेड किया हो.
कंपोज़ की झलक रेंडर करते समय गड़बड़ी होना
Android Studio Chipmunk से शुरू करते हुए, अगर आपको समस्याओं वाले पैनल में java.lang.NoSuchFieldError: view_tree_saved_state_registry_owner या java.lang.ClassNotFoundException: androidx.savedstate.R$id दिख रहा है, तो अपने मॉड्यूल में androidx.lifecycle:lifecycle-viewmodel-savedstate के लिए debugImplementation डिपेंडेंसी शामिल करना न भूलें.
अगर आपको समस्या पैनल में java.lang.NoSuchFieldError: view_tree_lifecycle_owner दिख रहा है, तो पक्का करें कि आपने अपने मॉड्यूल में androidx.lifecycle:lifecycle-runtime के लिए debugImplementation डिपेंडेंसी शामिल की हो.
अगर आपको समस्याओं वाले पैनल में java.lang.NoClassDefFoundError: Could not initialize class androidx.customview.poolingcontainer.PoolingContainer या java.lang.NoClassDefFoundError: androidx/customview/poolingcontainer/PoolingContainerListener दिख रहा है, तो अपने मॉड्यूल में androidx.customview:customview-poolingcontainer के लिए debugImplementation डिपेंडेंसी शामिल करना न भूलें.
कुंजी और कीस्टोर के लिए अलग-अलग पासवर्ड इस्तेमाल करने पर गड़बड़ी होना
वर्शन 4.2 से, Android Studio अब JDK 11 पर चलता है. इस अपडेट की वजह से, साइनिंग पासकोड से जुड़े बुनियादी व्यवहार में बदलाव होता है.
Build > Generate Signed Bundle / APK पर जाकर, किसी ऐप्लिकेशन बंडल या APK के लिए ऐप्लिकेशन साइनिंग को कॉन्फ़िगर करने की कोशिश करने पर, कुंजी और कीस्टोर के लिए अलग-अलग पासवर्ड डालने से यह गड़बड़ी हो सकती है:
Key was created with errors:
Warning: Different store and Key passwords not supported for PKCS12 Key stores
इस समस्या को हल करने के लिए, कुंजी और कीस्टोर, दोनों के लिए एक ही पासवर्ड डालें.
वर्शन 4.2 इंस्टॉल करने के बाद, Android Studio चालू नहीं हो रहा है
Studio, पिछले .vmoptions को इंपोर्ट करने की कोशिश करता है. साथ ही, उन्हें सैनिटाइज़ करता है, ताकि वे JDK 11 के इस्तेमाल किए गए गार्बेज कलेक्टर के साथ काम कर सकें. अगर यह प्रोसेस पूरी नहीं हो पाती है, तो हो सकता है कि IDE उन उपयोगकर्ताओं के लिए शुरू न हो जिन्होंने .vmoptions फ़ाइल में कस्टम वीएम विकल्प सेट किए हैं.
इस समस्या को हल करने के लिए, हमारा सुझाव है कि आप .vmoptions में कस्टम विकल्पों को टिप्पणी के तौर पर मार्क करें. इसके लिए, “#” वर्ण का इस्तेमाल करें. .vmoptions फ़ाइल, इन जगहों पर मिल सकती है:
Windows
C:\Users\YourUserName\AppData\[Local|Roaming]\Google\AndroidStudio4.2\studio64.exe.vmoptions
macOS
~/Library/Application Support/Google/AndroidStudio4.2/studio.vmoptions
Linux
~/.config/Google/AndroidStudio4.2/studio64.vmoptions
अगर यह तरीका आज़माने के बाद भी Studio चालू नहीं होता है, तो नीचे दिया गया अपग्रेड करने के बाद Studio चालू नहीं होता सेक्शन देखें.
डेटाबेस जांचने वाले टूल का इस्तेमाल करने वाले ऐप्लिकेशन, Android 11 एम्युलेटर पर क्रैश हो जाते हैं
डेटाबेस जांचने वाले टूल का इस्तेमाल करने वाले ऐप्लिकेशन, Android 11 एम्युलेटर पर क्रैश हो सकते हैं. साथ ही, logcat में इस तरह की गड़बड़ी दिख सकती है:
Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR)
इस समस्या को ठीक करने के लिए, अपने Android 11 एम्युलेटर को वर्शन 9 या इसके बाद के वर्शन पर अपग्रेड करें. इसके लिए, Tools > SDK Manager पर जाएं. SDK टूल के प्लैटफ़ॉर्म टैब में, पैकेज की जानकारी दिखाएं लेबल वाले बॉक्स को चुनें. इसके बाद, Android 11 एम्युलेटर का नौवां या इसके बाद का वर्शन चुनें.

अपग्रेड करने के बाद, Studio चालू नहीं हो रहा है
अगर अपग्रेड करने के बाद Studio शुरू नहीं होता है, तो हो सकता है कि Android Studio के पिछले वर्शन से इंपोर्ट किया गया Android Studio कॉन्फ़िगरेशन अमान्य हो या कोई प्लग इन काम न कर रहा हो. इस समस्या को हल करने के लिए, Android Studio के वर्शन और ऑपरेटिंग सिस्टम के हिसाब से, नीचे दी गई डायरेक्ट्री को मिटाएं या बैकअप के लिए उसका नाम बदलें. इसके बाद, Android Studio को फिर से शुरू करें. इससे Android Studio अपनी डिफ़ॉल्ट स्थिति में रीसेट हो जाएगा और तीसरे पक्ष के सभी प्लग इन हट जाएंगे.
Android Studio 4.1 और इसके बाद के वर्शन के लिए:
Windows:
%APPDATA%\Google\AndroidStudio<version>
उदाहरण:C:\Users\your_user_name\AppData\Roaming\Google\AndroidStudio4.1macOS:
~/Library/Application Support/Google/AndroidStudio<version>
उदाहरण:~/Library/Application Support/Google/AndroidStudio4.1Linux:
~/.config/Google/AndroidStudio<version>और~/.local/share/Google/AndroidStudio<version>
उदाहरण:~/.config/Google/AndroidStudio4.1और~/.local/share/Google/AndroidStudio4.1
Android Studio 4.0 और इससे पहले के वर्शन के लिए:
Windows:
%HOMEPATH%\.AndroidStudio<version>\config
उदाहरण:C:\Users\your_user_name\.AndroidStudio3.6\configmacOS:
~/Library/Preferences/AndroidStudio<version>
उदाहरण:~/Library/Preferences/AndroidStudio3.6Linux:
~/.AndroidStudio<version>/config
उदाहरण:~/.AndroidStudio3.6/config
ध्यान दें कि Android Studio के Canary और बीटा वर्शन के लिए, कॉन्फ़िगरेशन डायरेक्ट्री PreviewX.Y है, न कि <version> के लिए X.Y. उदाहरण के लिए, Android Studio 4.1 Canary बिल्ड, AndroidStudioPreview4.1 का इस्तेमाल करते हैं. यह AndroidStudio4.1 डायरेक्ट्री के बजाय इस्तेमाल किया जाता है. इस डायरेक्ट्री का इस्तेमाल, रिलीज़ कैंडिडेट और स्टेबल रिलीज़ के लिए किया जाता है.
Kotlin मल्टीप्लैटफ़ॉर्म प्रोजेक्ट में कंपाइलेशन से जुड़ी समस्या
सिंबल मौजूद न होने की वजह से, Kotlin एमपीपी कोड में कंपाइलेशन से जुड़ी गड़बड़ियां हो सकती हैं. Kotlin प्लगिन को 1.4 वर्शन पर अपग्रेड करने से, यह समस्या हल हो जाएगी.
Linux पर की-मैपिंग से जुड़ी समस्याएं
Linux पर, कुछ कीबोर्ड शॉर्टकट, Linux के डिफ़ॉल्ट कीबोर्ड शॉर्टकट और KDE और GNOME जैसे लोकप्रिय विंडो मैनेजर के शॉर्टकट के साथ मेल नहीं खाते. ऐसा हो सकता है कि एक-दूसरे से मेल न खाने वाले ये कीबोर्ड शॉर्टकट, Android Studio में उम्मीद के मुताबिक काम न करें.
इस समस्या के बारे में ज़्यादा जानकारी (इसमें समस्या को हल करने के संभावित तरीके भी शामिल हैं) IntelliJ के बग ट्रैकर में मिल सकती है.
ChromeOS पर यूज़र इंटरफ़ेस (यूआई) का टेक्स्ट छोटा दिखना
ChromeOS पर, टेक्स्ट पिछली रिलीज़ की तुलना में काफ़ी छोटा दिख सकता है. इस समस्या को हल करने के लिए, यह तरीका अपनाएं:
- फ़ाइल > सेटिंग पर क्लिक करके, सेटिंग विंडो खोलें
- Appearance & Behavior > Appearance पर जाएं.
- कस्टम फ़ॉन्ट का इस्तेमाल करें को चुनें.
- फ़ॉन्ट का साइज़ बढ़ाएं.
- Settings विंडो में, Editor > Font पर जाएं.
- फ़ॉन्ट का साइज़ बढ़ाएं.
- ठीक है पर क्लिक करें.
कोड में बदलाव करना
इस सेक्शन में, कोड एडिटर से जुड़ी आम समस्याओं के बारे में बताया गया है.
कीबोर्ड इनपुट का काम न करना - Linux पर "iBus" से जुड़ी समस्याएं
Linux पर iBus डीमन और Android Studio के बीच कुछ इंटरैक्शन होते हैं. कुछ मामलों में, IDE कीबोर्ड इनपुट का जवाब देना बंद कर देता है या रैंडम वर्णों को इनपुट करना शुरू कर देता है. यह गड़बड़ी, iBus और XLib + AWT के बीच सिंक न होने की वजह से होती है. इसकी शिकायत, JetBrains और iBus को पहले ही की जा चुकी है. इस समस्या को हल करने के लिए, फ़िलहाल तीन तरीके उपलब्ध हैं:
- पहला तरीका: iBus को सिंक्रोनस मोड में चालू करें. Android Studio शुरू करने से पहले, कमांड लाइन पर यह कमांड चलाएं:
$ IBUS_ENABLE_SYNC_MODE=1 ibus-daemon -xrd
- दूसरा तरीका: Android Studio में iBus इनपुट को बंद करें. सिर्फ़ Android Studio के लिए iBus इनपुट को बंद करने के लिए, कमांड लाइन पर यह कमांड दें:
इस तरीके से, सिर्फ़ Android Studio के लिए इनपुट के तरीके बंद किए जाते हैं. इससे, आपके डिवाइस पर चल रहे अन्य ऐप्लिकेशन पर कोई असर नहीं पड़ता. ध्यान दें कि अगर Android Studio के चलने के दौरान डीमन को रीस्टार्ट किया जाता है (उदाहरण के लिए,$ XMODIFIERS= ./bin/studio
ibus-daemon -rdचलाकर), तो अन्य सभी ऐप्लिकेशन के लिए इनपुट के तरीके बंद हो जाते हैं. साथ ही, सेगमेंटेशन फ़ॉल्ट की वजह से Android Studio का JVM क्रैश हो सकता है. - तीसरा तरीका: शॉर्टकट बाइंडिंग की दोबारा जांच करके पक्का करें कि अगले इनपुट का शॉर्टकट, Control+Space पर सेट न हो. ऐसा इसलिए, क्योंकि यह Android Studio में कोड पूरा करने का शॉर्टकट भी है. Ubuntu 14.04 (Trusty) में, Super+Space को डिफ़ॉल्ट शॉर्टकट के तौर पर सेट किया गया है. हालांकि, पिछले वर्शन की सेटिंग अब भी मौजूद हो सकती हैं. शॉर्टकट बाइंडिंग देखने के लिए, कमांड लाइन पर
ibus-setupचलाएं. इससे IBus की सेटिंग वाली विंडो खुल जाएगी. कीबोर्ड शॉर्टकट में जाकर, इनपुट का अगला तरीका देखें. अगर यह Control+Space पर सेट है, तो इसे Super+Space या अपनी पसंद के किसी अन्य शॉर्टकट पर सेट करें.
प्रोजेक्ट कॉन्फ़िगरेशन
इस सेक्शन में, प्रोजेक्ट कॉन्फ़िगरेशन और Gradle सिंक से जुड़ी समस्याओं के बारे में बताया गया है.
Gradle सिंक नहीं हो सका: ब्रोकन पाइप
समस्या यह है कि Gradle डीमन, IPv6 के बजाय IPv4 का इस्तेमाल करने की कोशिश कर रहा है.
- पहला तरीका: Linux पर, अपने
~/.profileया~/.bash_profileमें यह डालें:export _JAVA_OPTIONS="-Djava.net.preferIPv6Addresses=true" - दूसरा तरीका: Android Studio की vmoptions फ़ाइल में,
-Djava.net.preferIPv4Addresses=trueलाइन को बदलकर-Djava.net.preferIPv6Addresses=trueकरें. ज़्यादा जानकारी के लिए, नेटवर्किंग IPv6 की इस्तेमाल के लिए गाइड देखें.
Gradle सिंक या एसडीके मैनेजर से "पीयर की पुष्टि नहीं हुई" गड़बड़ियां मिलना
इन गड़बड़ियों की असल वजह, $JAVA_HOME/jre/lib/certificates/cacerts में सर्टिफ़िकेट मौजूद न होना है. इन गड़बड़ियों को ठीक करने के लिए, यह तरीका अपनाएं:
- अगर प्रॉक्सी का इस्तेमाल किया जा रहा है, तो सीधे कनेक्ट करने की कोशिश करें. अगर डायरेक्ट कनेक्शन काम करता है, तो प्रॉक्सी के ज़रिए कनेक्ट करने के लिए, आपको
keytoolका इस्तेमाल करके, प्रॉक्सी सर्वर के सर्टिफ़िकेट को cacerts फ़ाइल में जोड़ना पड़ सकता है. - इस्तेमाल किए जा सकने वाले और बिना बदलाव किए गए JDK को फिर से इंस्टॉल करें. Ubuntu का इस्तेमाल करने वाले लोगों पर असर डालने वाली एक ऐसी समस्या है जिसके बारे में हमें पता है. इसकी वजह से,
/etc/ssl/certs/java/cacertsखाली दिखता है. इस समस्या को हल करने के लिए, कमांड लाइन पर यह कमांड चलाएं:sudo /var/lib/dpkg/info/ca-certificates-java.postinst configure
नियोजित करना
इस सेक्शन में, कनेक्ट किए गए डिवाइस पर ऐप्लिकेशन को डिप्लॉय करने से जुड़ी समस्याओं के बारे में बताया गया है.
[सिर्फ़ Mac OS के लिए] /System/Volumes/Data में सेव किए गए प्रोजेक्ट पर Gradle फ़ाइल देखने से जुड़ी समस्या की वजह से, इंक्रीमेंटल अपडेट लागू नहीं होते
Gradle से जुड़ी समस्या 18149, Android Gradle प्लगिन के 7.0 और इसके बाद के वर्शन पर असर डालती है. इसकी वजह यह है कि इन वर्शन के लिए Gradle का 7.0 और इसके बाद का वर्शन ज़रूरी है. Gradle 7.0 और इसके बाद के वर्शन में, फ़ाइल देखने की सुविधा डिफ़ॉल्ट रूप से चालू होती है.
अगर Mac OS पर काम किया जा रहा है और आपका प्रोजेक्ट /System/Volumes/Data में सेव है, तो Gradle फ़ाइल वॉचिंग, फ़ाइल में किए गए बदलावों को ठीक से ट्रैक नहीं कर पाएगी.
इस वजह से, बिल्ड सिस्टम को फ़ाइल में किए गए कोई भी बदलाव नहीं दिखेंगे. इसलिए, वह APK को अपडेट नहीं करेगा. इसके बाद, इंक्रीमेंटल डिप्लॉयमेंट कोड कुछ नहीं करेगा, क्योंकि लोकल APK की स्थिति डिवाइस पर मौजूद APK की स्थिति जैसी ही है.
इस समस्या को हल करने के लिए, आपको अपने प्रोजेक्ट की डायरेक्ट्री को उपयोगकर्ता डायरेक्ट्री में ले जाना चाहिए. इसका मतलब है कि /Users/username में. इसके बाद, Gradle फ़ाइल वॉचिंग की मदद से, बिल्ड सिस्टम को फ़ाइल में हुए बदलावों के बारे में सही तरीके से सूचना दी जाएगी. साथ ही, इंक्रीमेंटल बदलावों को लागू किया जाएगा.
macOS High Sierra पर Android Emulator HAXM
macOS High Sierra (10.13) पर Android Emulator को macOS के साथ बेहतर तरीके से काम करने और स्थिरता के लिए, HAXM 6.2.1 या इसके बाद के वर्शन की ज़रूरत होती है. हालांकि, macOS 10.13 में HAXM जैसे कर्नेल एक्सटेंशन इंस्टॉल करने की प्रोसेस थोड़ी मुश्किल है. आपको कर्नल एक्सटेंशन को इंस्टॉल करने की अनुमति मैन्युअल तरीके से देनी होगी. इसके लिए, यह तरीका अपनाएं:
- सबसे पहले, एसडीके मैनेजर से HAXM का नया वर्शन इंस्टॉल करने की कोशिश करें.
- MacOS में, सिस्टम की सेटिंग > Security and Privacy पर जाएं.
अगर आपको यह सूचना दिखती है कि डेवलपर "Intel Corporation Apps" के सिस्टम सॉफ़्टवेयर को लोड होने से ब्लॉक कर दिया गया है, तो Allow पर क्लिक करें:

ज़्यादा जानकारी और समस्या हल करने के तरीकों के लिए, Apple का यह वेबपेज और समस्या 62395878 देखें.
बदलाव लागू करें
इस सेक्शन में, बदलाव लागू करें सुविधा से जुड़ी ऐसी समस्याओं के बारे में बताया गया है जिनके बारे में पहले से जानकारी है.
ऐप्लिकेशन का नया नाम लागू नहीं किया गया
अगर आपने अपने ऐप्लिकेशन का नाम बदला है और फिर उस बदलाव को लागू करने की कोशिश की है, तो हो सकता है कि अपडेट किया गया नाम न दिखे. इस समस्या को हल करने के लिए, Run
पर क्लिक करें. इससे आपका ऐप्लिकेशन फिर से डिप्लॉय हो जाएगा और आपको अपने बदलाव दिखेंगे.
Android रनटाइम में समस्या होने पर गड़बड़ी का मैसेज दिखता है
अगर Android 8.0 या 8.1 पर चलने वाले डिवाइस का इस्तेमाल किया जा रहा है, तो कुछ खास तरह के बदलाव लागू करने की कोशिश करने पर, आपको "VERIFICATION_ERROR" मैसेज दिख सकते हैं. खास तौर पर, Kotlin का इस्तेमाल करने पर ऐसा हो सकता है. यह मैसेज, Android रनटाइम से जुड़ी किसी समस्या की वजह से दिखता है. इसे Android 9.0 और इसके बाद के वर्शन में ठीक कर दिया गया है. इस समस्या की वजह से, 'बदलाव लागू करें' सुविधा काम नहीं करती. हालांकि, अपने बदलावों को देखने के लिए, अब भी ऐप्लिकेशन को फिर से चलाया
जा सकता है. हालांकि, हमारा सुझाव है कि आप डिवाइस को Android 9.0 या इसके बाद के वर्शन पर अपग्रेड करें.
डीबग करना और टेस्ट करना
इस सेक्शन में, आपके ऐप्लिकेशन को डीबग और टेस्ट करने से जुड़ी समस्याओं के बारे में बताया गया है.
Android Studio से JUnit टेस्ट चलाने पर, क्लासपाथ में संसाधन मौजूद नहीं होते
अगर आपके Java मॉड्यूल में खास रिसॉर्स फ़ोल्डर हैं, तो IDE से टेस्ट चलाने पर वे रिसॉर्स नहीं मिलेंगे. कमांड लाइन से Gradle का इस्तेमाल करके
टेस्ट चलाए जा सकते हैं. आईडीई से Gradle check टास्क को एक्ज़ीक्यूट करने पर भी यह काम करेगा. ज़्यादा जानकारी के लिए, समस्या 64887 देखें.
यह समस्या इसलिए होती है, क्योंकि IntelliJ 13 के बाद से, क्लासपाथ के तौर पर सिर्फ़ एक फ़ोल्डर होना ज़रूरी है. IntelliJ का बिल्डर, सभी संसाधनों को उस बिल्ड फ़ोल्डर में कॉपी करता है. हालांकि, Gradle संसाधनों को कॉपी नहीं करता.
- पहला तरीका: यूनिट टेस्ट चलाने के बजाय, IDE से Gradle
checkटास्क चलाएं. - दूसरा तरीका: अपनी बिल्ड स्क्रिप्ट को अपडेट करें, ताकि रिसॉर्स को बिल्ड फ़ोल्डर में मैन्युअल तरीके से कॉपी किया जा सके. ज़्यादा जानकारी के लिए, टिप्पणी #13 देखें.
JUnit टेस्ट चलाने पर, कोड को दो बार कंपाइल किया जा सकता है
नया प्रोजेक्ट बनाते समय, JUnit टेंप्लेट कॉन्फ़िगरेशन को "लॉन्च करने से पहले" वाले दो चरणों के साथ बनाया जा सकता है: Make और Gradle-aware Make. इसके बाद, यह कॉन्फ़िगरेशन JUnit के बनाए गए सभी रन कॉन्फ़िगरेशन में लागू हो जाता है.
- मौजूदा प्रोजेक्ट की समस्या को ठीक करने के लिए, Run > Edit Configurations पर क्लिक करें. इसके बाद, JUnit के डिफ़ॉल्ट कॉन्फ़िगरेशन को बदलें, ताकि उसमें सिर्फ़ Gradle-aware Make चरण शामिल हो.
- आने वाले समय में सभी प्रोजेक्ट के लिए इस समस्या को ठीक करने के लिए, फ़ाइल > प्रोजेक्ट बंद करें पर क्लिक करें. आपको वेलकम स्क्रीन दिखेगी. इसके बाद, Configure > Project Defaults > Run Configurations पर क्लिक करें. साथ ही, JUnit कॉन्फ़िगरेशन को बदलें, ताकि उसमें सिर्फ़ Gradle-aware Make चरण शामिल हो.
टेस्ट रन के कुछ कॉन्फ़िगरेशन काम नहीं करते
किसी टेस्ट मेथड पर राइट क्लिक करने पर उपलब्ध सभी रन कॉन्फ़िगरेशन मान्य नहीं होते. खास तौर पर, ये कॉन्फ़िगरेशन मान्य नहीं हैं:
- Gradle रन कॉन्फ़िगरेशन (जिनमें आइकॉन के तौर पर Gradle लोगो होता है) काम नहीं करते.
- JUnit रन कॉन्फ़िगरेशन (जिनमें हरे रंग के Android के बिना आइकॉन होता है) इंस्ट्रुमेंटेशन टेस्ट पर लागू नहीं होते. इन्हें लोकल जेवीएम पर नहीं चलाया जा सकता.
नेटिव कोड को डीबग करते समय Java ब्रेकपॉइंट जोड़ना
जब आपका ऐप्लिकेशन आपके नेटिव कोड में किसी ब्रेकपॉइंट पर रुका हो, तो हो सकता है कि ऑटो और ड्यूल डीबगर, आपके सेट किए गए नए Java ब्रेकपॉइंट को तुरंत न पहचानें. इस समस्या से बचने के लिए, डीबग सेशन शुरू करने से पहले या ऐप्लिकेशन के Java ब्रेकपॉइंट पर रुकने के दौरान, Java ब्रेकपॉइंट जोड़ें. ज़्यादा जानकारी के लिए, समस्या 229949 देखें.
नेटिव डीबगर से बाहर निकलना
Java और नेटिव कोड को डीबग करने के लिए, ऑटो या ड्यूअल डीबगर का इस्तेमाल करते समय, अगर आप अपने Java कोड से किसी नेटिव फ़ंक्शन में जाते हैं (उदाहरण के लिए, डीबगर आपके Java कोड की उस लाइन पर एक्ज़ीक्यूशन को रोक देता है जो नेटिव फ़ंक्शन को कॉल करती है और आप स्टेप इन
पर क्लिक करते हैं) और आपको अपने Java कोड पर वापस जाना है, तो प्रोग्राम फिर से शुरू करें
पर क्लिक करें (स्टेप आउट
या स्टेप ओवर
के बजाय). आपके ऐप्लिकेशन की प्रोसेस अब भी रुकी रहेगी. इसलिए, इसे फिर से शुरू करने के लिए, your-module-java टैब में प्रोग्राम फिर से शुरू करें
पर क्लिक करें. ज़्यादा जानकारी के लिए, समस्या
224385 देखें.
लाइब्रेरी लोड करते समय नेटिव डीबगर हैंग हो जाता है
Android Studio 4.2 और इसके बाद के वर्शन पर अपग्रेड करने के बाद, नेटिव डिबगर का पहली बार इस्तेमाल करने पर, हो सकता है कि Android डिवाइस से लाइब्रेरी लोड करते समय नेटिव डिबगर काम करना बंद कर दे. यह एक ऐसी समस्या है जो डीबगर को रोकने और रीस्टार्ट करने के बाद भी बनी रहती है. इस समस्या को ठीक करने के लिए,
$USER/.lldb/module-cache/ पर मौजूद LLDB कैश मेमोरी को मिटाएं.
नेटिव डीबगर क्रैश होने पर, "डीबगर प्रोसेस, एग्ज़िट कोड 127 के साथ खत्म हुई" मैसेज दिखता है
यह गड़बड़ी, नेटिव डीबगर को शुरू करते समय Linux पर आधारित प्लैटफ़ॉर्म पर होती है. इससे पता चलता है कि नेटिव डीबगर के लिए ज़रूरी लाइब्रेरी में से कोई एक लाइब्रेरी, लोकल सिस्टम पर इंस्टॉल नहीं है. ऐसा हो सकता है कि मौजूद न होने वाली लाइब्रेरी का नाम, idea.log फ़ाइल में पहले से ही प्रिंट हो. अगर ऐसा नहीं है, तो टर्मिनल का इस्तेमाल करके Android Studio की इंस्टॉलेशन डायरेक्ट्री पर जाएं. इसके बाद, bin/lldb/bin/LLDBFrontend --version कमांड लाइन को चलाकर जानें कि कौनसी लाइब्रेरी मौजूद नहीं हैं. आम तौर पर, ncurses5 लाइब्रेरी मौजूद नहीं होती है, क्योंकि Linux के हाल ही के कुछ डिस्ट्रिब्यूशन को पहले ही ncurses6 पर अपग्रेड कर दिया गया है.
प्रोफ़ाइलर
इस सेक्शन में, प्रोफ़ाइलर से जुड़ी समस्याओं के बारे में बताया गया है.
नेटिव मेमोरी प्रोफ़ाइलर: ऐप्लिकेशन के स्टार्टअप के दौरान प्रोफ़ाइलिंग की सुविधा उपलब्ध नहीं है
फ़िलहाल, ऐप्लिकेशन के स्टार्टअप के दौरान नेटिव मेमोरी प्रोफ़ाइलर उपलब्ध नहीं है. यह विकल्प, आने वाले अपडेट में उपलब्ध होगा.
इसके बजाय, स्टार्टअप प्रोफ़ाइलें कैप्चर करने के लिए, Perfetto स्टैंडअलोन कमांड-लाइन प्रोफ़ाइलर का इस्तेमाल किया जा सकता है.
सीपीयू प्रोफ़ाइलर में टाइम आउट वाली गड़बड़ियां
Sample Java Methods या Trace Java Methods कॉन्फ़िगरेशन चुनने पर, आपको Android Studio के सीपीयू प्रोफ़ाइलर में "रिकॉर्डिंग बंद नहीं हो सकी" गड़बड़ी दिख सकती है. ये गड़बड़ियां अक्सर टाइम आउट की वजह से होती हैं. खास तौर पर, तब जब आपको idea.log फ़ाइल में गड़बड़ी का यह मैसेज दिखता है:
Wait for ART trace file timed out
टाइम आउट की गड़बड़ियां, सैंपल किए गए तरीकों के मुकाबले ट्रेस किए गए तरीकों पर ज़्यादा असर डालती हैं. साथ ही, छोटी रिकॉर्डिंग के मुकाबले लंबी रिकॉर्डिंग पर ज़्यादा असर डालती हैं. कुछ समय के लिए, छोटी रिकॉर्डिंग करके देखें कि गड़बड़ी ठीक होती है या नहीं.
अगर आपको प्रोफ़ाइलर के साथ टाइम आउट की समस्याएं आ रही हैं, तो कृपया गड़बड़ी की शिकायत करें. इसमें आपके डिवाइसों के मेक/मॉडल और idea.log और logcat से जुड़ी कोई भी एंट्री शामिल होनी चाहिए.
डीबग या प्रोफ़ाइलिंग करते समय एडीबी से जुड़ी गड़बड़ी
Platform Tools 29.0.3 का इस्तेमाल करने पर, हो सकता है कि नेटिव डीबगिंग और Android Studio प्रोफ़ाइलर ठीक से काम न करें. साथ ही, सहायता > लॉग दिखाएं चुनने पर, आपको idea.log फ़ाइल में"AdbCommandRejectedException " या"पोर्ट कनेक्ट नहीं हो सका " दिख सकता है. प्लैटफ़ॉर्म टूल को 29.0.4 या इसके बाद के वर्शन पर अपग्रेड करने से, दोनों समस्याएं ठीक हो जाती हैं.
Platform Tools को अपग्रेड करने के लिए, यह तरीका अपनाएं:
- Android Studio में एसडीके मैनेजर खोलने के लिए, Tools > SDK Manager पर क्लिक करें या टूलबार में SDK Manager
पर क्लिक करें.
- Android SDK Platform-Tools के बगल में मौजूद चेकबॉक्स पर क्लिक करें, ताकि उस पर सही का निशान दिखे. बाईं ओर मौजूद कॉलम में, डाउनलोड आइकॉन
दिखना चाहिए.
- लागू करें या ठीक है पर क्लिक करें.
प्लगिन, बिल्ड आउटपुट विंडो को काम करने से रोकता है
CMake simple highlighter प्लग इन का इस्तेमाल करने से, कॉन्टेंट बिल्ड आउटपुट विंडो में नहीं दिखता. बिल्ड चलता है और बिल्ड आउटपुट टैब दिखता है, लेकिन कोई आउटपुट प्रिंट नहीं होता (समस्या #204791544).
इंस्टॉल करने का क्रम, लॉन्च होने से रोकता है
Android Studio के पुराने वर्शन से पहले नया वर्शन इंस्टॉल करने पर, हो सकता है कि पुराना वर्शन लॉन्च न हो. उदाहरण के लिए, अगर आपने पहले Android Studio का Canary वर्शन इंस्टॉल किया है और फिर स्टेबल वर्शन को इंस्टॉल और लॉन्च करने की कोशिश की है, तो हो सकता है कि स्टेबल वर्शन लॉन्च न हो. ऐसे मामलों में, आपको कैश मेमोरी मिटानी होगी, ताकि स्टेबल (पुराना) वर्शन लॉन्च हो सके. macOS पर, कैश मेमोरी मिटाने के लिए, Library/ApplicationSupport/Google/AndroidStudioversion_number डायरेक्ट्री को मिटाएं. Windows पर, कैश मेमोरी मिटाने के लिए डिस्क क्लीनअप का इस्तेमाल करें.
एस्प्रेसो टेस्ट रिकॉर्डर, Compose के साथ काम नहीं करता
एस्प्रेसो टेस्ट रिकॉर्डर, Compose का इस्तेमाल करने वाले प्रोजेक्ट के साथ काम नहीं करता. Compose वाले प्रोजेक्ट के लिए यूज़र इंटरफ़ेस (यूआई) टेस्ट बनाने के लिए, Compose लेआउट की जांच करना लेख पढ़ें.
Logcat के शॉर्टकट, अंग्रेज़ी के अलावा अन्य भाषाओं के कीबोर्ड लेआउट के साथ काम नहीं करते
अगर अंग्रेज़ी के अलावा किसी दूसरी भाषा के कीबोर्ड लेआउट का इस्तेमाल किया जा रहा है, तो हो सकता है कि Logcat का डिफ़ॉल्ट कीबोर्ड शॉर्टकट, लेआउट के साथ काम न करे. साथ ही, Android Studio में टेक्स्ट में बदलाव करते समय, आपको कुछ वर्ण टाइप करने में समस्या आए. इस समस्या को हल करने के लिए,
Logcat के उस कीमैप को मिटाएं या फिर से मैप करें जिससे समस्या हो रही है. Android Studio में Logcat के कीमैप में बदलाव करने के लिए, Android Studio > Settings > Keymap पर जाएं. इसके बाद, कीमैप की सूची में Logcat खोजें. ज़्यादा जानकारी के लिए, समस्या #263475910 देखें.
इस समस्या को ठीक करने के लिए, Android Studio Electric Eel Patch 1 से Logcat शॉर्टकट को हटा दिया जाएगा.
Android Gradle प्लगिन से जुड़ी सामान्य समस्याएं
इस सेक्शन में, Android Gradle प्लग-इन के नए और स्टेबल वर्शन में मौजूद उन समस्याओं के बारे में बताया गया है जिनके बारे में हमें पता है.
डाइनैमिक-फ़ीचर लाइब्रेरी की सभी डिपेंडेंसी की लिंट जांच नहीं की जाती
ऐप्लिकेशन मॉड्यूल से checkDependencies = true के साथ लिंट चलाते समय, डाइनैमिक-फ़ीचर लाइब्रेरी डिपेंडेंसी की जांच तब तक नहीं की जाती, जब तक वे ऐप्लिकेशन डिपेंडेंसी भी न हों (समस्या #191977888).
इसके बजाय, उन लाइब्रेरी पर लिंट टास्क चलाया जा सकता है.
नई लाइन शुरू करने के चिह्न वाले वर्णों के नाम वाली फ़ाइल पर हस्ताक्षर करना
JAR साइनिंग (v1 स्कीम) में, फ़ाइल के ऐसे नाम इस्तेमाल नहीं किए जा सकते जिनमें नई लाइन शुरू करने का चिह्न शामिल हो (समस्या #63885809).
ऐसा हो सकता है कि बिल्ड टाइम के दौरान, वैरिएंट आउटपुट में बदलाव करने की सुविधा काम न करे
वैरिएंट आउटपुट में बदलाव करने के लिए, Variant API का इस्तेमाल करने पर, नए प्लगिन के साथ गड़बड़ी होती है. यह अब भी आसान कामों के लिए काम करता है. जैसे, बिल्ड के समय APK का नाम बदलना, जैसा कि यहां दिखाया गया है:
// If you use each() to iterate through the variant objects, // you need to start using all(). That's because each() iterates // through only the objects that already exist during configuration time— // but those object don't exist at configuration time with the new model. // However, all() adapts to the new model by picking up object as they are // added during execution. android.applicationVariants.all { variant -> variant.outputs.all { outputFileName = "${variant.name}-${variant.versionName}.apk" } }
हालाँकि, ज़्यादा मुश्किल टास्क अब पूरे नहीं किए जा सकते. जैसे, outputFile ऑब्जेक्ट को ऐक्सेस करना. ऐसा इसलिए है, क्योंकि कॉन्फ़िगरेशन के दौरान, वैरिएंट के हिसाब से टास्क अब नहीं बनाए जाते. इस वजह से, प्लगिन को अपने सभी आउटपुट की जानकारी पहले से नहीं होती. हालांकि, इसका मतलब यह भी है कि कॉन्फ़िगरेशन में कम समय लगता है.
manifestOutputFile अब उपलब्ध नहीं है
processManifest.manifestOutputFile() तरीका अब उपलब्ध नहीं है. इसे कॉल करने पर, आपको यह गड़बड़ी दिखेगी:
A problem occurred configuring project ':myapp'. Could not get unknown property 'manifestOutputFile' for task ':myapp:processDebugManifest' of type com.android.build.gradle.tasks.ProcessManifest.
हर वैरिएंट के लिए मेनिफ़ेस्ट फ़ाइल पाने के लिए, manifestOutputFile() को कॉल करने के बजाय, processManifest.manifestOutputDirectory() को कॉल किया जा सकता है. इससे, जनरेट किए गए सभी मेनिफ़ेस्ट वाली डायरेक्ट्री का पाथ वापस मिल जाएगा. इसके बाद, मेनिफ़ेस्ट को ढूंढकर
उस पर अपना लॉजिक लागू किया जा सकता है. नीचे दिए गए सैंपल में, मेनिफ़ेस्ट में वर्शन कोड को डाइनैमिक तौर पर बदला गया है:
android.applicationVariants.all { variant -> variant.outputs.all { output -> output.processManifest.doLast { // Stores the path to the maifest. String manifestPath = "$manifestOutputDirectory/AndroidManifest.xml" // Stores the contents of the manifest. def manifestContent = file(manifestPath).getText() // Changes the version code in the stored text. manifestContent = manifestContent.replace('android:versionCode="1"', String.format('android:versionCode="%s"', generatedCode)) // Overwrites the manifest with the new text. file(manifestPath).write(manifestContent) } } }
AGP 7.3.0 के एआईडीएल सपोर्ट और Kotlin 1.7.x से जुड़ी समस्याएं
Kotlin 1.7.x में KAPT के साथ AGP 7.3.0 का इस्तेमाल करने पर, बिल्ड के कुछ वैरिएंट के लिए AIDL सोर्स सेट हट जाते हैं. हालांकि, अन्य एआईडीएल सोर्स सेट का इस्तेमाल अब भी किया जा सकता है. इनमें main/, बिल्ड टाइप, ऐप्लिकेशन टाइप, और ऐप्लिकेशन टाइप के कॉम्बिनेशन शामिल हैं. अगर आपको वैरिएंट के हिसाब से एआईडीएल सोर्स सेट इस्तेमाल करने हैं, तो Kotlin 1.6.21 का इस्तेमाल जारी रखें.
पहले से मालूम समस्याओं को ठीक किया गया
इस सेक्शन में, उन समस्याओं के बारे में बताया गया है जिन्हें हाल ही की रिलीज़ में ठीक किया गया है. अगर आपको इनमें से कोई समस्या आ रही है, तो आपको Android Studio को नए स्टेबल या वर्शन की झलक पर अपडेट करना चाहिए.
Android Studio Rabbit 1 Canary 5 में ठीक किया गया
- पैरलल Gradle सिंक की सुविधा: Android Studio Quail 1 में, Gradle के 9.4 या इसके बाद के वर्शन का इस्तेमाल करने पर,
gradle.propertiesमें मौजूदorg.gradle.parallel=trueप्रॉपर्टी, Gradle सिंक के दौरान पैरलल मॉडल फ़ेच करने की सुविधा को चालू नहीं करती. इसकी वजह से, बड़े प्रोजेक्ट को सिंक करने में ज़्यादा समय लगता था. नईorg.gradle.tooling.parallelप्रॉपर्टी, पैरलल मॉडल फ़ेचिंग को चालू कर देगी. हालांकि, यह IDEA के मॉडल बिल्डर के लिए चालू नहीं होगी. यह पाबंदी हटा दी गई है.
Android Studio 2021.1.1 में ठीक किया गया
- लिंट आउटपुट मौजूद नहीं है: लिंट टास्क
UP-TO-DATEहोने पर,stdoutमें कोई लिंट टेक्स्ट आउटपुट प्रिंट नहीं होता (समस्या #191897708). AGP 7.1.0-alpha05 में ठीक किया गया. - Hilt प्लग इन का इस्तेमाल करने वाले ऐप्लिकेशन प्रोजेक्ट की यूनिट टेस्टिंग से जुड़ी समस्याएं: यूनिट टेस्ट क्लासपाथ में, बिना इंस्ट्रुमेंट वाली ऐप्लिकेशन क्लास शामिल होती हैं. इसका मतलब है कि यूनिट टेस्ट चलाते समय, डिपेंडेंसी इंजेक्शन को मैनेज करने के लिए, Hilt ऐप्लिकेशन क्लास को इंस्ट्रुमेंट नहीं करता (समस्या #213534628). इसे एजीपी 7.1.1 में ठीक किया गया.
Android Studio 2020.3.1 में ठीक किया गया
- Kotlin प्रोजेक्ट में लिंट से जुड़े अपवाद:
checkDependencies = trueसेट करने वाले Kotlin प्रोजेक्ट में, null pointer exception या गड़बड़ियां (समस्या #158777858) आ सकती हैं.
Android Studio 4.2 में ठीक की गई गड़बड़ियां
- macOS Big Sur पर आईडीई फ़्रीज़ हो जाता है: कोई डायलॉग बॉक्स खोलने पर, Android Studio 4.1 फ़्रीज़ हो सकता है.
Android Studio 4.1 में ठीक किया गया
- आईडीई के पिछले वर्शन की मेमोरी सेटिंग लागू करने के लिए रीस्टार्ट करें: Android Studio को अपडेट करने के बाद, आपको Android Studio को रीस्टार्ट करना होगा, ताकि आईडीई के पिछले वर्शन से माइग्रेट की गई मेमोरी सेटिंग लागू की जा सकें.
- कस्टम अनुमति स्ट्रिंग वाली मेनिफ़ेस्ट क्लास, अब डिफ़ॉल्ट रूप से जनरेट नहीं होती: अगर आपको क्लास जनरेट करनी है, तो
android.generateManifestClass = trueसेट करें.
Android Studio 3.6 में ठीक किया गया
LineageOS पर APK इंस्टॉल करने से जुड़ी गड़बड़ी: LineageOS या CyanogenMod के कुछ वर्शन पर चलने वाले डिवाइसों पर, आपके ऐप्लिकेशन को डिप्लॉय करने में गड़बड़ी हो सकती है. साथ ही,
INSTALL_PARSE_FAILED_NOT_APKअपवाद दिख सकता है.Android Studio 3.6 Beta 1 और इसके बाद के वर्शन पर, IDE इस अपवाद को मैनेज करता है. इसके लिए, LineageOS या CyanogenMod डिवाइसों पर ऐप्लिकेशन को डिप्लॉय करते समय, ऐप्लिकेशन को पूरी तरह से इंस्टॉल किया जाता है. इस वजह से, डिप्लॉय होने में ज़्यादा समय लग सकता है.
Android Studio 3.5.2 में ठीक किया गया
- एक्सएमएल कोड का स्टाइल काम नहीं कर रहा है: एक्सएमएल कोड में बदलाव करते समय, IDE ने गलत कोड स्टाइल लागू किया. ऐसा तब हुआ, जब आपने मेन्यू बार से कोड > कोड को फिर से फ़ॉर्मैट करें को चुना.
Android Studio 3.3.1 में ठीक किया गया
C++ पर आधारित प्रोजेक्ट स्कैन करते समय, आउट ऑफ़ मेमोरी से जुड़ी गड़बड़ियां: जब Gradle किसी ऐसे प्रोजेक्ट को स्कैन करता है जिसमें एक ही ड्राइव पर एक से ज़्यादा जगहों पर C++ कोड मौजूद होता है, तो स्कैन में पहली कॉमन डायरेक्ट्री के नीचे मौजूद सभी डायरेक्ट्री शामिल होती हैं. कई डायरेक्ट्री और फ़ाइलों को स्कैन करने से, आउट ऑफ़ मेमोरी गड़बड़ियां हो सकती हैं.
इस समस्या के बारे में ज़्यादा जानने के लिए, इससे जुड़ा बग पढ़ें.