Android Studio और Android Gradle प्लग इन की पहले से मालूम समस्याएं

यह पेज Android StudioLadybug और Android Gradle प्लग इन 8.7.0 की ज्ञात समस्याओं को ट्रैक करता है. अगर आपको कोई ऐसी समस्या आती है जो यहां नहीं दी गई है, तो कृपया गड़बड़ी की शिकायत करें.

झलक के लिए अपग्रेड करना: Android Studio और 'Android Gradle प्लग इन' की हर रिलीज़ का मकसद, ऐप्लिकेशन को क्रैश या फ़्रीज़ होने से बचाने और परफ़ॉर्मेंस को बेहतर बनाने के साथ-साथ नई सुविधाएं जोड़ना है. आने वाले समय में रिलीज़ होने वाले वर्शन के फ़ायदे पाने के लिए, Android Studio की झलक डाउनलोड और इंस्टॉल करें.

Android Studio से जुड़ी समस्याएं

इस सेक्शन में, उन समस्याओं के बारे में बताया गया है जो Android Studio के नए और स्टेबल वर्शन में मौजूद हैं.

'बदलाव लागू करें और गतिविधि को रीस्टार्ट करें' विकल्प, एपीआई लेवल 35 वाले डिवाइसों या एम्युलेटर पर गतिविधि को रीस्टार्ट नहीं करता

जब 'बदलाव लागू करें और गतिविधि रीस्टार्ट करें' वाले एपीआई 35 डिवाइस पर कोड में बदलाव डिप्लॉय किए जाते हैं, तो ऐप्लिकेशन रीस्टार्ट नहीं होगा और आपको इन बदलावों का कोई असर नहीं दिखेगा. ऐप्लिकेशन को फिर से चलाने पर, आपको कोड में किए गए बदलावों का असर दिखेगा. हमारी टीम इसकी जांच कर रही है.

Firebase सहायता विंडो में गड़बड़ी का मैसेज दिखता है

अगर Firebase सहायता विंडो (मुख्य मेन्यू में टूल > Firebase) में गड़बड़ी का कोई मैसेज दिखता है, तो गड़बड़ी को ठीक करने के लिए कैश मेमोरी को अमान्य करें और Android Studio को रीस्टार्ट करें.

लेआउट इंस्पेक्टर का इस्तेमाल करके, किसी व्यू को अलग नहीं किया जा सकता

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

लेआउट इंस्पेक्टर का इस्तेमाल करके, 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 दिख रहा है, तो अपने मॉड्यूल में debugImplementation डिपेंडेंसी को androidx.customview:customview-poolingcontainer में शामिल करना न भूलें.

पासकोड और कीस्टोर के लिए अलग-अलग पासवर्ड इस्तेमाल करने पर गड़बड़ी

Android Studio 4.2 से, यह JDK 11 पर काम करता है. इस अपडेट की वजह से, साइनिंग पासकोड के काम करने के तरीके में बदलाव होता है.

बिल्ड > हस्ताक्षर किया गया बंडल / APK जनरेट करें पर जाकर, किसी ऐप्लिकेशन बंडल या APK के लिए ऐप्लिकेशन साइनिंग को कॉन्फ़िगर करने पर, पासकोड और पासकोड स्टोर के लिए अलग-अलग पासवर्ड डालने पर, गड़बड़ी का यह मैसेज दिख सकता है:

Key was created with errors:
Warning: Different store and Key passwords not supported for PKCS12 Key stores

इस समस्या को हल करने के लिए, पासकोड को पासकोड और पासकोड स्टोर, दोनों के लिए एक ही रखें.

Android Studio 4.2 इंस्टॉल करने के बाद, वह शुरू नहीं होता

Studio, JDK 11 के इस्तेमाल किए जाने वाले गै़रबेज कलेक्टर के साथ काम करने के लिए, पिछले .vmoptions को इंपोर्ट करने और उन्हें साफ़ करने की कोशिश करता है. अगर यह प्रोसेस पूरी नहीं होती है, तो हो सकता है कि .vmoptions फ़ाइल में कस्टम वर्चुअल मशीन (वीएम) के विकल्प सेट करने वाले कुछ उपयोगकर्ताओं के लिए, IDE शुरू न हो.

हमारा सुझाव है कि इस समस्या को हल करने के लिए, .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)

