lightbulb_outline Help shape the future of the Google Play Console, Android Studio, and Firebase. Start survey

Known issues

This page tracks current known issues with Android Studio. To report an issue not already included here, see Report a bug.

  • Configuration on demand with Gradle 4.6: If you're using either Android Plugin for Gradle 3.0.1 or 3.1.0 with Gradle 4.6, you should disable configuration on demand in your gradle.properties file, as shown below, to avoid some unpredictable build errors. This issue should be fixed in a future version of the plugin.

    org.gradle.configureondemand=false

  • The @RestrictTo lint check does not work for Windows machines: In Android Studio 2.3, the @RestrictTo lint check does not correctly trigger error messages on Windows machines.

  • Virtual devices with parentheses in their names will not run: In Android Studio version 2.2, although you can include parentheses in the name of a Virtual Device (and in fact, some devices, like Android TV, include parentheses in their names automatically), you cannot run a virtual device that uses parentheses in its name. To avoid this problem, edit the Virtual Device to remove all "(" and ")" characters from the name.

    This issue has been resolved as of Android Studio 2.3

  • Instant Run is not compatible with Jack: Instant Run is currently not compatible with the Jack compiler, so it is disabled for projects using the Jack compiler. (Using the Jack compiler is only necessary when using Java 8 language features.)

  • Tools and libraries that require the app's class files are not compatible with Jack: Various tools that read .class files (such as JaCoCo, Mockito, and some lint checks) are currently not compatible with the Jack compiler.

  • Gradle build unable to clean output folders when project is on NTFS on Linux: Because of the file locking behavior of NTFS, on Windows machines, Android Studio automatically copies the classes' JAR files to another location before indexing, so that subsequent Gradle builds can clean and make changes to the build/tree. See issue 202297 for more information. This behavior is not enabled when using NTFS on Linux or OSX machines, but can be manually specified in your idea.properties file by uncommenting the following line: 

    idea.jars.nocopy=false

  • Mac performance: The OpenJDK 1.8.0_76 bundled with Studio 2.2 has a few problems on Mac. Using an external 4K monitor with a scaled resolution can adversely impact rendering performance as discussed in issue 203412 and in IDEA-144261, up to the point that the IDE becomes unresponsive. Additionally, as reported in issue 223749 and in IDEA-158500, scrolling is very sensitive on Mac 10.12 (Sierra).

  • Gradle Sync Failed: Broken Pipe: The issue is that the Gradle daemon is trying to use IPv4 instead of IPv6.

    • Workaround 1: On Linux, put the following in your ~/.profile or ~/.bash_profile: 
      export _JAVA_OPTIONS="-Djava.net.preferIPv6Addresses=true"
    • Workaround 2: in Android Studio's vmoptions file, change the line -Djava.net.preferIPv6Addresses=true to -Djava.net.preferIPv6Addresses=true For more information, see the Networking IPv6 User Guide.

  • "peer not authenticated" errors from Gradle sync or SDK Manager: The root cause of these errors is a missing certificate in $JAVA_HOME/jre/lib/certificates/cacerts. To resolve these errors, proceed as follows:

    • If you're behind a proxy, try to connect directly. If the direct connection works, then in order to connect via the proxy you may need to use keytool to add the proxy server's certificate to the cacerts file.
    • Re-install a supported, unmodified JDK. There's a known issue affecting Ubuntu users, which results in an empty /etc/ssl/certs/java/cacerts. To work around this issue, execute the following on the command line: 
      $ sudo /var/lib/dpkg/info/ca-certificates-java.postinst configure

  • JUnit tests missing resources in classpath when run from Android Studio: If you have specific resource folders in your Java modules, then those resources won't be found when running tests from the IDE. Running tests using Gradle from the command line will work. Executing the Gradle check task from the IDE will also work. See issue 64887 for more details.

    This issue happens because as of IntelliJ 13, you can only have a single folder as the classpath. IntelliJ's builder copies all resources into that build folder, but Gradle doesn't copy over the resources.

    • Workaround 1: Run the Gradle check task from the IDE rather than running a unit test.
    • Workaround 2: Update your build script to manually copy resources into the build folder. See comment #13 for more information.

  • Running JUnit tests may compile the code twice: When creating a new project, the template JUnit configuration might be created with two "Before launch" steps: Make and Gradle-aware Make. This configuration is then propagated to all created JUnit run configurations.

    • To fix the issue for the current project, click Run > Edit Configurations and change the default JUnit configuration to only include the Gradle-aware Make step.
    • To fix the issue for all future projects, click File > Close Project. You should see the welcome screen. Then click Configure > Project Defaults > Run Configurations and change the JUnit configuration to only include the Gradle-aware Make step.

  • Some test run configurations don't work: Not all run configurations that are available when right-clicking a test method are valid. Specifically, the following configurations are not valid:

    • Gradle run configurations (which have a Gradle logo as the icon) don't work.
    • JUnit run configurations (which have an icon without the green Android) don't apply to instrumentation tests, which cannot be run on the local JVM.
    Android Studio also remembers the run configuration created in a given context (for example, right-clicking a specific class or method), and will not offer to run in a different configuration in the future. To fix this, click Run > Edit Configurations and remove the incorrectly-created configurations.

  • Linux and the Awesome WM 3.4: Android Studio versions 0.8.3 and higher may not work correctly with the "Awesome WM" window manager version 3.4. To resolve this issue, upgrade to Awesome WM version 3.5.

  • Frozen keyboard input - "iBus" problems on Linux: There are some known interactions between the iBus daemon on Linux and Android Studio. In some scenarios, the IDE stops responding to keyboard input or starts inputting random characters. This bug is triggered by some missing synchronization between iBus and XLib + AWT, and has already been reported upstream to JetBrains and iBus. There are three current workarounds for this issue:

    • Workaround 1: Force iBus into synchronous mode. Before starting Android Studio, run the following on the command line: 
      $ IBUS_ENABLE_SYNC_MODE=1 ibus-daemon -xrd
    • Workaround 2: Disable iBus input in Android Studio. To disable iBus input for Android Studio only, run the following on the command line: 
      $ XMODIFIERS= ./bin/studio.sh
      This workaround only disables input methods for Android Studio, not any other applications you may be running. Note that if you restart the daemon while Android Studio is running (for example, by running ibus-daemon -rd), you effectively disable the input methods for all other applications and may also crash Android Studio's JVM with a segmentation fault.
    • Workaround 3: Double-check the shortcut bindings to make sure that the Next input shortcut is not set to Control+Space, since this is also the code completion shortcut in Android Studio. Ubuntu 14.04 (Trusty) makes Super+Space the default shortcut, but settings from previous versions may still be around. To check your shortcut bindings, run ibus-setup on the command line to open the IBus Preferences window. Under Keyboard Shortcuts, check the Next input method. If it is set to Control+Space, change it to Super+Space, or another shortcut of your choice.

  • Ubuntu and JAyatana: JAyatana allows Java Swing applications to integrate with the global menu in Ubuntu's Unity graphical shell. In some cases, Android Studio may encounter a NullPointerException under Unity, with an error message such as: 

    java.lang.NullPointerException
