Problemas conocidos con Android Studio y el complemento de Gradle para Android

En esta página, se enumeran los problemas conocidos con Android Studio 3.5 y el complemento de Gradle para Android 3.5.0. Si encuentras un problema que aún no está incluido aquí, envía un informe de error.

Actualiza para obtener una versión preliminar: cada versión de Android Studio y el complemento de Gradle para Android tienen el objetivo de mejorar la estabilidad y el rendimiento, además de agregar nuevas funciones. Ahora, para disfrutar de los beneficios de las próximas versiones, descarga e instala la versión preliminar de Android Studio.

Problemas conocidos con Android Studio

En esta sección, se describen los problemas conocidos que se encontraron en la última versión estable de Android Studio.

Edición de código

En esta sección, se describen los problemas conocidos relacionados con el editor de código.

Estilo de código XML dañado

Cuando se edita código XML, el IDE puede aplicar un estilo de código incorrecto si seleccionas Code > Reformat Code en la barra de menú. Si quieres solucionar este problema, sigue estos pasos para restablecer el estilo de código de Android apropiado:

  1. Haz clic en File > Settings (en macOS, Android Studio > Preferences) para abrir la ventana de Settings.
  2. En el panel izquierdo, haz clic en Editor > Code Style > XML.
  3. Cerca de la esquina superior derecha del panel derecho, selecciona Set from > Predefined Style > Android.
  4. Haz clic en OK.

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.

Configuración de proyectos

En esta sección, se describen los problemas conocidos relacionados con la configuración de proyectos y la sincronización de Gradle.

Falló la sincronización de 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

Implementación

En esta sección, se describen los problemas conocidos relacionados con la implementación de tu app en un dispositivo conectado.

Android Emulator con HAXM en macOS High Sierra

Android Emulator 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.

Apply Changes

En esta sección, se describen los problemas conocidos relacionados con Apply Changes.

Un problema en Android Runtime arroja un error

Si usas un dispositivo en el que se ejecuta Android 8.0 o 8.1, es posible que encuentres mensajes de "VERIFICATION_ERROR" cuando intentes aplicar determinados tipos de cambios (especialmente si usas Kotlin). Este mensaje aparece cuando se produce un problema relacionado con Android Runtime, que se corrigió en Android 9.0 y versiones posteriores. Si bien el problema hace que Apply Changes falle, puedes volver a Ejecutar Ícono Run tu app para ver los cambios. Sin embargo, te recomendamos que actualices el dispositivo a Android 9.0 o posterior.

No es posible aplicar cambios cuando se usa android:sharedUserId

Si intentas hacer cambios en una clase que aún no se implementó en tu app en ejecución, Apply Changes fallará si la app se configuró de cualquiera de las siguientes maneras:

Cuando Apply Changes falle debido a este problema, Android Studio mostrará el siguiente mensaje:

Changes were not applied. JVMTI error: UNKNOWN_JVMTI_ERROR
    

Para resolver este problema en Android Studio 3.5, haz clic en Ejecutar Ícono Run para volver a implementar tu app y ver los cambios.

Depuración y pruebas

En esta sección, se describen los problemas conocidos relacionados con la depuración y las pruebas de tu app.

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. Luego, esta configuración 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.

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 tu código (por ejemplo, el depurador detiene la ejecución en una línea de tu código que llama a una función y haces clic en Step Into ) y quieres volver a tu código Java, haz clic en Resume Program (en lugar de 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.

Problemas conocidos con el complemento de Gradle para Android

En esta sección, se describen los problemas conocidos relacionados con la versión estable más reciente del complemento de Gradle para Android.

Firma del archivo cuyo nombre contiene caracteres de retorno de carro (CR)

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

Errores conocidos corregidos

En esta sección, se describen los problemas conocidos que se corrigieron en una versión reciente. Si tienes alguno de estos problemas, deberías actualizar Android Studio a la versión estable más reciente o la versión preliminar.

Errores corregidos en Android Studio 3.3.1

  • 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.

    Para obtener más información sobre este problema, consulta el error asociado con el problema.

Errores corregidos en Android Studio 3.2

  • 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.