इस समस्या को ठीक करने के लिए, टूल > SDK Manager पर जाएं और अपने Android 11 एम्युलेटर को वर्शन 9 या उसके बाद वाले वर्शन पर अपग्रेड करें. SDK प्लैटफ़ॉर्म टैब में, पैकेज की जानकारी दिखाएं लेबल वाले बॉक्स को चुनें. इसके बाद, Android 11 एम्युलेटर के वर्शन 9 या उसके बाद वाले वर्शन को चुनें.

अपग्रेड करने के बाद 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.1

• macOS: ~/Library/Application Support/Google/AndroidStudio<version>
  उदाहरण: ~/Library/Application Support/Google/AndroidStudio4.1

• Linux: ~/.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\config

• macOS: ~/Library/Preferences/AndroidStudio<version>
  उदाहरण: ~/Library/Preferences/AndroidStudio3.6

• Linux: ~/.AndroidStudio<version>/config
  उदाहरण: ~/.AndroidStudio3.6/config

ध्यान दें कि Android Studio की कैनरी और बीटा रिलीज़ की कॉन्फ़िगरेशन डायरेक्ट्री <version> के लिए X.Y के बजाय PreviewX.Y है. उदाहरण के लिए, Android Studio 4.1 कैनरी बिल्ड में रिलीज़ के उम्मीदवारों और स्टेबल रिलीज़ के लिए इस्तेमाल होने वाली AndroidStudio4.1 डायरेक्ट्री के बजाय, AndroidStudioPreview4.1 का इस्तेमाल किया जाता है.

Kotlin मल्टीप्लैटफ़ॉर्म प्रोजेक्ट में कंपाइलेशन की समस्या

सिंबल मौजूद न होने की वजह से, Kotlin MPP कोड में कंपाइलेशन से जुड़ी गड़बड़ियां हो सकती हैं. Kotlin प्लग इन को 1.4 वर्शन में अपग्रेड करने से, यह समस्या ठीक हो जाएगी.

Linux पर की-मैपिंग से जुड़ी समस्याएं

Linux पर, कुछ कीबोर्ड शॉर्टकट, Linux के डिफ़ॉल्ट कीबोर्ड शॉर्टकट और KDE और GNOME जैसे लोकप्रिय विंडो मैनेजर के कीबोर्ड शॉर्टकट से मेल नहीं खाते. हो सकता है कि Android Studio में, एक जैसे कीबोर्ड शॉर्टकट उम्मीद के मुताबिक काम न करें.

इस समस्या के बारे में ज़्यादा जानकारी (इसमें संभावित समाधान भी शामिल हैं) मिल सकती है. यह जानकारी InteliJ के गड़बड़ी ट्रैकर में मिल सकती है.

ChromeOS पर यूज़र इंटरफ़ेस (यूआई) का छोटा टेक्स्ट

ChromeOS पर, टेक्स्ट पिछले वर्शन के मुकाबले काफ़ी छोटा दिख सकता है. इस समस्या को हल करने के लिए, यह तरीका अपनाएं:

1. फ़ाइल > सेटिंग पर क्लिक करके, सेटिंग विंडो खोलें
2. दिखने का तरीका और व्यवहार > दिखने का तरीका पर जाएं.
3. पसंद के मुताबिक फ़ॉन्ट का इस्तेमाल करें को चुनें.
4. फ़ॉन्ट का साइज़ बढ़ाएं.
5. सेटिंग विंडो में, एडिटर > फ़ॉन्ट पर जाएं.
6. फ़ॉन्ट का साइज़ बढ़ाएं.
7. ठीक है पर क्लिक करें.

कोड में बदलाव करना

इस सेक्शन में, कोड एडिटर से जुड़ी आम समस्याओं के बारे में बताया गया है.

कीबोर्ड इनपुट फ़्रीज़ हो गया - Linux पर "iBus" से जुड़ी समस्याएं

Linux और Android Studio पर iBus डेमन के बीच कुछ इंटरैक्शन होते हैं. कुछ मामलों में, IDE कीबोर्ड इनपुट का जवाब देना बंद कर देता है या अपने-आप वर्ण डालना शुरू कर देता है. यह गड़बड़ी, iBus और XLib + AWT के बीच कुछ सिंक न होने की वजह से ट्रिगर हुई है. साथ ही, JetBrains और iBus में, अपस्ट्रीम की रिपोर्ट पहले ही भेज दी गई है. इस समस्या को हल करने के लिए, फ़िलहाल ये तीन तरीके अपनाए जा सकते हैं:

