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

En esta página, se enumeran los problemas conocidos Android Studio Actualización de funciones de Koala y complemento de Android para Gradle 8.6.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 Android para Gradle 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 versión estable más reciente de Android Studio.

La ventana de Firebase Assistant muestra un mensaje de error

Si la ventana de Firebase Assistant (Tools > Firebase desde el menú principal) muestra un mensaje de error, invalida las cachés y reinicia Android Studio para solucionar el error.

No se puede aislar una vista con el Inspector de diseño

Capacidad de aislar una vista con la función El Inspector de diseño no está disponible en este momento. Estamos trabajando para solucionar este problema en una versión futura.

No todos los nodos de Compose se pueden inspeccionar con el Inspector de diseño.

Si notas que no todos los nodos de Compose se pueden inspeccionar cuando usas el Inspector de diseño, es probable que esto se deba a un error que se corrigió en la versión 1.5.0-alpha04 de Compose. Si experimentas este problema, asegúrate de actualizar a la versión 1.5.0-alpha04, o una posterior, de Compose.

Se produce un error al procesar la vista previa de Compose

Comenzando por Android Studio Chipmunk, si ves java.lang.NoSuchFieldError: view_tree_saved_state_registry_owner o java.lang.ClassNotFoundException: androidx.savedstate.R$id en el panel de problemas, asegúrate de incluir una dependencia debugImplementation a androidx.lifecycle:lifecycle-viewmodel-savedstate en tu módulo.

Si ves java.lang.NoSuchFieldError: view_tree_lifecycle_owner en el panel de problemas, asegúrate de incluir una dependencia debugImplementation a androidx.lifecycle:lifecycle-runtime en tu módulo.

Si ves java.lang.NoClassDefFoundError: Could not initialize class androidx.customview.poolingcontainer.PoolingContainer o java.lang.NoClassDefFoundError: androidx/customview/poolingcontainer/PoolingContainerListener en el panel de problemas, asegúrate de incluir una dependencia debugImplementation en androidx.customview:customview-poolingcontainer en tu módulo.

Se produce un error cuando las contraseñas de la clave y del almacén de claves son diferentes

A partir de la versión 4.2, Android Studio ejecuta JDK 11. Esta actualización provoca un cambio de comportamiento subyacente relacionado con las claves de firma.

Cuando navegas a Build > Generate Signed Bundle / APK para configurar la firma de apps para un paquete de aplicación o un APK y, luego, ingresas distintas contraseñas para la clave y el almacén de claves, se genera el siguiente error:

Key was created with errors:
Warning: Different store and Key passwords not supported for PKCS12 Key stores

Para evitar este problema, usa la misma contraseña para la clave y el almacén de claves.

Android Studio no se inicia luego de instalar la versión 4.2

Studio intenta importar .vmoptions anteriores y limpiarlas de manera que funcionen con el recolector de elementos no utilizados del JDK 11. Si ese proceso falla, es posible que, en algunos casos, el IDE no se inicie si el usuario estableció opciones de VM personalizadas en el archivo .vmoptions.

A fin de solucionar este problema, te recomendamos que comentes las opciones personalizadas en .vmoptions (con el carácter "#"). Puedes encontrar el archivo .vmoptions en las siguientes ubicaciones:

Windows

C:\Users\YourUserName\AppData\[Local|Roaming]\Google\AndroidStudio4.2\studio64.exe.vmoptions

macOS

~/Library/Application Support/Google/AndroidStudio4.2/studio.vmoptions

Linux

~/.config/Google/AndroidStudio4.2/studio64.vmoptions

Si Studio no se inicia después de probar esta solución alternativa, consulta Android Studio no se inicia después de la actualización que se incluye a continuación.

Las apps que usan el Inspector de bases de datos fallan en el emulador de Android 11

Las apps que usan el Inspector de bases de datos pueden fallar cuando se ejecutan en el emulador de Android 11 y se muestra un error como el siguiente en Logcat:

 Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR)

