Report a bug

We want to fix your bugs! But many bugs don't include required information. So we are focusing our limited resources on bugs that have complete reports. To improve the chances of your bug being fixed, please take a moment to read this document.

If you don't follow these steps, we will close your bug. If that happens, simply resubmit with the additional information.

Also note that the issue tracker is not a support forum. If you have questions about how to use the tools, or how to get your Android app to work, please visit stackoverflow.com or one of the several Android developer support resources.

How to report a bug

Make sure you are using the latest versions of the tools. This saves us from reviewing bugs that have already been fixed. If possible, also search for similar issues on the issue tracker for Android Studio to see whether the issue you’re seeing has already been reported (you can usually use the error message as a search keyword).
Open a bug report from Android Studio by selecting Help > Submit Feedback. This is the easiest way to start a bug because it populates the bug report with your Android Studio version, Java version, and system information, which we need to properly reproduce the issue. (Otherwise, file your bug here and add the version information by hand.)
Describe the exact steps to reproduce. If we can reproduce the issue on the first try, the odds of a fix are much better. If possible, include a code snippet (or better yet, point to a github project which can be used to reproduce the bug). Screenshots are also helpful to show what you are observing.
Describe what you expected to happen, and what you instead observed.
Pick a descriptive summary for the bug. You'd be surprised how many bugs are filed with the summary "Bug," "Issue," "Exception," "Not working," and so on, which makes it difficult for us to sort the issues.
For certain kinds of bugs, we need additional information:

Details for Android Studio bugs

Include the following additional information that is specific for Android Studio bugs.

If the IDE hangs

If the IDE itself appears to be very sluggish or completely frozen, generate a couple of thread dumps and attach them to the bug report. These tell us what the IDE is so busy doing (or what contended resource it’s waiting for).

If the IDE is sluggish but not frozen, also attach the idea.log file (select Help > Show Log in Finder). This shows us whether the reason the IDE is sluggish is that it's constantly throwing errors into the log.

Using CPU profiles to diagnose slowness

If you are experiencing sluggishness in Android Studio, CPU profiles can sometimes help diagnose the issue. Use these steps to capture a CPU profile captured using the Android Studio/IntelliJ Performance Testing plugin:

Install the plugin. This can be done directly from Android Studio by searching for "Performance Testing" in the plugin marketplace. Alternatively, you can download a Studio-compatible version from the plugin website.
Create the CPU profile. When Android Studio seems to be sluggish, choose "Start CPU Usage Profiling", repeat a few actions for which latency is problematic (code completion, typing and waiting for highlighting to catch up, etc.) and then hit "Stop CPU Usage Profiling."
Share the profile file. A balloon will appear providing the CPU snapshot file name, which should follow the format snapshot-NNN. Please share that snapshot file in your bug report.

If the IDE runs out of memory

Memory problems in Android Studio are sometimes difficult to reproduce and report. To help solve this problem, Android Studio includes a memory usage report that you can send to the Android Studio team to help identify the source of the memory issues.

Run a memory usage report

To run a memory usage report, follow these steps:

Click Help > Analyze Memory Usage from the menu bar.

Android Studio dumps the heap and prompts you to restart the IDE. If you restart the IDE, the heap dump analysis starts immediately. Otherwise, the heap dump analysis starts the next time you run Android Studio. In either case, the IDE notifies you once the memory usage report is ready for you to review.

Important: Sending a memory usage report to our team does not include the raw data from the heap dump; the heap dump is deleted as soon as the analysis is complete. Although the generated report does not contain any personal data, it is used in accordance with the Google Privacy Policy.
Click Review Report.

Before you send the report, you can review all of the information that's included.
After you've finished your review, copy and paste the contents of the report into a file and attach that file when you file your bug.

Submitting the report information this way ensures that the Android Studio team can communicate with you using the issue tracker while we are investigating your memory issues.

If the IDE crashes or throws exceptions

For other types of crashes, attach the idea.log file. Select Help > Show Log in Finder.

Generating a thread dump

A thread dump is a printout of all the threads running in the JVM, and for each thread, a printout of all the stackframes. This makes it easy to see what the IDE is busy doing, especially if you generate a couple of thread dumps a few seconds apart.

When you report bugs where the IDE is extremely busy with a pegged CPU, or where the IDE appears to have frozen, a thread dump can pinpoint either what code is doing a lot of work, or which threads are contending over resources and causing a deadlock.

The JDK ships with a tool named "jstack" which can be used to generate a thread dump. First you'll need to find the process id of the Android Studio process. You can use the "jps" command for that. (Both jstack and jps are in the bin directory of the JDK. If you have multiple JDKs installed, you should use the same version here as the one you are running Android Studio with, and you can see what version that is in Android Studio's About box.)

On Linux, Mac:

jps -mv | grep studio

For Windows:

jps -mv | findstr studio

For example, this will print out a long line like this:

$ jps -mv | grep studio
37605 -Dfile.encoding=UTF-8 -ea -Dsun.io.useCanonCaches=false -Djava.net.preferIPv4Stack=true -Djna.nosys=true ...

The first number on the left, 37605 in this case, is the process ID.

Next, you can generate a thread dump and save it to the file dump.txt like so:

jstack -l pid >> dump.txt

If that does not work, there are some additional platform-specific ways you can generate a thread dump; see IntelliJ Support for detailed instructions.

Details for build tools and Gradle bugs

Attach a real or sample project that demonstrates the issue. This is the best way to ensure all of the information needed is captured. Be sure to remove any sensitive information before sharing.

If you cannot share a project, please indicate the versions of the tools you're using (try to use the latest stable or preview versions first):

Android Gradle plugin version: Select File > Project Structure, click Project, and then locate Android Gradle Plugin Version.
Gradle version: From the above page, locate Gradle Version.
Android Studio version: Select Help > About and locate the Android Studio version.

Additionally, include the following information where applicable:

If a behavior has changed unexpectedly from an earlier version to the current version, indicate both versions.
If the build failed with an error, run the build from the command line with the --stacktrace option (i.e., ./gradlew <task> --stacktrace) and provide us with a stack trace.
If the build takes longer than expected, try one of the following:
- Run ./gradlew <task> --scan and share with us the generated Gradle build scan.
- Run ./gradlew <task> -Pandroid.enableProfileJson=true and share the Chrome-trace files generated under the <root-project>/build/android-profile directory.

Details for Android Emulator bugs

The easiest way to gather the emulator details is to use the File a bug feature in the extended controls:

Click More in the emulator panel.
In the Extended controls window, select Bug Report on the left.

This opens a screen where you can see the bug report details such as the screenshot, the AVD configuration info, and a bug report log. You can enter the steps to reproduce here or wait and type them into the report generated in the next step.
Wait for the bug report to finish collecting, and then click Send to Google. This opens a window for you to save the bug report in a folder and then opens your browser to create a report in the Google Issue Tracker, with the necessary emulator details filled in.
In the report, complete any remaining details such as the steps to reproduce the bug and attach the files saved when you created the bug report.

Otherwise, you must manually enter the following details:

Emulator Version. In the emulator, open the Extended controls, click Help, then click the About tab to find the Emulator version
Android SDK Tools version. Select Tools > SDK Manager, click SDK Tools, and then locate Android SDK Tools
Host CPU Model.
- On Linux: Open /proc/cpuinfo
- On Windows: Right-click My Computer and select Properties
- On Mac: Click the Apple icon and click About This Mac
Device name. From the AVD Manager, click to open the drop-down menu in the Actions column for the device, and then select View Details (or open the $avdname.avd/config.ini file). Find the entry for hw.device.name. For example: hw.device.name=Nexus 5