Known issues with Android Studio and Android Gradle Plugin

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

Known Issues with Android Studio

  • Espresso Test Recorder compilation failure: Compilation fails with the message Execution failed for task ':app:compileDebugAndroidTestJavaWithJavac'. when you attempt to build a project that uses the Espresso Test Recorder. This issue affects versions of Android Studio below 3.2 that use version 3.0.2 or later of the espresso-core dependency. This issue does not affect Android Studio 3.2 and higher.

    If you are using Android Studio 3.1 or lower, you can work around this issue by setting a dependency on a version of espresso-core below 3.0.2 or by adding a separate rules dependency, as shown in the Espresso setup instructions.

  • 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 file by uncommenting the following line:


  • 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=""
    • Workaround 2: in Android Studio's vmoptions file, change the line to 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/
      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:

    at com.jarego.jayatana.swing.SwingGlobalMenu.getSwingGlobalMenuWindowController(
    at com.jarego.jayatana.swing.SwingGlobalMenu.installLockParentGlobalMenu(
    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: -". 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.

Known issues with the Android Gradle Plugin

  • Configuration on demand with Gradle 4.6 and above: If you're using Android Gradle Plugin 3.0.x or 3.1.x with Gradle 4.6 and above, you should disable configuration on demand to avoid some unpredictable build errors. (If you are using Android Gradle Plugin 3.2.0 or higher, you do not need to take any action to disable configuration on demand.)

    Disable configuration on demand in your file as shown below:


    To disable configuration on demand in the Android Studio settings, choose File > Settings (Android Studio > Preferences on Mac), select the Compiler category in the left pane, and clear the Configure on demand checkbox.

    In Android Studio 3.2 Beta 1 and higher, the options for enabling configuration on demand have been removed.

  • Project Sync Error while loading Android Plugin 3.0.0 multiple times: Loading the Android plugin multiple times in a single build leads to a project sync error. This can occur when you have multiple subprojects that each include the Android plugin in their buildscript classpath. This is a limitation of Gradle’s new variant-aware dependency management, which cannot yet handle matching attributes from different classloaders. If you are using Android Plugin 3.0.0 or lower, upgrade the plugin to Android plugin 3.1.0 and higher or follow the steps below to reslove the issue:

    • Multi-module Builds: Make sure that you add the Android plugin to only the build classpath of your top-level build.gradle file, as shown below:

      // Additionally, make sure that you don't wrap this in a
      // subprojects block.
      buildscript {
          dependencies {
              classpath ''
    • Composite Builds: Make sure that, for the main project and each included project that uses the Android plugin, the buildscript classpaths are identical. This also requires the order of the classpaths you add to the buildscript block to be identical. For example, consider the following classpath dependencies included in the build.gradle file of the main project:

      buildscript {
          dependencies {
              classpath ""
              classpath "me.tatarka:gradle-retrolambda:3.7.0"

      Now consider the following build.gradle file for another project included in the composite build:

      buildscript {
          dependencies {
              // Note that the order of plugins differs from that
              // of the main project's build.gradle file. This results
              // in a build error because Gradle registers this as a
              // different classloader.
              classpath "me.tatarka:gradle-retrolambda:3.7.0"
              classpath ""
  • Mismatch in Guava dependencies error with Firebase plugin version 1.1.0: Firebase plugin version 1.1.0 can cause a mismatch in Guava dependencies, resulting in the following error:

    Error:Execution failed for task ':app:packageInstantRunResourcesDebug'.;
    To get around this build error, add the following to the dependencies block of your project-level build.gradle file:

    dependencies {
        classpath ('') {
                    exclude group: '', module: 'guava-jdk5'

    For more information, see issue #63180002.

  • To use Protobufs, you must upgrade the Protobuf plugin to version 0.8.2 or higher.

  • The third party android-apt plugin is no longer supported. You should switch to the built-in annotation processor support, which has been improved to handle resolving dependencies lazily.

  • JAR signing (v1 scheme) does not support file names containing Carriage Return (CR) characters. (See issue #63885809).

API changes

Android Gradle Plugin 3.0.0 and higher introduce API changes that remove certain functionalities and may break your existing builds. Later versions of the plugin may introduce new public APIs that replace broken functionalities.

Modifying variant outputs at build time may not work

Using the Variant API to manipulate variant outputs is broken with the new plugin. It still works for simple tasks, such as changing the APK name during build time, as shown below:

// 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.versionName}.apk"

However, more complicated tasks that involve accessing outputFile objects no longer work. That's because variant-specific tasks are no longer created during the configuration stage. This results in the plugin not knowing all of its outputs up front, but it also means faster configuration times.

manifestOutputFile is no longer available

The processManifest.manifestOutputFile() method is no longer available, and you get the following error when you call it:

A problem occurred configuring project ':myapp'.
   Could not get unknown property 'manifestOutputFile' for task ':myapp:processDebugManifest'
   of type

Instead of calling manifestOutputFile() to get the manifest file for each variant, you can call processManifest.manifestOutputDirectory() to return the path of the directory that contains all generated manifests. You can then locate a manifest and apply your logic to it. The sample below dynamically changes the version code in the manifest:

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.