Para solucionar este problema, navega a Tools > SDK Manager y actualiza tu versión del emulador de Android 11 a la versión 9 o versiones posteriores. En la pestaña SDK Platforms, marca la casilla con la etiqueta Show Package Details y selecciona la versión 9 del emulador de Android 11 o una posterior.

Android Studio no se inicia después de la actualización

Si Studio no se inicia después de una actualización, es posible que el problema se deba a una configuración no válida de Android Studio importada desde una versión anterior de Android Studio o un complemento incompatible. Como solución alternativa, borra (o con fines de copia de seguridad, renombra) el directorio que se indica a continuación según la versión de Android Studio y el sistema operativo, y vuelve a iniciar Android Studio. Esta acción restablecerá Android Studio a su estado predeterminado y se quitarán todos los complementos de terceros.

Para Android Studio 4.1 y versiones posteriores:

  • Windows: %APPDATA%\Google\AndroidStudio<version>
    Ejemplo: C:\Users\your_user_name\AppData\Roaming\Google\AndroidStudio4.1

  • macOS: ~/Library/Application Support/Google/AndroidStudio<version>
    Ejemplo: ~/Library/Application Support/Google/AndroidStudio4.1

  • Linux: ~/.config/Google/AndroidStudio<version> y ~/.local/share/Google/AndroidStudio<version>
    Ejemplo: ~/.config/Google/AndroidStudio4.1 y ~/.local/share/Google/AndroidStudio4.1

Para Android Studio 4.0 y versiones anteriores:

  • Windows: %HOMEPATH%\.AndroidStudio<version>\config
    Ejemplo: C:\Users\your_user_name\.AndroidStudio3.6\config

  • macOS: ~/Library/Preferences/AndroidStudio<version>
    Ejemplo: ~/Library/Preferences/AndroidStudio3.6

  • Linux: ~/.AndroidStudio<version>/config
    Ejemplo: ~/.AndroidStudio3.6/config

Ten en cuenta que el directorio de configuración para las versiones Canary y beta de Android Studio es PreviewX.Y en lugar de X.Y para <version>. Por ejemplo, las compilaciones de la versión Canary de Android Studio 4.1 usan AndroidStudioPreview4.1, en lugar del directorio AndroidStudio4.1 que se usa para las versiones potenciales y estables.

Problema de compilación en proyectos multiplataforma de Kotlin

Pueden surgir errores de compilación en el código MPP de Kotlin debido a la falta de símbolos. Este problema se debería solucionar al actualizar el complemento de Kotlin a la versión 1.4.

Conflictos de asignación de teclas en Linux

En Linux, algunas combinaciones de teclas entran en conflicto con las predeterminadas de Linux y las de administradores de ventanas populares, como KDE y GNOME. Es posible que estas combinaciones de teclas no funcionen como se espera en Android Studio.

Puedes encontrar más información sobre este error (incluidas posibles soluciones) en el registro de errores de IntelliJ.

Texto pequeño de la IU en ChromeOS

En ChromeOS, el texto puede parecer mucho más pequeño que en las versiones anteriores. Para solucionar este problema, haz lo siguiente:

  1. Haz clic en File > Settings para abrir la ventana Settings.
  2. Ve a Appearance & Behavior > Appearance.
  3. Selecciona Use custom font.
  4. Aumenta el tamaño de la fuente.
  5. En la ventana Settings, navega a Editor > Font.
  6. Aumenta el tamaño de la fuente.
  7. Haz clic en OK.

Edición de código

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

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ó antes 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, no los de otras aplicaciones que estén en ejecución. Ten en cuenta que, si reinicias el daemon mientras Android Studio está en ejecución (por ejemplo, cuando se ejecuta ibus-daemon -rd), inhabilitarás de manera efectiva los métodos de entrada para todas las demás aplicaciones y también podrías bloquear la JVM de Android Studio con una falla de segmentación.
  • Solución 3: Vuelve a verificar las vinculaciones de combinaciones de teclas para 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 vinculaciones de combinaciones 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.preferIPv4Addresses=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 para 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.