• पहला तरीका: iBus को सिंक्रोनस मोड में ज़बरदस्ती डालें. Android Studio शुरू करने से पहले, कमांड लाइन पर ये निर्देश चलाएं:

  $ IBUS_ENABLE_SYNC_MODE=1 ibus-daemon -xrd

• दूसरा तरीका: Android Studio में iBus इनपुट बंद करें. सिर्फ़ Android Studio के लिए iBus इनपुट को बंद करने के लिए, कमांड लाइन पर यह चलाएं:

  $ XMODIFIERS= ./bin/studio.sh

  यह तरीका सिर्फ़ Android Studio के लिए इनपुट के तरीकों को बंद करता है, न कि आपके किसी भी दूसरे ऐप्लिकेशन के लिए. ध्यान दें कि अगर Android 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 सिंक या SDK Manager से "पियर की पुष्टि नहीं की गई" गड़बड़ियां

इन गड़बड़ियों की मुख्य वजह यह है कि $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 का इस्तेमाल करने के लिए, HAXM 6.2.1 या इसके बाद के वर्शन की ज़रूरत होती है. इससे macOS के साथ बेहतर तरीके से काम करने और स्थिरता बनी रहती है. हालांकि, macOS 10.13 में HAXM जैसे कर्नेल एक्सटेंशन इंस्टॉल करने की प्रोसेस ज़्यादा मुश्किल है. आपको मैन्युअल तरीके से, कर्नेल एक्सटेंशन को इस तरह से इंस्टॉल करने की अनुमति देनी होगी:

1. सबसे पहले, SDK Manager से HAXM का नया वर्शन इंस्टॉल करने की कोशिश करें.
2. macOS में, System Preferences > Security and Privacy पर जाएं.

3. अगर आपको सूचना मिलती है कि डेवलपर "Intel Corporation ऐप्लिकेशन" के सिस्टम सॉफ़्टवेयर को लोड करने से रोका गया है, तो अनुमति दें पर क्लिक करें:

   

ज़्यादा जानकारी और समस्या को हल करने के तरीके के लिए, Apple का यह वेबपेज और समस्या 62395878 देखें.

बदलाव लागू करें

इस सेक्शन में, बदलाव लागू करें से जुड़ी समस्याओं के बारे में बताया गया है.

ऐप्लिकेशन का नया नाम लागू नहीं हुआ

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

Android रनटाइम में समस्या होने पर गड़बड़ी का मैसेज दिखना

अगर Android 8.0 या 8.1 वाले डिवाइस का इस्तेमाल किया जा रहा है, तो कुछ खास तरह के बदलाव लागू करने के दौरान आपको "VERIFICATION_ERROR" मैसेज दिख सकते हैं. ऐसा खास तौर पर, Kotlin का इस्तेमाल करने पर होता है. यह मैसेज, Android Runtime से जुड़ी किसी समस्या की वजह से दिखता है. इसे Android 9.0 और उसके बाद के वर्शन में ठीक कर दिया गया है. इस समस्या की वजह से, 'बदलाव लागू करें' विकल्प काम नहीं करता. हालांकि, बदलावों को देखने के लिए, अपने ऐप्लिकेशन को फिर से चालू करें. हालांकि, हमारा सुझाव है कि आप अपने डिवाइस को Android 9.0 या इसके बाद के वर्शन पर अपग्रेड करें.

डीबग करना और जांच करना

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

Android Studio से चलाने पर JUnit, क्लासपाथ में गायब संसाधनों की जांच करता है

अगर आपके Java मॉड्यूल में खास संसाधन फ़ोल्डर हैं, तो IDE से टेस्ट चलाने पर वे संसाधन नहीं मिलेंगे. कमांड लाइन से Gradle का इस्तेमाल करके टेस्ट चलाने पर, यह काम करेगा. IDE से check टास्क को एक्ज़ीक्यूट करने पर भी काम हो जाएगा. ज़्यादा जानकारी के लिए, समस्या 64887 देखें.

