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

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

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

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

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

Kotlin 2.0: Layout Inspector में लैम्ब्डा को हल नहीं किया जा सकता

Kotlin 2.0 का इस्तेमाल करते समय, लैम्डा को हल नहीं किया जा सकता. साथ ही, Layout Inspector, लैम्डा के सोर्स कोड पर सामान्य तरीके से नेविगेट नहीं कर सकता.

समाधान: इस समस्या के ठीक होने तक, नीचे दिए गए कंपाइलर विकल्प को समाधान के तौर पर जोड़ें:

kotlin {
  compilerOptions {
    freeCompilerArgs.add("-Xlambdas=class")
  }
}

"लॉन्च से पहले" Gradle-aware Make के बिना रन कॉन्फ़िगरेशन से, डिप्लॉयमेंट से जुड़ी गड़बड़ी होती है

Android Studio Ladybug Feature Drop Canary 9 में एक समस्या थी. इसकी वजह से, उस वर्शन में खोले गए प्रोजेक्ट से रन कॉन्फ़िगरेशन की जानकारी हट गई थी. अगर आपने किसी समय उस वर्शन के साथ अपना प्रोजेक्ट खोला था और ऐप्लिकेशन चलाने पर "बिल्ड आर्टफ़ैक्ट लोड हो रहे हैं" गड़बड़ी दिखती है, तो पुष्टि करें कि चालू रन कॉन्फ़िगरेशन के "लॉन्च से पहले" सेक्शन में "Gradle-aware Make" चरण मौजूद हो. इसकी पुष्टि करने के लिए, रन/डीबग कॉन्फ़िगरेशन > कॉन्फ़िगरेशन में बदलाव करें पर क्लिक करें. इसके बाद, चालू रन कॉन्फ़िगरेशन पर क्लिक करें और पुष्टि करें कि "लॉन्च से पहले" सेक्शन में "Gradle-aware Make" चरण मौजूद है. माफ़ करें, Android Studio इस समस्या को अपने-आप ठीक नहीं कर सकता. ऐसा इसलिए है, क्योंकि कुछ रन कॉन्फ़िगरेशन को "Gradle-aware Make" चरण के बिना जान-बूझकर सेट अप किया गया हो सकता है.

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

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

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

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

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

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

लेआउट इंस्पेक्टर का इस्तेमाल करके, सभी कंपोज़ नोड की जांच नहीं की जा सकती

अगर आपको लगता है कि लेआउट इंस्पेक्टर का इस्तेमाल करते समय, सभी कंपोज़ नोड की जांच नहीं की जा सकती, तो ऐसा किसी बग की वजह से हो सकता है. इस बग को Compose के वर्शन 1.5.0-alpha04 में ठीक कर दिया गया है. अगर आपको यह समस्या आ रही है, तो पक्का करें कि आपने Compose का वर्शन 1.5.0-alpha04 या इससे ऊपर का वर्शन इस्तेमाल किया हो.

Compose Preview को रेंडर करते समय गड़बड़ी हुई

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 डिपेंडेंसी शामिल की हो.

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

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, पिछली बार इस्तेमाल की गई .vmoptions फ़ाइल को इंपोर्ट करने की कोशिश करता है. साथ ही, JDK 11 के इस्तेमाल किए गए गार्बेज कलेक्टर के साथ काम करने के लिए, उन्हें सैनिटाइज़ करता है. अगर यह प्रोसेस पूरी नहीं होती है, तो हो सकता है कि आईडीई उन उपयोगकर्ताओं के लिए शुरू न हो जिन्होंने .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 के एम्युलेटर पर चलने वाले, Database Inspector का इस्तेमाल करने वाले ऐप्लिकेशन क्रैश हो सकते हैं. साथ ही, 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.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 पर 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 इनपुट बंद करने के लिए, कमांड लाइन पर यह निर्देश चलाएं: 
    $ 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 Preferences विंडो खुल जाएगी. कीबोर्ड शॉर्टकट में जाकर, इनपुट का अगला तरीका देखें. अगर इसे 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 से "peer not authenticated" गड़बड़ियां

इन गड़बड़ियों की मुख्य वजह, $JAVA_HOME/jre/lib/certificates/cacerts में सर्टिफ़िकेट मौजूद न होना है. इन गड़बड़ियों को ठीक करने के लिए, यह तरीका अपनाएं:

  • अगर आप प्रॉक्सी का इस्तेमाल कर रहे हैं, तो सीधे कनेक्ट करने की कोशिश करें. अगर डायरेक्ट कनेक्शन काम करता है, तो प्रॉक्सी के ज़रिए कनेक्ट करने के लिए, आपको cacerts फ़ाइल में प्रॉक्सी सर्वर का सर्टिफ़िकेट जोड़ने के लिए keytool का इस्तेमाल करना पड़ सकता है.
  • JDK को फिर से इंस्टॉल करें. यह JDK, इस्तेमाल किए जा सकने वाले 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 Plugin के 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 Apps" के सिस्टम सॉफ़्टवेयर को लोड होने से रोक दिया गया है, तो Allow पर क्लिक करें:

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

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

इस सेक्शन में, Apply Changes से जुड़ी उन समस्याओं के बारे में बताया गया है जिनके बारे में हमें पता है.

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

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

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

अगर Android 8.0 या 8.1 पर चलने वाले डिवाइस का इस्तेमाल किया जा रहा है, तो आपको कुछ बदलाव लागू करते समय "VERIFICATION_ERROR" मैसेज दिख सकते हैं. ऐसा खास तौर पर तब होता है, जब Kotlin का इस्तेमाल किया जा रहा हो. यह मैसेज, Android Runtime से जुड़ी समस्या की वजह से दिखता है. यह समस्या, 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 टेंप्लेट कॉन्फ़िगरेशन को दो "लॉन्च से पहले" चरणों के साथ बनाया जा सकता है: मेक और Gradle-aware मेक. इसके बाद, इस कॉन्फ़िगरेशन को बनाए गए सभी JUnit रन कॉन्फ़िगरेशन में शामिल कर दिया जाता है.

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

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

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

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

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

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

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