[Solo en macOS] No se aplican actualizaciones incrementales debido a un problema con la reproducción del archivo Gradle en proyectos guardados en /System/Volumes/Data.

El problema de Gradle 18149 afecta a las versiones 7.0 y superiores del complemento de Android para Gradle porque requieren Gradle 7.0 o una versión posterior. A partir de Gradle 7.0, la visualización de archivos está habilitada de forma predeterminada. Si trabajas en macOS y tu proyecto se guarda en /System/Volumes/Data, la visualización de archivos de Gradle no realizará un seguimiento adecuado de los cambios de archivos. Esto hará que el sistema de compilación no vea ningún cambio en los archivos y, por lo tanto, no actualizará los APK. El código de implementación incremental no realizará ninguna acción porque el estado del APK local es el mismo que en el dispositivo.

Para solucionar este problema, debes mover el directorio de tu proyecto al directorio de usuarios, es decir, en /Users/username. El sistema de compilación recibirá una notificación correcta sobre los cambios en los archivos de Gradle, y los cambios incrementales se aplicarán correctamente.

Android Emulator con HAXM en macOS High Sierra

Android Emulator en macOS High Sierra (10.13) requiere HAXM 6.2.1 o una versión posterior 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 System Preferences > Security and Privacy (Preferencias del sistema > Seguridad y privacidad).

  3. Si ves la siguiente alerta: System software from developer "Intel Corporation Apps" was blocked from loading (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 error 62395878.

Apply Changes

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

No se aplicó el nombre nuevo de la app

Si cambias el nombre de tu app y, luego, intentas aplicar ese cambio, es posible que el nombre actualizado no se refleje. Para resolver este problema, haz clic en Run Ícono Run a fin de volver a implementar la app y ver los cambios.

Un problema en Android Runtime arroja un error

Si usas un dispositivo en el que se ejecuta Android 8.0/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 hacer clic en Run Ícono Run y ejecutar tu app para ver los cambios. Sin embargo, te recomendamos que actualices el dispositivo a Android 9.0 o versiones posteriores.

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 de Java, esos recursos no se encontrarán cuando se ejecuten 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 lo hará. 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 n.º13 para obtener más información.

La ejecución de pruebas JUnit podría compilar el código dos veces

Al desarrollar un proyecto nuevo, 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 cuando haces 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, si se hace clic con el botón derecho en una clase o un método específicos), 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.

Agrega puntos de interrupción de Java al depurar código nativo

Cuando tu app esté detenida en un punto de interrupción de 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.

Sal del depurador nativo

Cuando se usa el depurador Auto o Dual para depurar código Java y nativo, si ingresas a una función nativa desde tu código Java (por ejemplo, el depurador detiene la ejecución en una línea de 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 Step Out o Step Over ). Se detendrá el proceso de tu app, por lo que debes hacer clic en Resume Program en la pestaña your-module-java para reanudarlo. Para obtener más información, consulta el problema 224385.

El depurador nativo se bloquea mientras se cargan las bibliotecas

Al usar el depurador nativo por primera vez después de actualizar a Android Studio 4.2 y versiones posteriores, el depurador nativo puede dejar de responder mientras se cargan las bibliotecas del dispositivo Android. Este es un problema persistente que continúa ocurriendo incluso si detienes y reinicias el depurador. Para solucionar este problema, borra la caché de LLDB en $USER/.lldb/module-cache/.

El depurador nativo falla con el error de que el proceso de depuración finalizó con el código de salida 127

Este error se produce en plataformas basadas en Linux cuando se inicia el depurador nativo. Indica que una de las bibliotecas requeridas por el depurador nativo no está instalada en el sistema local. Es posible que el nombre de la biblioteca que falta ya esté impreso en el archivo idea.log. De lo contrario, puedes usar una terminal para navegar al directorio de instalación de Android Studio y ejecutar la línea de comandos bin/lldb/bin/LLDBFrontend --version para saber qué bibliotecas faltan. Por lo general, la biblioteca que falta es ncurses5, ya que algunas versiones recientes de Linux ya se actualizaron a ncurses6.