at com.jarego.jayatana.swing.SwingGlobalMenu.getSwingGlobalMenuWindowController(SwingGlobalMenu.java:204)
at com.jarego.jayatana.swing.SwingGlobalMenu.installLockParentGlobalMenu(SwingGlobalMenu.java:160)
at ...
    For more information, see issue 187179. Because of this issue, newer versions of Ubuntu are disabling JAyatana by default. If you encounter this problem, there are two possible workarounds (see this Stack Overflow post for more information):

    • Workaround 1: Unset the JAVA_TOOL_OPTIONS environment variable when running Android Studio.
    • Workaround 2: Uninstall JAyatana.

  • Adding Java breakpoints while debugging native code: While your app is paused at a breakpoint in your native code, the Auto and Dual debuggers may not immediately recognize new Java breakpoints that you set. To avoid this issue, add Java breakpoints either before starting a debug session or while the app is paused on a Java breakpoint. For more information, see issue 229949.

  • Stepping out of the native debugger: While using the Auto or Dual debugger to debug Java and native code, if you step into a native function from your Java code (for example, the debugger pauses execution at a line in your Java code that calls a native function and you click Step Into ) and you want to return to your Java code, click Resume Program (instead of Step Out or Step Over ). Your app process will still be paused, so click Resume Program in the your-module-java tab to resume it. For more information, see issue 224385.

  • Spurious render exception: The specific render error message is: "The following classes could not be found: - android.support.v7.internal.app.WindowDecorActionBar". Despite the error message, the layout preview is correct and the message can be safely ignored.

    This issue has been fixed as of the Android Studio 2.0 preview.

  • Android Emulator HAXM on macOS High Sierra: The Android Emulator on macOS High Sierra (10.13) requires HAXM 6.2.1+ for best compatibility and stability with macOS. However, macOS 10.13 has a more involved process to install kernel extensions such as HAXM. You need to manually allow the kernel extension itself to be installed as follows:

    1. First, attempt to install the latest version of HAXM from the SDK Manager.
    2. In MacOS, go to System Preferences > Security and Privacy.

    3. If you see an alert that System software from developer "Intel Corporation Apps" was blocked from loading, click Allow:

    For more information and workarounds, see this Apple webpage and issue 62395878.