Java और नेटिव कोड को डीबग करने के लिए, Auto या Dual डीबगर का इस्तेमाल करते समय, अगर आपको अपने 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 कैश मिटाएं.

नेटिव डीबगर क्रैश हो जाता है और "Debugger process finished with exit code 127" मैसेज दिखता है

यह गड़बड़ी, Linux पर आधारित प्लैटफ़ॉर्म पर नेटिव डिबगर शुरू करते समय होती है. इससे पता चलता है कि नेटिव डिबगर के लिए ज़रूरी लाइब्रेरी में से कोई एक लाइब्रेरी, लोकल सिस्टम पर इंस्टॉल नहीं है. लापता लाइब्रेरी का नाम, idea.log फ़ाइल में पहले से प्रिंट किया गया हो सकता है. अगर ऐसा नहीं है, तो Android Studio की इंस्टॉलेशन डायरेक्ट्री पर जाने के लिए, टर्मिनल का इस्तेमाल करें. इसके बाद, bin/lldb/bin/LLDBFrontend --version कमांड लाइन को एक्ज़ीक्यूट करके जानें कि कौनसी लाइब्रेरी मौजूद नहीं हैं. आम तौर पर, ncurses5 लाइब्रेरी मौजूद नहीं होती, क्योंकि Linux के कुछ नए डिस्ट्रिब्यूशन पहले ही ncurses6 पर अपग्रेड हो चुके हैं.

प्रोफ़ाइलर

इस सेक्शन में, प्रोफ़ाइलर से जुड़ी ज्ञात समस्याओं के बारे में बताया गया है.

नेटिव मेमोरी प्रोफ़ाइलर: ऐप्लिकेशन शुरू होने के दौरान प्रोफ़ाइलिंग उपलब्ध नहीं है

फ़िलहाल, ऐप्लिकेशन शुरू होने के दौरान नेटिव मेमोरी प्रोफ़ाइलर उपलब्ध नहीं है. यह विकल्प, आने वाली रिलीज़ में उपलब्ध होगा.

इसके बजाय, स्टार्टअप प्रोफ़ाइलें कैप्चर करने के लिए, Perfetto के स्टैंडअलोन कमांड-लाइन प्रोफ़ाइलर का इस्तेमाल किया जा सकता है.

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

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

Wait for ART trace file timed out

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

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

डीबग या प्रोफ़ाइलिंग करते समय ADB अपवाद

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

प्लैटफ़ॉर्म टूल को अपग्रेड करने के लिए, यह तरीका अपनाएं:

  1. Android Studio में SDK Manager खोलने के लिए, Tools > SDK Manager पर क्लिक करें या टूलबार में SDK Manager पर क्लिक करें.

  2. Android SDK Platform-Tools के बगल में मौजूद चेकबॉक्स पर क्लिक करें, ताकि उसमें सही का निशान दिख जाए. बाईं ओर मौजूद कॉलम में, डाउनलोड आइकॉन दिखेगा.

  3. लागू करें या ठीक है पर क्लिक करें.

प्लगिन की वजह से, Build Output विंडो काम नहीं करती

CMake simple highlighter प्लगिन का इस्तेमाल करने पर, कॉन्टेंट Build Output विंडो में नहीं दिखता. बिल्ड चलता है और 'बिल्ड आउटपुट' टैब दिखता है, लेकिन कोई आउटपुट प्रिंट नहीं होता (समस्या #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 > Settings > Keymap पर जाएं. इसके बाद, कीमैप की सूची में Logcat खोजें. ज़्यादा जानकारी के लिए, समस्या #263475910 देखें.

इस समस्या को Android Studio Electric Eel Patch 1 में Logcat शॉर्टकट को हटाकर ठीक किया जाएगा.

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

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

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

किसी ऐप्लिकेशन मॉड्यूल से checkDependencies = true के साथ लिंट चलाने पर, डाइनैमिक-फ़ीचर लाइब्रेरी की डिपेंडेंसी की जांच नहीं की जाती. ऐसा तब तक होता है, जब तक वे ऐप्लिकेशन की डिपेंडेंसी भी न हों (समस्या #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() को कॉल करने के बजाय, 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 सोर्स सेट हटा दिए जाते हैं. आपके पास अब भी अन्य AIDL सोर्स सेट इस्तेमाल करने का विकल्प है. इनमें main/, बिल्ड टाइप, प्रॉडक्ट फ़्लेवर, और प्रॉडक्ट फ़्लेवर के कॉम्बिनेशन के सोर्स सेट शामिल हैं. अगर आपको वैरिएंट के हिसाब से एआईडीएल सोर्स सेट का इस्तेमाल करना है, तो Kotlin 1.6.21 का इस्तेमाल जारी रखें.

पहले से मालूम समस्याओं को ठीक किया गया

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

Android Studio 2021.1.1 में ठीक कर दिया गया है

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

Android Studio 2020.3.1 में ठीक कर दिया गया है

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

Android Studio 4.2 में ठीक की गई

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

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++ कोड होता है, तो स्कैन में पहली सामान्य डायरेक्ट्री के नीचे मौजूद सभी डायरेक्ट्री शामिल होती हैं. ज़्यादा डायरेक्ट्री और फ़ाइलों को स्कैन करने पर, मेमोरी खत्म होने की गड़बड़ियां हो सकती हैं.

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