यह समस्या इसलिए होती है, क्योंकि IntelliJ 13 के लिए ज़रूरी है कि आपके पास क्लासपाथ के तौर पर सिर्फ़ एक फ़ोल्डर हो. IntelliJ का बिल्डर, सभी संसाधनों को उस बिल्ड फ़ोल्डर में कॉपी करता है, लेकिन Gradle, संसाधनों को कॉपी नहीं करता.

• पहला तरीका: यूनिट टेस्ट चलाने के बजाय, IDE से Gradle check टास्क चलाएं.
• दूसरा तरीका: अपनी बिल्ड स्क्रिप्ट को अपडेट करके, संसाधनों को मैन्युअल तरीके से बिल्ड फ़ोल्डर में कॉपी करें. ज़्यादा जानकारी के लिए, टिप्पणी #13 देखें.

JUnit की जांच करने पर, कोड को दो बार कंपाइल किया जा सकता है

नया प्रोजेक्ट बनाते समय, टेंप्लेट JUnit कॉन्फ़िगरेशन को "लॉन्च से पहले" के दो चरणों के साथ बनाया जा सकता है: Make और Gradle-aware Make. इसके बाद, इस कॉन्फ़िगरेशन को बनाए गए सभी JUnit रन कॉन्फ़िगरेशन में लागू कर दिया जाता है.

• मौजूदा प्रोजेक्ट की समस्या को ठीक करने के लिए, रन > कॉन्फ़िगरेशन में बदलाव करें पर क्लिक करें. इसके बाद, डिफ़ॉल्ट JUnit कॉन्फ़िगरेशन को बदलकर, सिर्फ़ Gradle-अवेयर 'बनाएं चरण' को शामिल करें.
• आने वाले समय में होने वाली समस्याओं को ठीक करने के लिए, फ़ाइल > प्रोजेक्ट बंद करें पर क्लिक करें. आपको वेलकम स्क्रीन दिखेगी. इसके बाद, कॉन्फ़िगर करें > प्रोजेक्ट के डिफ़ॉल्ट > रन कॉन्फ़िगरेशन पर क्लिक करें. साथ ही, JUnit कॉन्फ़िगरेशन में बदलाव करके, सिर्फ़ Gradle के साथ काम करने वाले Make चरण को शामिल करें.

टेस्ट रन के कुछ कॉन्फ़िगरेशन काम नहीं करते

टेस्ट के तरीके पर राइट क्लिक करने पर, सभी रन कॉन्फ़िगरेशन मान्य नहीं होते. खास तौर पर, ये कॉन्फ़िगरेशन अमान्य हैं:

• Gradle रन कॉन्फ़िगरेशन (इसमें आइकॉन के तौर पर Gradle का लोगो होता है) काम नहीं करती.
• JUnit रन कॉन्फ़िगरेशन (जिसमें हरे रंग का Android वाला आइकॉन नहीं होता है) ऐसे इंस्ट्रुमेंटेशन टेस्ट पर लागू नहीं होते जो स्थानीय JVM पर नहीं चलाए जा सकते.

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

नेटिव कोड को डीबग करते समय, Java ब्रेकपॉइंट जोड़ना

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

नेटिव डीबगर से बाहर निकलना

Java और नेटिव कोड को डीबग करने के लिए, ऑटो या ड्यूअल डीबगर का इस्तेमाल करते समय, अगर आपने अपने Java कोड से किसी नेटिव फ़ंक्शन में स्टैप इन किया है (उदाहरण के लिए, डीबगर आपके Java कोड में उस लाइन पर प्रोसेस को रोक देता है जो किसी नेटिव फ़ंक्शन को कॉल करता है और आपने Step Into पर क्लिक किया है), तो अपने Java कोड पर वापस जाने के लिए, Step Out या Step Over के बजाय, Resume Program पर क्लिक करें. आपके ऐप्लिकेशन की प्रोसेस अब भी रुकी हुई होगी. इसलिए, उसे फिर से शुरू करने के लिए, your-module-java टैब में Resume Program पर क्लिक करें. ज़्यादा जानकारी के लिए, समस्या 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 स्टैंडअलोन कमांड-लाइन प्रोफ़ाइलर का इस्तेमाल किया जा सकता है.

सीपीयू प्रोफ़ाइलर में टाइम आउट की गड़बड़ियां

