Android Dev Summit, October 23-24: two days of technical content, directly from the Android team. Sign-up for livestream updates.

Problemas conocidos con Android Studio y el complemento Gradle para Android

En esta página, se enumeran los problemas conocidos actuales con Android Studio y el complemento Gradle para Android. Consulta Cómo informar un problema para enviar alguno que no esté incluido aquí.

Problemas conocidos con Android Studio

  • Errores de falta de memoria durante el análisis de proyectos basados en C++: Cuando Gradle analiza un proyecto que tiene código C++ en más de una ubicación en la misma unidad, el análisis incluye todos los directorios debajo del primer directorio común. Sin embargo, analizar una gran cantidad de directorios y archivos podría provocar errores de falta de memoria.

    Si experimentas este comportamiento en tu proyecto, te recomendamos usar Android Studio 3.2. Para obtener más información sobre este problema, consulta el error asociado con el problema.

  • Fallo de compilación de la Grabadora de pruebas Espresso: La compilación falla y muestra el mensaje "Execution failed for task ':app:compileDebugAndroidTestJavaWithJavac'" cuando intentas compilar un proyecto que usa la Grabadora de pruebas Espresso. Este problema afecta a las versiones de Android Studio anteriores a la 3.2 que usan la versión 3.0.2 o posterior de la dependencia espresso-core. Sin embargo, no afecta a Android Studio 3.2 ni versiones posteriores.

    Si usas Android Studio 3.1 o versiones anteriores, puedes establecer una dependencia en una versión de espresso-core anterior a la 3.0.2 para solucionar este problema, o bien al agregar una dependencia rules separada, como se muestra en las instrucciones de configuración de Espresso.

  • La comprobación de lint @RestrictTo no funciona en máquinas con Windows: En Android Studio 3.2, la comprobación de lint @RestrictTo no activa correctamente los mensajes de error en máquinas con Windows.

  • No se ejecutarán los dispositivos virtuales cuyos nombres tengan paréntesis: En la versión 2.2 de Android Studio, si bien puedes incluir paréntesis en el nombre de un dispositivo virtual (de hecho, algunos dispositivos, como Android TV, los incluyen en sus nombres automáticamente), no puedes ejecutar un dispositivo virtual cuyo nombre tenga paréntesis. Si quieres evitar este problema, edita el dispositivo virtual para quitar todos los caracteres "(" y ")" del nombre.

    Este problema se resolvió a partir de Android Studio 2.3

  • Instant Run no es compatible con Jack: Por el momento, Instant Run no es compatible con el compilador Jack, por lo que está inhabilitado para proyectos que lo usan. (El uso del compilador Jack solo es necesario cuando se usan las funciones de lenguaje Java 8).

  • Las herramientas y bibliotecas que requieren los archivos de clase de la app no son compatibles con Jack: Varias herramientas que leen archivos .class (como JaCoCo, Mockito y algunas comprobaciones de lint) actualmente no son compatibles con el compilador Jack.

  • La compilación de Gradle no puede limpiar las carpetas de salida cuando el proyecto está en NTFS en Linux: Debido al comportamiento de bloqueo de archivos de NTFS, en equipos con Windows, Android Studio copia automáticamente los archivos JAR de las clases en otra ubicación antes de la indexación, para que las compilaciones posteriores de Gradle puedan limpiar y realizar cambios en la compilación o en el árbol. Consulta el problema 202297 para obtener más información. Este comportamiento no está habilitado cuando se usa NTFS en equipos OSX o Linux, pero puedes especificarlo manualmente en tu archivo idea.properties al quitar el comentario de la siguiente línea:

    idea.jars.nocopy=false

  • Rendimiento de Mac: La implementación OpenJDK 1.8.0_76, incluida en el paquete de Studio 2.2, tiene algunos problemas en Mac. El uso de un monitor 4K externo con una resolución escalada puede afectar negativamente el rendimiento del procesamiento como se explica en el problema 203412 y en IDEA-144261, hasta el punto en que el IDE deja de responder. Además, como se informó en el problema 223749 y en IDEA-158500, el desplazamiento es muy sensible en Mac 10.12 (Sierra).

  • Falló la sincronización con Gradle: Canal dañado: El problema es que el daemon de Gradle está intentando usar IPv4 en lugar de IPv6.

    • Solución 1: En Linux, incluye lo siguiente en tu ~/.profile o ~/.bash_profile:
      export _JAVA_OPTIONS="-Djava.net.preferIPv6Addresses=true"
    • Solución 2: En el archivo vmoptions de Android Studio, cambia la línea -Djava.net.preferIPv6Addresses=true a -Djava.net.preferIPv6Addresses=true. Para obtener más información, consulta la Guía del usuario de herramientas de redes IPv6.
  • Errores "peer not authenticated" de la sincronización con Gradle o SDK Manager: La causa raíz de estos errores es que falta un certificado en $JAVA_HOME/jre/lib/certificates/cacerts. Para resolverlos, haz lo siguiente:

    • Si usas un proxy, intenta conectarte directamente. Si la conexión directa funciona, es posible que, para conectarte por medio del proxy, necesites usar keytool a fin de agregar el certificado del servidor proxy al archivo cacerts.
    • Vuelve a instalar un JDK compatible sin modificar. Hay un problema conocido que afecta a los usuarios de Ubuntu y que resulta en un /etc/ssl/certs/java/cacerts vacío. Para solucionar este problema, ejecuta lo siguiente en la línea de comandos:
      $ sudo /var/lib/dpkg/info/ca-certificates-java.postinst configure
  • Faltan recursos de las pruebas JUnit en la ruta de clase cuando se ejecutan desde Android Studio: Si tienes carpetas de recursos específicas en tus módulos Java, esos recursos no se encontrarán al ejecutar pruebas desde el IDE. La ejecución de pruebas por medio de Gradle desde la línea de comandos funcionará correctamente. La ejecución de la tarea check de Gradle desde el IDE también. Consulta el problema 64887 para obtener más detalles.

    Este problema se produce porque a partir de IntelliJ 13, solo puedes tener una única carpeta como ruta de clase. El compilador de IntelliJ copia todos los recursos en esa carpeta de compilación, pero Gradle no los copia.

    • Solución 1: Ejecuta la tarea check de Gradle desde el IDE, en lugar de ejecutar una prueba de unidades.
    • Solución 2: Actualiza tu secuencia de comandos de compilación para copiar recursos manualmente en la carpeta de compilación. Consulta el comentario #13 para obtener más información.
  • La ejecución de pruebas JUnit podría compilar el código dos veces: Al desarrollar un nuevo proyecto, la configuración de la plantilla JUnit puede crearse con dos pasos "previos al lanzamiento": Make y Gradle-aware Make. Esta configuración luego se propaga a todas las configuraciones de ejecución de JUnit creadas.

    • Para solucionar el problema en el proyecto actual, haz clic en Run > Edit Configurations y cambia la configuración predeterminada de JUnit a fin de incluir solo el paso de "Gradle-aware Make".
    • Para solucionar el problema en todos los proyectos futuros, haz clic en File > Close Project. Deberías ver la pantalla de bienvenida. Luego, haz clic en Configure > Project Defaults > Run Configurations y cambia la configuración de JUnit para incluir solo el paso de "Gradle-aware Make".
  • Algunas configuraciones de ejecución de pruebas no funcionan: No todas las configuraciones de ejecución que están disponibles al hacer clic con el botón derecho en un método de prueba son válidas. Específicamente, las siguientes configuraciones no son válidas:

    • Las configuraciones de ejecución de Gradle (que tienen un logotipo de Gradle como ícono) no funcionan.
    • Las configuraciones de ejecución de JUnit (que tienen un ícono sin el robot verde de Android) no se aplican a las pruebas de instrumentación, que no pueden ejecutarse en la JVM local.
    Android Studio también recuerda la configuración de ejecución creada en un contexto determinado (por ejemplo, al hacer clic con el botón derecho en una clase o método específico), y no ofrecerá la ejecución en una configuración diferente en el futuro. Para solucionar este problema, haz clic en Run > Edit Configurations y quita las configuraciones creadas incorrectamente.

  • Linux y Awesome WM 3.4: Es posible que Android Studio 0.8.3 y las versiones posteriores no funcionen correctamente con la versión 3.4 del administrador de ventanas "Awesome WM". Para resolver este problema, actualiza a la versión 3.5 de Awesome WM.

  • Entrada de teclado inmovilizada: problemas de "iBus" en Linux: Existen algunas interacciones conocidas entre el daemon iBus en Linux y Android Studio. En algunos casos, el IDE deja de responder a la entrada del teclado o comienza a ingresar caracteres aleatorios. Este error se genera por una falta de sincronización entre iBus y XLib + AWT, y ya se informó de manera ascendente a iBus y JetBrains. Actualmente, existen tres soluciones para este problema:

    • Solución 1: Fuerza el iBus al modo síncrono. Antes de iniciar Android Studio, ejecuta lo siguiente en la línea de comandos:
      $ IBUS_ENABLE_SYNC_MODE=1 ibus-daemon -xrd
    • Solución 2: Inhabilita la entrada del iBus en Android Studio. Si quieres hacerlo para Android Studio únicamente, ejecuta lo siguiente en la línea de comandos:
      $ XMODIFIERS= ./bin/studio.sh
      Esta solución solo inhabilita los métodos de entrada para Android Studio, pero no para las demás apps que puedan estar en ejecución. Ten en cuenta que, si reinicias el daemon mientras Android Studio está en ejecución (por ejemplo, al ejecutar ibus-daemon -rd), inhabilitarás de manera efectiva los métodos de entrada para todas las demás apps y también podrías bloquear la JVM de Android Studio con un fallo de segmentación.
    • Solución 3: Vuelve a verificar los vínculos de combinación de teclas a fin de asegurarte de que Next input shortcut no esté configurado en "Control + Espacio", ya que esta también es la combinación de teclas para la finalización de código en Android Studio. Ubuntu 14.04 (Trusty) hace que "Super + Espacio" sea la combinación de teclas predeterminada, pero puede suceder que la configuración de las versiones anteriores aún esté disponible. Si quieres verificar tus vínculos de combinación de teclas, ejecuta ibus-setup en la línea de comandos para abrir la ventana "IBus Preferences". En Keyboard Shortcuts, marca la opción Next input method. Si está configurado en "Control + Espacio", cámbialo a "Super + Espacio", o bien a otra combinación de teclas que elijas.
  • Ubuntu y JAyatana: JAyatana permite que las aplicaciones de Java Swing se integren con el menú global en la shell gráfica Unity de Ubuntu. En algunos casos, Android Studio podría encontrar una excepción NullPointerException en Unity, con un mensaje de error como el siguiente:

    java.lang.NullPointerException
        at com.jarego.jayatana.swing.SwingGlobalMenu.getSwingGlobalMenuWindowController(SwingGlobalMenu.java:204)
        at com.jarego.jayatana.swing.SwingGlobalMenu.installLockParentGlobalMenu(SwingGlobalMenu.java:160)
        at ...
    Para obtener más información, consulta el problema 187179. Debido a este problema, las versiones más recientes de Ubuntu están inhabilitando JAyatana de forma predeterminada. Si experimentas este problema, hay dos soluciones posibles (consulta esta publicación de Stack Overflow para obtener más información):

    • Solución 1: Inhabilita la variable de entorno JAVA_TOOL_OPTIONS cuando ejecutes Android Studio.
    • Solución 2: Desinstala JAyatana.
  • Agregar puntos de interrupción de Java al depurar código nativo: Cuando tu app esté detenida en un punto de interrupción en tu código nativo, es posible que los depuradores Auto y Dual no reconozcan inmediatamente los nuevos puntos de interrupción de Java que establezcas. Para evitar este problema, agrega puntos de interrupción de Java antes de comenzar una sesión de depuración o cuando la app esté detenida en un punto de interrupción de Java. Para obtener más información, consulta el problema 229949.

  • Salir del depurador nativo: Al usar el depurador Auto o Dual para depurar código nativo y Java, si ingresas a una función nativa desde de tu código Java (por ejemplo, el depurador detiene la ejecución en una línea en tu código Java que llama a una función nativa y haces clic en Step Into ) y quieres volver a tu código Java, haz clic en Resume Program  (en lugar de en Step Out  o Step Over ). El proceso de la app seguirá detenido, así que deberás hacer clic en Resume Program  en la pestaña your-module-java para reanudarlo. Para obtener más información, consulta el problema 224385.

  • Excepción de procesamiento falso: El mensaje de error de procesamiento específico es el siguiente: "The following classes could not be found: - android.support.v7.internal.app.WindowDecorActionBar" (No se pudieron encontrar las siguientes clases: -android.support.v7.internal.app.WindowDecorActionBar). A pesar del mensaje de error, la vista previa del diseño es correcta y el mensaje puede ignorarse, ya que no hay riesgo.

    Este problema se solucionó a partir de la versión preliminar de Android Studio 2.0.

  • Emulador de Android con HAMX en macOS High Sierra: El emulador de Android en macOS High Sierra (10.13) requiere HAXM 6.2.1 o versiones posteriores para una mejor compatibilidad y estabilidad con macOS. Sin embargo, macOS 10.13 tiene un proceso más complejo para instalar extensiones de kernel como HAXM. Deberás permitir manualmente que la extensión de kernel se instale de la siguiente manera:

    1. Primero, intenta instalar la versión más reciente de HAXM desde el SDK Manager.
    2. En macOS, ve a Preferencias del sistema > Seguridad y privacidad.
    3. Si ves la siguiente alerta: El software del sistema del desarrollador "Intel Corporation Apps" no pudo cargarse, haz clic en Permitir:

    Para obtener más información y soluciones, consulta esta página web de Apple y el problema 62395878.