Generadores de perfiles

En esta sección, se describen los problemas conocidos relacionados con los generadores de perfiles.

Generador de perfiles de memoria nativo: el perfilado no está disponible durante el inicio de la app

El Generador de perfiles de memoria nativo no está disponible actualmente durante el inicio de la app. Esta opción estará disponible en una versión futura.

Como solución alternativa, puedes usar el generador de perfiles de línea de comandos de Perfetto para capturar perfiles de inicio.

Errores de tiempo de espera en el Generador de perfiles de CPU

Es posible que se generen errores del tipo "Recording failed to stop" en el Generador de perfiles de CPU de Android Studio cuando selecciones las opciones de configuración Sample Java Methods o Trace Java Methods. A menudo, son errores de tiempo de espera, especialmente si ves el siguiente mensaje de error en el archivo idea.log:

Wait for ART trace file timed out

Los errores de tiempo de espera tienden a afectar más a los métodos de seguimiento que a los métodos de muestreo, así como a las grabaciones más largas en comparación con las más cortas. Como solución temporal, puede ser útil probar grabaciones más cortas para ver si desaparece el error.

Si tienes problemas de tiempo de espera con el generador de perfiles, informa un error que incluya la marca o el modelo de tus dispositivos y cualquier entrada relevante de idea.log y logcat.

Excepción de ADB durante la depuración o la generación de perfiles

Si usas Platform Tools 29.0.3, es posible que la depuración nativa y los generadores de perfiles de Android Studio no funcionen correctamente y que veas "AdbCommandRejectedException" o "Failed to connect port" en el archivo idea.log cuando selecciones Help > Show Log. Si actualizas Platform Tools a la versión 29.0.4 o una posterior, se corregirán ambos problemas.

Para actualizar Platform Tools, haz lo siguiente:

  1. Abre SDK Manager desde Android Studio; para hacerlo, haz clic en Tools > SDK Manager o en SDK Manager en la barra de herramientas.

  2. Haz clic en la casilla de verificación junto a Android SDK Platform-Tools para que se muestre una marca de verificación. Debería aparecer un ícono de descarga en la columna izquierda.

  3. Haz clic en Apply o en OK.

El complemento impide que funcione la ventana Build Output

El uso del complemento CMake simple highlighter evita que el contenido aparezca en la ventana Build Output. Se ejecuta la compilación y aparece la pestaña Build Output, pero no se imprime ningún resultado (problema #204791544).

El pedido de instalación impide el lanzamiento

Si instalas una versión más reciente de Android Studio antes de una anterior, es posible que la versión anterior no se inicie. Por ejemplo, si primero instalas la versión canary de Android Studio y, luego, intentas instalar e iniciar la versión estable, es posible que la versión estable no se inicie. En casos como este, debes borrar la caché para iniciar la versión estable (más antigua). En macOS, borra el directorio Library/ApplicationSupport/Google/AndroidStudioversion_number para borrar la caché. En Windows, usa la opción Limpiar discos para borrar la caché.

La grabadora de pruebas Espresso no funciona con Compose

La grabadora de pruebas Espresso no funciona con proyectos que incluyen Compose. Si quieres crear pruebas de IU para proyectos que incluyen Compose, consulta Cómo probar tu diseño de Compose.

Conflicto de combinaciones de teclas Logcat con diseños de teclado que no están en inglés

Si usas un diseño de teclado que no está en inglés, es posible que una combinación de teclas predeterminada de Logcat entre en conflicto con el diseño y no te permita escribir determinados caracteres cuando edites texto en Android Studio. Para solucionar este problema, borra o reasigna el mapa de teclas Logcat en conflicto. Para editar los mapas de teclas de Logcat en Android Studio, ve a Android Studio > Settings > Keymap y busca Logcat en la lista de mapas de teclas. Para obtener más información, consulta el problema #263475910.

Este error se resolverá mediante la eliminación del acceso directo de Logcat en el parche eléctrico Electric Eel 1 de Android Studio.

Problemas conocidos con el complemento de Android para Gradle

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

No se realizó la verificación de lint de todas las dependencias de la biblioteca de funciones dinámicas

Cuando ejecutas lint con checkDependencies = true desde un módulo de app, no se verifican las dependencias de la biblioteca de funciones dinámicas, a menos que también sean dependencias de apps (problema #191977888). Como solución alternativa, la tarea de lint se puede ejecutar en esas bibliotecas.

Firma del archivo cuyo nombre contiene caracteres de retorno de carro

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

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

No es posible usar la API de Variant para manipular resultados de variantes con el complemento nuevo. 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, cuando intentes llamarlo, verás el siguiente error: 

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() para obtener el archivo de manifiesto para cada variante, puedes llamar a processManifest.manifestOutputDirectory() para que muestre 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)
        }
    }
}