Java के सैंपल तरीके या Java के तरीके ट्रैक करें कॉन्फ़िगरेशन चुनने पर, आपको Android Studio के सीपीयू प्रोफ़ाइलर में "रिकॉर्डिंग बंद नहीं हो सकी" गड़बड़ियां दिख सकती हैं. ये अक्सर टाइम आउट की गड़बड़ियां होती हैं. खास तौर पर, अगर आपको idea.log फ़ाइल में गड़बड़ी का यह मैसेज दिखता है, तो:

Wait for ART trace file timed out

टाइम आउट की गड़बड़ियां, सैंपल किए गए तरीकों के मुकाबले ट्रैक किए गए तरीकों पर ज़्यादा असर डालती हैं. साथ ही, छोटी रिकॉर्डिंग के मुकाबले लंबी रिकॉर्डिंग पर ज़्यादा असर डालती हैं. कुछ समय के लिए, कम अवधि की रिकॉर्डिंग करके देखें कि क्या गड़बड़ी ठीक हो जाती है.

अगर आपको प्रोफ़ाइलर में टाइम आउट से जुड़ी समस्याएं आ रही हैं, तो कृपया गड़बड़ी की शिकायत करें. इसमें आपके डिवाइस का ब्रैंड/मॉडल और idea.log और logcat से मिली काम की जानकारी शामिल होनी चाहिए.

डीबग करने या प्रोफ़ाइल बनाने के दौरान ADB से जुड़ी गड़बड़ी

Platform Tools 29.0.3 का इस्तेमाल करने पर, हो सकता है कि नेटिव डीबगिंग और Android Studio के प्रोफ़ाइलर ठीक से काम न करें. साथ ही, सहायता > लॉग दिखाएं को चुनने पर, आपको idea.log फ़ाइल में "AdbCommandRejectedException" या "पोर्ट कनेक्ट नहीं हो सका" दिख सकता है. प्लैटफ़ॉर्म टूल को 29.0.4 या उसके बाद के वर्शन पर अपग्रेड करने से, दोनों ही समस्याएं ठीक हो जाती हैं.

Platform Tools को अपग्रेड करने के लिए, यह तरीका अपनाएं:

1. Android Studio में SDK Manager खोलने के लिए, टूल > SDK Manager पर क्लिक करें. इसके अलावा, टूलबार में SDK Manager पर भी क्लिक किया जा सकता है.
2. Android SDK Platform-Tools के बगल में मौजूद चेकबॉक्स पर क्लिक करें, ताकि उस पर सही का निशान दिखे. बाईं ओर मौजूद कॉलम में, डाउनलोड आइकॉन दिखेगा.
3. लागू करें या ठीक है पर क्लिक करें.

प्लग इन बिल्ड आउटपुट विंडो को काम करने से रोकता है