Problemas conocidos con el complemento Gradle para Android

  • Configuración on demand con Gradle 4.6 y versiones posteriores: Si usas el complemento Gradle para Android 3.0.x o 3.1.x con Gradle 4.6 y versiones posteriores, debes desactivar la configuración on demand a fin de evitar algunos errores de compilación impredecibles. (Si usas el complemento Gradle para Android 3.2.0 o versiones posteriores, no necesitas realizar ninguna acción para inhabilitar la configuración on demand).

    Inhabilita la configuración on demand en tu archivo gradle.properties como se muestra a continuación:

    org.gradle.configureondemand=false
        

    Para inhabilitar la configuración on demand en las opciones de Android Studio, elige File > Settings (Android Studio > Preferences en Mac), selecciona la categoría Compiler en el panel izquierdo y desmarca la casilla de verificación Configure on demand.

    En Android Studio 3.2 Beta 1 y versiones posteriores, se quitaron las opciones para habilitar la configuración on demand.

  • Error de sincronización del proyecto al cargar el complemento de Android 3.0.0 varias veces: Si cargas el complemento de Android varias veces en una sola compilación se generará un error de sincronización del proyecto, lo que puede ocurrir cuando tienes varios subproyectos y cada uno de ellos incluye el complemento de Android en su ruta de clase de la secuencia de comandos de compilación. Esta es una limitación de la nueva administración de dependencias con reconocimiento de variantes de Gradle, que aún no permite administrar atributos coincidentes de diferentes cargadores de clases. Si usas el complemento de Android 3.0.0 o versiones anteriores, actualiza al complemento de Android 3.1.0 y versiones posteriores, o bien sigue los pasos que aparecen a continuación para resolver el problema:

    • Compilaciones de varios módulos: Asegúrate de agregar el complemento de Android solo a la ruta de clase de la compilación de tu archivo build.gradle de nivel superior, como se muestra a continuación:

      // Additionally, make sure that you don't wrap this in a
          // subprojects block.
          buildscript {
              ...
              dependencies {
                  classpath 'com.android.tools.build:gradle:3.4.2'
              }
          }
          
    • Compilaciones compuestas: Asegúrate de que, para el proyecto principal y cada proyecto incluido que use el complemento de Android, las rutas de clase de la secuencia de comandos de compilación sean idénticas. También se requiere que sea idéntico el orden de las rutas de clase que agregues al bloque buildscript. Por ejemplo, considera las siguientes dependencias de ruta de clase incluidas en el archivo build.gradle del proyecto principal:

      buildscript {
              ...
              dependencies {
                  classpath "com.android.tools.build:gradle:3.4.2"
                  classpath "me.tatarka:gradle-retrolambda:3.7.0"
              }
          }
          

      Ahora, considera el siguiente archivo build.gradle para otro proyecto incluido en la compilación compuesta:

      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 "com.android.tools.build:gradle:3.4.2"
              }
          }
          
  • Error de coincidencia en las dependencias de Guava con la versión 1.1.0 del complemento de Firebase: La versión 1.1.0 del complemento de Firebase puede causar una discrepancia en las dependencias de Guava, lo que genera el siguiente error:

        Error:Execution failed for task ':app:packageInstantRunResourcesDebug'.
        com.google.common.util.concurrent.MoreExecutors.directExecutor()Ljava/util/concurrent/Executor;
        
    Para evitar este error de compilación, agrega lo siguiente al bloque dependencies de tu archivo build.gradle de nivel de proyecto:

    dependencies {
            classpath ('com.google.firebase:firebase-plugins:1.1.0') {
                        exclude group: 'com.google.guava', module: 'guava-jdk5'
            }
            ...
        }
        

    Para obtener más información, consulta el problema #63180002.

  • Para usar Protobufs, debes actualizar el complemento de Protobuf a la versión 0.8.2 o una posterior.

  • Ya no se admite el complemento android-apt de terceros. Debes cambiar a la compatibilidad con el procesador de anotaciones integrado, que se mejoró a fin de controlar la resolución de dependencias de forma lenta.

  • La firma JAR (esquema v1) no admite nombres de archivos que contengan caracteres de retorno de carro (CR) (consulta el problema #63885809).

Cambios en la API

En el complemento Gradle para Android 3.0.0 y versiones posteriores, se introdujeron cambios en la API que quitan funcionalidades específicas y pueden romper tus compilaciones existentes. En las versiones posteriores del complemento, podrían introducirse nuevas API públicas que reemplacen las funcionalidades afectadas.

Modificar los resultados de la variante en el tiempo de compilación podría no funcionar

No es posible usar la API de variantes para manipular resultados de variantes con el nuevo complemento. Sin embargo, puedes usarla para tareas simples, como modificar el nombre del APK durante la compilación, de la siguiente manera:

    // 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"
        }
    }
    

No obstante, las tareas más complicadas que incluyen el acceso a objetos outputFile ya no funcionan debido a que ya no se crean tareas específicas de las variantes durante la etapa de configuración. Como resultado, el complemento no reconoce todos sus resultados de antemano, aunque se reducen los tiempos de configuración.

manifestOutputFile ya no está disponible

El método processManifest.manifestOutputFile() ya no está disponible y verás el siguiente error cuando lo llames:

    A problem occurred configuring project ':myapp'.
       Could not get unknown property 'manifestOutputFile' for task ':myapp:processDebugManifest'
       of type com.android.build.gradle.tasks.ProcessManifest.
    

En lugar de llamar a manifestOutputFile() a fin de obtener el archivo de manifiesto para cada variante, puedes llamar a processManifest.manifestOutputDirectory() para mostrar la ruta de acceso del directorio que contiene todos los manifiestos generados. Luego, puedes ubicar un manifiesto y aplicarle tu lógica. En el siguiente ejemplo, se cambia de forma dinámica el código de la versión en el manifiesto:

    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)
            }
        }
    }