Problemas con la compatibilidad con AIDL de AGP 7.3.0 y Kotlin 1.7.x

El uso de AGP 7.3.0 con KAPT en Kotlin 1.7.x hace que se eliminen los conjuntos de orígenes de AIDL para variantes de compilación específicas. Aún puedes usar los otros conjuntos de orígenes de AIDL, incluidos los de main/, los tipos de compilación, las variantes de productos y las combinaciones de variantes de productos. Si necesitas usar los conjuntos de orígenes de AIDL específicos de las variantes, sigue usando Kotlin 1.6.21.

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 de vista previa o estable más reciente.

Errores que se corrigieron en Android Studio 2021.1.1

  • Resultado de lint faltante: No hay salida de texto de lint impresa en stdout cuando la tarea de lint es UP-TO-DATE (problema #191897708). Se corrigió en AGP 7.1.0-alpha05.
  • Problemas con la prueba de unidades de un proyecto de app que usa el complemento de Hilt: La ruta de clase de la prueba de unidades contiene las clases de apps no instrumentadas, lo que significa que Hilt no instrumenta las clases de la app para administrar la inserción de dependencias cuando se ejecutan pruebas de unidades (problema #213534628). Se corrigió en AGP 7.1.1.

Errores que se corrigieron en Android Studio 2020.3.1

  • Excepciones de lint en proyectos de Kotlin: Es posible que los proyectos de Kotlin que configuran checkDependencies = true experimenten excepciones de puntero nulo o errores (problema #158777858).

Errores que se corrigieron en Android Studio 4.2

  • El IDE se bloquea en macOS Big Sur: Android Studio 4.1 podría bloquearse cuando abres un diálogo.

Errores que se corrigieron en Android Studio 4.1

  • Reinicia para aplicar la configuración de memoria desde una versión anterior de IDE: después de actualizar Android Studio, debes reiniciarlo para aplicar cualquier configuración de memoria migrada desde una versión anterior del IDE.
  • La clase de manifiesto con cadenas de permiso personalizadas ya no se genera de forma predeterminada: Si deseas generar la clase, configura android.generateManifestClass = true.

Errores que se corrigieron en Android Studio 3.6

  • Error de instalación de APK en LineageOS: la implementación de tu app en dispositivos que ejecutan ciertas versiones de LineageOS o CyanogenMod puede fallar y generar una excepción INSTALL_PARSE_FAILED_NOT_APK.

    En la versión beta 1 de Android Studio 3.6 y versiones posteriores, el IDE procesa esta excepción mediante una instalación completa de la app cuando la implementas en dispositivos LineageOS o CyanogenMod, lo que puede resultar en tiempos de implementación más prolongados.

Errores que se corrigieron en Android Studio 3.5.2

  • Estilo de código XML dañado: cuando se editó código XML, el IDE aplicó un estilo de código incorrecto cuando seleccionaste Code > Reformat Code en la barra de menú.

Errores que se corrigieron 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 él.