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

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

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

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

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

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

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

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

अगर Firebase सहायता विंडो (मुख्य मेन्यू में टूल > 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 दिख रहा है, तो अपने मॉड्यूल में 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 मैनेजर पर जाकर, अपने 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 के Canary और बीटा रिलीज़ के लिए कॉन्फ़िगरेशन डायरेक्ट्री, <version> के लिए X.Y के बजाय PreviewX.Y है. उदाहरण के लिए, Android Studio 4.1 Canary के बिल्ड, रिलीज़ कैंडिडेट और स्थिर रिलीज़ के लिए इस्तेमाल की जाने वाली AndroidStudio4.1 डायरेक्ट्री के बजाय, AndroidStudioPreview4.1 का इस्तेमाल करते हैं.

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

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

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

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

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

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 मैनेजर से 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 से Gradle check टास्क को भी चलाया जा सकता है. ज़्यादा जानकारी के लिए, समस्या 64887 देखें.

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

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

JUnit टेस्ट चलाने से, कोड दो बार कंपाइल हो सकता है

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

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

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

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

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

नेटिव कोड को डीबग करते समय, 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 स्टैंडअलोन कमांड-लाइन प्रोफ़ाइलर का इस्तेमाल किया जा सकता है.

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

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 " या"पोर्ट कनेक्ट नहीं हो सका " दिख सकता है. Platform Tools को 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 Test Recorder, उन प्रोजेक्ट के साथ काम नहीं करता जिनमें 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 के साथ AGP 7.3.0 का इस्तेमाल करने पर, खास बिल्ड वैरिएंट के लिए AIDL सोर्स सेट हटा दिए जाते हैं. हालांकि, अब भी अन्य एआईडीएल सोर्स सेट का इस्तेमाल किया जा सकता है. इनमें main/, बिल्ड टाइप, प्रॉडक्ट फ़्लेवर, और प्रॉडक्ट फ़्लेवर के कॉम्बिनेशन शामिल हैं. अगर आपको वैरिएंट के हिसाब से AIDL सोर्स सेट का इस्तेमाल करना है, तो 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 और उसके बाद के वर्शन में, IDE इस अपवाद को मैनेज करता है. इसके लिए, LineageOS या CyanogenMod डिवाइसों पर ऐप्लिकेशन को डिप्लॉय करने पर, वह ऐप्लिकेशन को पूरी तरह से इंस्टॉल करता है. इस वजह से, डिप्लॉय करने में ज़्यादा समय लग सकता है.

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

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

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

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

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