CMake सिंपल हाइलाइटर प्लग इन का इस्तेमाल करने पर, कॉन्टेंट को बिल्ड आउटपुट विंडो में नहीं दिखाया जाता. बिल्ड चलता है और बिल्ड आउटपुट टैब दिखता है, लेकिन कोई आउटपुट नहीं दिखता (समस्या #204791544).

इंस्टॉल करने के क्रम की वजह से ऐप्लिकेशन लॉन्च नहीं हो पा रहा है

Android Studio के पुराने वर्शन से पहले नया वर्शन इंस्टॉल करने पर, हो सकता है कि पुराना वर्शन लॉन्च न हो. उदाहरण के लिए, अगर आपने सबसे पहले Android Studio का कैनरी वर्शन इंस्टॉल किया है और फिर स्टैबल वर्शन को इंस्टॉल और लॉन्च करने की कोशिश की है, तो हो सकता है कि स्टैबल वर्शन लॉन्च न हो. ऐसे मामलों में, आपको कैश मेमोरी मिटानी होगी, ताकि स्टेबल (पुराना) वर्शन लॉन्च हो सके. macOS पर, कैश मेमोरी मिटाने के लिए, Library/ApplicationSupport/Google/AndroidStudioversion_number डायरेक्ट्री को मिटाएं. Windows पर, कैश मेमोरी मिटाने के लिए डिस्क क्लीनअप का इस्तेमाल करें.

Espresso Test Recorder, Compose के साथ काम नहीं करता

Espresso टेस्ट रिकॉर्डर, उन प्रोजेक्ट के साथ काम नहीं करता जिनमें Compose शामिल है. Compose का इस्तेमाल करने वाले प्रोजेक्ट के लिए यूज़र इंटरफ़ेस (यूआई) टेस्ट बनाने के लिए, Compose लेआउट की जांच करना लेख पढ़ें.

Logcat शॉर्टकट, अंग्रेज़ी के अलावा किसी अन्य भाषा के कीबोर्ड लेआउट के साथ काम नहीं करता

अगर अंग्रेज़ी के अलावा किसी अन्य भाषा के कीबोर्ड लेआउट का इस्तेमाल किया जा रहा है, तो हो सकता है कि Logcat का डिफ़ॉल्ट कीबोर्ड शॉर्टकट, लेआउट के साथ काम न करे. साथ ही, Android Studio में टेक्स्ट में बदलाव करते समय, कुछ वर्ण टाइप न हो पाएं. इस समस्या को हल करने के लिए, Logcat के उस कीमैप को मिटाएं या फिर से मैप करें जिससे समस्या आ रही है. Android Studio में Logcat कीबोर्ड मैप में बदलाव करने के लिए, Android Studio > सेटिंग > कीबोर्ड मैप पर जाएं. इसके बाद, कीबोर्ड मैप की सूची में Logcat खोजें. ज़्यादा जानकारी के लिए, समस्या #263475910 देखें.

Android Studio Electric Eel पैच 1 में Logcat शॉर्टकट हटाने से, यह समस्या हल हो जाएगी.

Android Gradle प्लग इन से जुड़ी समस्याएं

इस सेक्शन में, Android Gradle प्लग-इन के सबसे नए वर्शन में मौजूद समस्याओं के बारे में बताया गया है.

डाइनैमिक-फ़ीचर लाइब्रेरी की सभी डिपेंडेंसी की जांच, लिंट की मदद से नहीं की जाती

किसी ऐप्लिकेशन मॉड्यूल से checkDependencies = true के साथ lint चलाने पर, डाइनैमिक-फ़ीचर लाइब्रेरी डिपेंडेंसी की जांच तब तक नहीं की जाती, जब तक वे ऐप्लिकेशन डिपेंडेंसी भी न हों (समस्या #191977888). इस समस्या को हल करने के लिए, उन लाइब्रेरी पर लिंट टास्क चलाया जा सकता है.

नई हस्ताक्षर फ़ाइल का नाम, नई लाइन शुरू करने के वर्णों के साथ दिया गया है

JAR साइनिंग (v1 स्कीम) में, फ़ाइल के ऐसे नाम इस्तेमाल नहीं किए जा सकते जिनमें कैरिज रिटर्न वर्ण हों (समस्या #63885809).

हो सकता है कि बिल्ड के समय वैरिएंट के आउटपुट में बदलाव करने से काम न हो

नए प्लग इन के साथ, वैरिएंट के आउटपुट में बदलाव करने के लिए, वैरिएंट एपीआई का इस्तेमाल नहीं किया जा सकता. हालांकि, यह अब भी आसान टास्क के लिए काम करता है. जैसे, 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 AIDL के साथ काम करने और Kotlin 1.7.x से जुड़ी समस्याएं

Kotlin 1.7.x में KAPT के साथ एजीपी 7.3.0 का इस्तेमाल करने से, खास बिल्ड वैरिएंट के लिए एआईडीएल सोर्स सेट हट जाते हैं. हालांकि, अब भी अन्य AIDL सोर्स सेट का इस्तेमाल किया जा सकता है. इनमें main/, बिल्ड टाइप, प्रॉडक्ट फ़्लेवर, और प्रॉडक्ट फ़्लेवर के कॉम्बिनेशन शामिल हैं. अगर आपको खास वैरिएंट के लिए एआईडीएल सोर्स सेट का इस्तेमाल करना है, तो Kotlin 1.6.21 का इस्तेमाल करना जारी रखें.

पहले से मालूम समस्याएं ठीक की गईं

इस सेक्शन में, ऐसी समस्याओं के बारे में बताया गया है जिन्हें हाल ही में रिलीज़ किए गए वर्शन में ठीक किया गया है. अगर आपको इनमें से कोई भी समस्या आ रही है, तो आपको Android Studio को नए स्टेबल या झलक दिखाने वाले वर्शन में अपडेट करना चाहिए.

Android Studio 2021.1.1 में ठीक किया गया

• लिंट आउटपुट मौजूद नहीं है: लिंट टास्क UP-TO-DATE होने पर, stdout में कोई लिंट टेक्स्ट आउटपुट नहीं दिखता है (समस्या #191897708). इसे AGP 7.1.0-alpha05 में ठीक कर दिया गया है.
• Hilt प्लग इन का इस्तेमाल करने वाले ऐप्लिकेशन प्रोजेक्ट की यूनिट टेस्टिंग से जुड़ी समस्याएं: यूनिट टेस्ट क्लासपाथ में, ऐसी ऐप्लिकेशन क्लास शामिल होती हैं जिनमें इंस्ट्रूमेंट नहीं होते. इसका मतलब है कि यूनिट टेस्ट चलाते समय, Hilt ऐप्लिकेशन क्लास को इंस्ट्रूमेंट नहीं करता, ताकि डिपेंडेंसी इंजेक्शन को मैनेज किया जा सके (समस्या #213534628). AGP 7.1.1 में ठीक किया गया.

Android Studio 2020.3.1 में ठीक किया गया

• Kotlin प्रोजेक्ट में Lint से जुड़ी गड़बड़ियां: checkDependencies = true सेट करने वाले Kotlin प्रोजेक्ट में, शून्य पॉइंटर की गड़बड़ियां या गड़बड़ियां दिख सकती हैं (समस्या #158777858).

Android Studio 4.2 में ठीक किया गया

• macOS Big Sur पर IDE फ़्रीज़ हो जाता है: कोई डायलॉग खोलने पर, Android Studio 4.1 फ़्रीज़ हो सकता है.

Android Studio 4.1 में ठीक किया गया

• IDE के पिछले वर्शन से मेमोरी सेटिंग लागू करने के लिए रीस्टार्ट करें: Android Studio को अपडेट करने के बाद, आपको IDE के पिछले वर्शन से माइग्रेट की गई किसी भी मेमोरी सेटिंग को लागू करने के लिए, Android Studio को रीस्टार्ट करना होगा.
• कस्टम अनुमति स्ट्रिंग वाली मेनिफ़ेस्ट क्लास अब डिफ़ॉल्ट रूप से जनरेट नहीं होती: अगर आपको क्लास जनरेट करनी है, तो android.generateManifestClass = true सेट करें.

Android Studio 3.6 में ठीक किया गया

• LineageOS पर APK इंस्टॉल करने से जुड़ी गड़बड़ी: हो सकता है कि LineageOS या CyanogenMod के कुछ वर्शन पर चलने वाले डिवाइसों पर, आपका ऐप्लिकेशन डिप्लॉय न हो पाए और INSTALL_PARSE_FAILED_NOT_APK अपवाद दिखे.

  Android Studio 3.6 बीटा 1 और उसके बाद के वर्शन पर, जब आप अपने ऐप्लिकेशन को LineageOS या CyanogenMod पर डिप्लॉय करते हैं, तो IDE में पूरा ऐप्लिकेशन इंस्टॉल करकर इस अपवाद को हैंडल किया जाता है. इसकी वजह से डिप्लॉयमेंट में ज़्यादा समय लग सकता है.

Android Studio 3.5.2 में ठीक किया गया

• एक्सएमएल कोड स्टाइल गलत है: एक्सएमएल कोड में बदलाव करते समय, मेन्यू बार से कोड > कोड को फिर से फ़ॉर्मैट करें को चुनने पर, IDE ने गलत कोड स्टाइल लागू किया.

Android Studio 3.3.1 में ठीक किया गया

• C++ पर आधारित प्रोजेक्ट स्कैन करते समय मेमोरी की गड़बड़ियां खत्म हो गई हैं: जब Gradle, किसी ऐसे प्रोजेक्ट को स्कैन करता है जिसमें एक ही ड्राइव में एक से ज़्यादा जगहों पर C++ कोड होते हैं, तो स्कैन में पहली सामान्य डायरेक्ट्री के नीचे की सभी डायरेक्ट्री शामिल हो जाती हैं. बड़ी संख्या में डायरेक्ट्री और फ़ाइलों को स्कैन करने पर, 'मेमोरी खत्म हो गई' वाली गड़बड़ियां हो सकती हैं.

  इस समस्या के बारे में ज़्यादा जानकारी के लिए, उससे जुड़ा बग पढ़ें.