El sistema de compilación de Android Studio se basa en Gradle, y el complemento de Android para Gradle agrega varias funciones que son específicas para la compilación de apps para Android. Si bien el complemento para Android suele actualizarse en el paso de bloqueo con Android Studio, el complemento y el resto del sistema Gradle se pueden ejecutar independientemente de Android Studio y se pueden actualizar por separado.
En esta página, se explica cómo mantener tus herramientas de Gradle actualizadas y cuál es el contenido de las actualizaciones recientes.
Si quieres obtener un resumen general sobre los próximos cambios rotundos, consulta el plan del complemento de Android para Gradle.
A fin de obtener detalles para configurar tus compilaciones de Android con Gradle, consulta las siguientes páginas:
- Cómo configurar tu compilación
- Referencia del DSL del complemento para Android
- Referencia del DSL de Gradle
Si quieres obtener más información sobre el sistema de compilación de Gradle, consulta la Guía del usuario de Gradle.
Cómo actualizar el complemento de Android para Gradle
Si actualizas Android Studio, es posible que recibas una solicitud para actualizar automáticamente el complemento de Android para Gradle a la versión más reciente disponible. Puedes aceptar la actualización o especificar manualmente una versión, según los requisitos de compilación del proyecto.
Puedes especificar la versión del complemento en el menú File > Project Structure > Project en Android Studio o en el archivo build.gradle
de nivel superior. La versión del complemento se aplica a todos los módulos integrados en ese proyecto de Android Studio. En el siguiente ejemplo, se establece el complemento en la versión 7.1.2 del archivo build.gradle
:
Groovy
plugins { id 'com.android.application' version '7.1.2' apply false id 'com.android.library' version '7.1.2' apply false id 'org.jetbrains.kotlin.android' version '1.5.31' apply false }
Kotlin
plugins { id("com.android.application") version "7.1.2" apply false id("com.android.library") version "7.1.2" apply false id("org.jetbrains.kotlin.android") version "1.5.31" apply false }
Precaución: No debes usar dependencias dinámicas en los números de versión, como 'com.android.tools.build:gradle:2.+'
. El uso de esa función puede causar actualizaciones de versión inesperadas y dificultades para resolver diferencias entre versiones.
Si no se descargó la versión especificada del complemento, Gradle la descargará la próxima vez que compiles el proyecto o hagas clic en Files > Sync Project with Gradle Files en la barra de menú de Android Studio.
Cómo actualizar Gradle
Si actualizas Android Studio, es posible que recibas una solicitud para actualizar también Gradle a la versión más reciente disponible. Puedes aceptar la actualización o especificar manualmente una versión, según los requisitos de compilación del proyecto.
En la siguiente tabla, se muestra qué versión de Gradle se requiere para cada versión del complemento de Android para Gradle. Si quieres obtener el mejor rendimiento, deberías usar la versión más reciente de Gradle y del complemento.
Versión del complemento | Versión requerida de Gradle |
---|---|
1.0.0 - 1.1.3 | 2.2.1 - 2.3 |
1.2.0 - 1.3.1 | 2.2.1 - 2.9 |
1.5.0 | 2.2.1 - 2.13 |
2.0.0 - 2.1.2 | 2.10 - 2.13 |
2.1.3 - 2.2.3 | 2.14.1 - 3.5 |
2.3.0+ | 3.3+ |
3.0.0+ | 4.1+ |
3.1.0+ | 4.4+ |
3.2.0 - 3.2.1 | 4.6+ |
3.3.0 - 3.3.3 | 4.10.1+ |
3.4.0 - 3.4.3 | 5.1.1+ |
3.5.0 - 3.5.4 | 5.4.1+ |
3.6.0 - 3.6.4 | 5.6.4+ |
4.0.0+ | 6.1.1+ |
4.1.0+ | 6.5+ |
4.2.0+ | 6.7.1+ |
7.0 | 7.0+ |
7.1 | 7.2+ |
7.2 | 7.3+ |
Puedes especificar la versión de Gradle en el menú File > Project Structure > Project en Android Studio o editando la referencia de distribución de Gradle en el archivo gradle/wrapper/gradle-wrapper.properties
. En el siguiente ejemplo, se configura la versión de Gradle en 7.4.2 en el archivo gradle-wrapper.properties
.
...
distributionUrl = "https\://services.gradle.org/distributions/gradle-7.4.2-bin.zip"
...
Cambios en el control de versiones (noviembre de 2020)
Actualizaremos la numeración de versiones del complemento de Android para Gradle (AGP) a fin de que coincida mejor con la herramienta de compilación subyacente de Gradle.
Estos son algunos de los cambios más importantes:
AGP ahora usará el control de versiones semántico y los cambios rotundos se incluirán en las versiones principales.
Se lanzará una versión principal de AGP por año, que estará alineada con la actualización más importante de Gradle.
La versión posterior a AGP 4.2 será 7.0 y requerirá una actualización a Gradle 7.x. Cada lanzamiento importante de AGP requerirá una actualización importante de versión de la herramienta subyacente de Gradle.
Las API quedarán obsoletas aproximadamente con un año de anticipación y, al mismo tiempo, se pondrá a disposición una función de reemplazo. Aproximadamente un año después, se quitarán las API obsoletas en la próxima actualización importante.
7.1.0 (enero de 2022)
El complemento de Android para Gradle 7.1.0 es una actualización importante que incluye una variedad de nuevas funciones y mejoras.
7.1.3 (abril de 2022)
Esta actualización menor incluye las siguientes correcciones de errores:
- Problemas de clases duplicados informados por R8
Para ver una lista completa de las correcciones de errores que se incluyen en esta versión, consulta la entrada de blog del Parche 3 de Android Studio Bumblebee.
7.1.2 (febrero de 2022)
Esta actualización menor incluye las siguientes correcciones de errores:
- El complemento de Gradle para Android 7.1.0-rc01 no realiza la transformación del código de bytes ASM durante las pruebas de unidades.
- La sincronización de Gradle falla y muestra "Unable to load class 'com.android.build.api.extension.AndroidComponentsExtension'".
- No se pueden usar algunos bloques de DSL nuevos de Groovy DSL en complemento de Android para Gradle 7.0.0.
- La nueva API de publicación de AGP 7.1: el jar de javadoc no se firma.
- ClassesDataSourceCache debe usar la última versión de Asm.
- Android Studio BumbleBee no siempre implementa los cambios más recientes.
Para ver una lista completa de las correcciones de errores que se incluyen en esta versión, consulta la entrada de blog del Parche 2 de Android Studio Bumblebee.
7.1.1 (febrero de 2022)
Esta actualización menor corresponde al lanzamiento del Parche 1 de Android Studio Bumblebee.
Para ver una lista de las correcciones de errores que se incluyen en esta versión, consulta la entrada de blog del Parche 1 de Android Studio Bumblebee.
Compatibilidad
Versión mínima | Versión predeterminada | Notas | |
---|---|---|---|
Gradle | 7.2 | 7.2 | Para obtener más información, consulta cómo actualizar Gradle. |
Herramientas de desarrollo del SDK | 30.0.3 | 30.0.3 | Instala o configura las herramientas de compilación del SDK. |
NDK | N/A | 21.4.7075529 | Instala o configura una versión diferente del NDK. |
JDK | 11 | 11 | Para obtener más información, consulta cómo configurar la versión de JDK. |
La tarea de análisis de lint ahora se puede almacenar en caché
El objeto AndroidLintAnalysisTask
ahora es compatible con la caché de compilación de Gradle.
Si para habilitar la caché de compilación configuras org.gradle.caching=true
en tu archivo gradle.properties
, la tarea de análisis de lint obtendrá su resultado de la caché de compilación cuando sea posible.
La tarea de análisis de lint es con frecuencia el mayor cuello de botella cuando se ejecuta lint con el complemento de Android para Gradle. Por eso, habilitar la caché de compilación mejora la velocidad de compilación cuando ejecuta lint en muchas situaciones. Deberías ver una mejora notable en el rendimiento, por ejemplo, si tienes un proyecto de varios módulos y limpias el directorio de compilación antes de ejecutar lint en tu servidor de CI.
Los módulos de C/C++ ahora pueden hacer referencia a otros módulos de C/C++ del mismo proyecto
Un módulo de Android para Gradle con código C/C++ ahora se puede configurar para hacer referencia a archivos de encabezado y código de biblioteca en otro módulo de Gradle. El protocolo Prefab se usa para comunicar los encabezados y las bibliotecas entre módulos de Gradle.
Requisitos
El módulo consuming debe ser
CMake
y nondk-build
. La compatibilidad con ndk-build requerirá una actualización futura del NDK. El módulo publishing puede serCMake
ondk-build
.El módulo consuming debe habilitar
prefab
en el archivobuild.gradle
.
android {
buildFeatures {
prefab true
}
}
- El módulo publishing debe habilitar
prefabPublishing
en el archivobuild.gradle
.
android {
buildFeatures {
prefabPublishing true
}
}
- El módulo consuming debe hacer referencia al módulo publishing al agregar una línea en el bloque
dependencies
del archivobuild.gradle
. Por ejemplo:
dependencies {
implementation project(':mylibrary')
}
- El módulo publishing debe exponer un paquete mediante una sección
prefab
. Por ejemplo:
android {
prefab {
mylibrary {
libraryName "libmylibrary"
headers "src/main/cpp/include"
}
}
}
- El archivo
CMakeLists.txt
del módulo de consumo puede usarfind_package()
para ubicar el paquete publicado por el módulo de producción. Por ejemplo:
find_package(mylibrary REQUIRED CONFIG)
target_link_libraries(
myapplication
mylibrary::mylibrary)
- Debe haber una STL para toda la aplicación. Por ejemplo, tanto los módulos de consumo como los de publicación pueden usar la STL compartida de C++.
android {
defaultConfig {
externalNativeBuild {
cmake {
arguments '-DANDROID_STL=c++_shared'
}
}
}
}
Para obtener una explicación más detallada sobre cómo configurar consumidores y productores de AAR nativos con AGP, consulta Dependencias nativas con AGP.
Configuración del repositorio en el archivo settings.gradle
Cuando se crea un proyecto nuevo en Android Studio Bumblebee, el archivo build.gradle
de nivel superior contiene el bloque plugins
, seguido del código para limpiar el directorio de compilación:
plugins {
id 'com.android.application' version '7.1.0-beta02' apply false
id 'com.android.library' version '7.1.0-beta02' apply false
id 'org.jetbrains.kotlin.android' version '1.5.30' apply false
}
task clean(type: Delete) {
delete rootProject.buildDir
}
La configuración del repositorio que antes estaba en el archivo build.gradle
de nivel superior ahora está en el archivo settings.gradle
:
pluginManagement {
repositories {
gradlePluginPortal()
google()
mavenCentral()
}
}
dependencyResolutionManagement {
repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)
repositories {
google()
mavenCentral()
}
}
rootProject.name = 'GradleManagedDeviceTestingNew'
include ':app'
El archivo build.gradle
de nivel de módulo no cambió. Por lo tanto, usa el archivo build.gradle
de nivel superior y el archivo settings.gradle
para definir las configuraciones de compilación que se aplican a todos los módulos de tu proyecto, o los repositorios y las dependencias que se aplican a Gradle. Usa el archivo build.gradle
de nivel de módulo para definir configuraciones de compilación que sean específicas de un módulo determinado dentro del proyecto.
Reductor de recursos mejorado
Android Studio Bumblebee incluye un reductor de recursos mejorado que ayuda a reducir el tamaño de tu app.
Compatibilidad con apps que tienen funciones dinámicas
Se actualizó la implementación predeterminada del reductor de recursos de Android en el complemento de Android para Gradle 7.1.0-alpha09. La implementación nueva admite la reducción de apps con funciones dinámicas.
Reducciones adicionales y experimentales del tamaño de la app
La nueva implementación del reductor de recursos puede reducir aún más el tamaño de la app reducida si modificas la tabla de recursos para quitar los recursos de valor que no se usan y las referencias a los recursos de archivos no usados. El nuevo reductor de recursos puede borrar por completo recursos de archivos no utilizados, lo que reduce aún más el tamaño de la app. Este comportamiento aún no está habilitado de forma predeterminada, pero puedes probarlo. Para ello, agrega la opción experimental android.experimental.enableNewResourceShrinker.preciseShrinking=true
al archivo gradle.properties
del proyecto.
Informa cualquier problema que tengas con el reductor de recursos nuevo o la marca experimental. Para ayudarte a diagnosticar problemas o como una solución temporal, puedes volver a la implementación anterior. Para ello, agrega android.enableNewResourceShrinker=false
al gradle.properties
de tu proyecto.
El reductor nuevo reemplaza los recursos basados en archivos sin usar por archivos mínimos ligeramente diferentes a los del reductor de recursos anterior. No se espera que esto afecte el tiempo de ejecución.
Se programó la eliminación de la implementación anterior en el complemento de Android para Gradle 8.0.0.
Publicación de variantes de compilación
El complemento de Android para Gradle 7.1.0 y versiones posteriores te permiten configurar qué variantes de compilación publicar en un repositorio de Maven de Apache. AGP crea un componente con una o varias variantes de compilación basadas en el nuevo DSL de publicación, que puedes usar para personalizar una publicación en un repositorio de Maven. En comparación con las versiones anteriores, esto también elimina el trabajo innecesario, ya que no se crearán componentes de forma predeterminada. Para obtener más información, consulta la muestra de código de publicación.
Publicación del JAR de Javadoc
AGP 7.1.0 y versiones posteriores te permiten generar Javadoc desde fuentes Java y Kotlin, y publicar archivos JAR de Javadoc, además de AAR para proyectos de biblioteca. Se agrega Javadoc a los archivos de POM y metadatos del módulo Gradle. Para habilitar esta función, agrega withJavadocJar()
en el bloque de publicación singleVariant
o multipleVariants
. Para obtener más información, consulta la muestra de código de opciones de publicación.
Publicación de fuentes de JAR
AGP 7.1.0 y versiones posteriores te permiten publicar archivos JAR de origen de Java y Kotlin, además de AAR para proyectos de biblioteca. Las fuentes se agregan a los archivos de POM y metadatos del módulo Gradle. Para habilitar esta función, agrega withSourcesJar()
en el bloque de publicación singleVariant
o multipleVariants
. Para obtener más información, consulta la muestra de código de opciones de publicación.
Cambio semántico del bloque lint
Todos los métodos de lint que anulan el nivel de gravedad de un problema (enable
, disable
/ignore
, informational
, warning
, error
, fatal
) ahora respetan el orden de la configuración. Por ejemplo, si se configura un problema como fatal en finalizeDsl()
, ahora se anula la inhabilitación en el DSL principal. Para obtener más información, consulta los documentos de referencia del bloque lint{}
y los puntos de extensión y flujo de la compilación de Android.
Compatibilidad con Navigation Safe Args
Se quitaron las API de AGP de las que dependen el complemento de Gradle para Navigation Safe Args. AGP 7.1 no funciona con las versiones 2.4.0-rc1 o 2.4.0 de Navigation Safe Args, pero funcionará con las versiones 2.5.0-alpha01 y 2.4.1. Mientras tanto, como solución alternativa, puedes usar AGP 7.1 con una compilación de resúmenes de Navigation Safe Args, Navigation 2.5.0-SNAPSHOT. Para usar la compilación de resúmenes, sigue las instrucciones del resumen con el ID de compilación #8054565.
Además, las versiones 2.4.1 y 2.5.0 de Navigation Safe Args ya no funcionarán con AGP 4.2. Para usar esas versiones de Safe Args, debes usar AGP 7.0 y versiones posteriores.
Inhabilita la creación automática de componentes
A partir de AGP 8.0, se inhabilitará de forma predeterminada la creación automática de componentes.
En la actualidad, AGP 7.1 crea automáticamente un componente para cada variante de compilación, que tiene el mismo nombre que la variante de compilación, y un componente all
que contiene todas las variantes de compilación. Esta creación automática de componentes se inhabilitará. Para realizar la transición al nuevo comportamiento, debes inhabilitar manualmente la creación automática de componentes mediante la configuración de android.disableAutomaticComponentCreation
en true.
. Para obtener más información, consulta
Cómo usar el complemento de Maven Publish.
Compatibilidad con Firebase Performance Monitoring
AGP 7.1 no es compatible con la versión 1.4.0 del complemento de Gradle de Firebase Performance Monitoring y versiones anteriores. El Asistente de actualización de AGP no actualizará de automáticamente el complemento a la versión 1.4.1, por lo que, si usas firebase-perf
y deseas actualizar AGP a la versión 7.1, debes realizar esta actualización específica de forma manual.
Errores conocidos
En esta sección, se describen los problemas conocidos presentes en el complemento de Android para Gradle 7.1.0.
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 controlar la inserción de dependencias cuando se ejecutan pruebas de unidades.
Este error se solucionará en la versión 7.1.1. Consulta el error #213534628.
7.0.0 (julio de 2021)
El complemento de Android para Gradle 7.0.0 es una actualización importante que incluye una variedad de nuevas funciones y mejoras.
7.0.1 (agosto de 2021)
Esta actualización menor incluye diversas correcciones de errores. Para ver una lista de las correcciones de errores más importantes, consulta la publicación relacionada en el blog de actualizaciones de versiones.
Compatibilidad
Versión mínima | Versión predeterminada | Notas | |
---|---|---|---|
Gradle | 7.0.2 | 7.0.2 | Para obtener más información, consulta cómo actualizar Gradle. |
Herramientas de desarrollo del SDK | 30.0.2 | 30.0.2 | Instala o configura las herramientas de compilación del SDK. |
NDK | N/A | 21.4.7075529 | Instala o configura una versión diferente del NDK. |
JDK | 11 | 11 | Para obtener más información, consulta cómo configurar la versión de JDK. |
Se requiere JDK 11 para ejecutar AGP 7.0
Cuando usas el complemento de Android para Gradle 7.0 a fin de compilar tu app, ahora se requiere JDK 11 para ejecutar Gradle. Android Studio Arctic Fox empaqueta JDK 11 y configura Gradle para usarlo de forma predeterminada. Esto significa que la mayoría de los usuarios de Android Studio no necesitan hacer cambios de configuración en sus proyectos.
Si necesitas configurar manualmente la versión de JDK que usa AGP dentro de Android Studio, debes usar JDK 11 o una versión posterior.
Cuando uses AGP independientemente de Android Studio, actualiza la versión de JDK configurando la variable de entorno JAVA_HOME o la opción de línea de comandos -Dorg.gradle.java.home
en el directorio de instalación de JDK 11.
API de variantes estable
La nueva API de variantes ahora es estable. Consulta las interfaces nuevas en el paquete com.android.build.api.variant y los ejemplos en el proyecto gradle-recipes de GitHub. Como parte de la nueva API de variantes, pusimos a disposición varios archivos intermedios, llamados artefactos, a través de la interfaz Artifacts. Esos artefactos, como el manifiesto combinado, se pueden obtener y personalizar de manera segura con complementos y código de terceros.
A fin de seguir ampliando la API de variantes, incorporaremos nuevas funciones y aumentaremos la cantidad de artefactos intermedios que estarán disponibles para la personalización.
Cambios de comportamiento de lint
En esta sección, se describen varios cambios de comportamiento de lint en el complemento de Android para Gradle 7.0.0.
Lint mejorado para dependencias de biblioteca
Ahora lint se ejecuta con checkDependencies = true
más rápido que antes.
En el caso de los proyectos de Android que consisten en una app con dependencias de biblioteca, se recomienda establecer checkDependencies
en true
como se muestra a continuación y ejecutar lint a través de ./gradlew :app:lint
, que analizará todos los módulos de dependencias en paralelo y generará un solo informe, que incluirá problemas de la app y todas sus dependencias.
Groovy
// build.gradle android { ... lintOptions { checkDependencies true } }
Kotlin
// build.gradle.kts android { ... lint { isCheckDependencies = true } }
Las tareas de lint ahora pueden estar actualizadas
Si las fuentes y los recursos de un módulo no cambiaron, no es necesario volver a ejecutar la tarea de análisis de lint para el módulo. Cuando esto sucede, la ejecución de la tarea se muestra como "UP-TO-DATE" en los resultados de Gradle. Con este cambio, cuando ejecutes lint en un módulo de aplicación con checkDependencies = true
, solo los módulos que hayan cambiado deberán ejecutar su análisis. Como resultado, lint puede ejecutarse aún más rápido.
Tampoco se debe ejecutar la tarea de generación de informe de lint si sus entradas no cambiaron. Un problema conocido relacionado es que no hay resultados de texto de lint impresos en stdout cuando la tarea de lint está UP-TO-DATE (problema #191897708).
Cómo ejecutar lint en módulos de funciones dinámicas
AGP ya no permite ejecutar lint desde módulos de funciones dinámicas. Cuando se ejecute lint desde el módulo de aplicaciones correspondiente, se ejecutará en sus módulos de funciones dinámicas y se incluirán todos los errores en el informe de lint de la app. Un problema conocido relacionado es que, cuando lint se ejecuta con checkDependencies = true
desde un módulo de app, las dependencias de la biblioteca de funciones dinámicas no se verifican, a menos que también sean dependencias de apps (problema #191977888).
Cómo ejecutar lint solo en la variante predeterminada
Cuando se ejecuta ./gradlew :app:lint
, ahora lint solo se ejecuta para la variante predeterminada.
En las versiones anteriores de AGP, lint se ejecutaba para todas las variantes.
Advertencias de clases faltantes en el reductor R8
R8 maneja las clases faltantes y la opción -dontwarn
de manera más precisa y coherente. Por lo tanto, debes comenzar a evaluar las advertencias de clases faltantes que emite R8.
Cuando R8 encuentre una referencia de clase que no esté definida en tu app o en una de sus dependencias, emitirá una advertencia que se mostrará en el resultado de compilación. Por ejemplo:
R8: Missing class: java.lang.instrument.ClassFileTransformer
Esta advertencia indica que no se pudo encontrar la definición de clase java.lang.instrument.ClassFileTransformer
cuando se analizaba el código de la app. Si bien esto suele significar que hay un error, es posible que quieras ignorar esta advertencia. Dos motivos comunes para ignorar la advertencia son los siguientes:
Las bibliotecas que se orientan a la JVM y a la clase faltante son del tipo de biblioteca de JVM (como en el ejemplo anterior).
Una de tus dependencias usa una API de solo tiempo de compilación.
Para ignorar una advertencia de clase faltante, agrega una regla -dontwarn
a tu archivo proguard-rules.pro
. Por ejemplo:
-dontwarn java.lang.instrument.ClassFileTransformer
Para mayor comodidad, AGP generará un archivo que contenga todas las reglas potencialmente faltantes y las escribirá en una ruta de acceso de archivo como la siguiente: app/build/outputs/mapping/release/missing_rules.txt
. Agrega las reglas a tu archivo proguard-rules.pro
para ignorar las advertencias.
En AGP 7.0, los mensajes de clase faltantes aparecerán como advertencias, y podrás convertirlos en errores si configuras android.r8.failOnMissingClasses = true
en gradle.properties
.
En AGP 8.0, estas advertencias se convertirán en errores que afectarán a tu compilación. Es posible conservar el comportamiento de AGP 7.0 si agregas la opción -ignorewarnings
a tu archivo proguard-rules.pro
, pero no es recomendable.
Se quitó la caché de compilación del complemento de Android para Gradle
Se quitó la caché de compilación de AGP en AGP 4.1. La caché de compilación de AGP se introdujo en AGP 2.3 para complementar la caché de compilación de Gradle, y esta la sustituyó por completo en AGP 4.1. Este cambio no afecta al tiempo de compilación.
En AGP 7.0, se quitaron las propiedades android.enableBuildCache
y android.buildCacheDir
, y la tarea cleanBuildCache
.
Usa el código fuente de Java 11 en tu proyecto
Ahora puedes compilar código fuente hasta Java 11 en el proyecto de tu app, lo que te permite usar funciones de lenguaje más nuevas, como métodos de interfaz privada, el operador Diamante para clases anónimas y sintaxis de variables locales para parámetros lambda.
A fin de habilitar esta función, establece compileOptions
como la versión de Java deseada y compileSdkVersion
en 30 o más:
Groovy
// build.gradle android { compileSdkVersion 30 compileOptions { sourceCompatibility JavaVersion.VERSION_11 targetCompatibility JavaVersion.VERSION_11 } // For Kotlin projects kotlinOptions { jvmTarget = "11" } }
Kotlin
// build.gradle.kts android { compileSdkVersion(30) compileOptions { sourceCompatibility(JavaVersion.VERSION_11) targetCompatibility(JavaVersion.VERSION_11) } kotlinOptions { jvmTarget = "11" } }
Se quitaron las configuraciones de dependencias
En AGP 7.0, se quitaron los siguientes parámetros de configuración (o permisos de dependencia):
compile
Según el caso de uso, esto se reemplazó conapi
oimplementation
.
También se aplica a las variantes *Compile. Por ejemplo:debugCompile
.provided
Se reemplazó porcompileOnly
.
También se aplica a las variantes *Provided. Por ejemplo:releaseProvided
.apk
Se reemplazó porruntimeOnly
.publish
Se reemplazó porruntimeOnly
.
En la mayoría de los casos, el Asistente de actualización del AGP migrará automáticamente tu proyecto a las configuraciones nuevas.
Cambio de ruta de clase cuando compilas con el complemento de Android para Gradle
Si compilas con el complemento de Android para Gradle, la ruta de clase de la compilación puede cambiar. Debido a que AGP ahora usa configuraciones api/implementation
internamente, es posible que se quiten algunos artefactos de la ruta de clase de la compilación. Si necesitas una dependencia de AGP durante la compilación, asegúrate de agregarla como una dependencia explícita.
No se admite la adición de bibliotecas nativas a una carpeta de recursos de Java
Anteriormente, podías agregar una biblioteca nativa en una carpeta de recursos de Java y registrar la carpeta con android.sourceSets.main.resources.srcDirs
para que se extrajera la biblioteca nativa y se agregara al APK final. A partir de AGP 7.0, esto no es compatible y se ignoran las bibliotecas nativas en una carpeta de recursos de Java. En su lugar, usa el método DSL destinado a bibliotecas nativas, android.sourceSets.main.jniLibs.srcDirs
. Para obtener más información, consulta cómo configurar conjuntos de orígenes.
Errores conocidos
En esta sección, se describen los problemas conocidos presentes en el complemento de Android para Gradle 7.0.0.
Incompatibilidad con el complemento multiplataforma 1.4.x de Kotlin
El complemento de Android para Gradle 7.0.0 es compatible con el complemento multiplataforma de Kotlin 1.5.0 y versiones posteriores. Los proyectos que utilizan la compatibilidad con varias plataformas de Kotlin deben actualizarse a Kotlin 1.5.0 para usar el complemento de Android para Gradle 7.0.0. Como solución alternativa, puedes cambiar el complemento de Android para Gradle a la versión inferior 4.2.x, aunque no se recomienda.
Para obtener más información, consulta KT-43944.
Falta el resultado de lint
No hay resultados de texto de lint impresos en stdout cuando la tarea lint está actualizada (problema #191897708). Para obtener más información, consulta Cambios de comportamiento de lint. Este problema se solucionará en el complemento de Android para Gradle 7.1.
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. Para obtener más información, consulta Cambios de comportamiento de lint.
4.2.0 (marzo de 2021)
Compatibilidad
Versión mínima | Versión predeterminada | Notas | |
---|---|---|---|
Gradle | 6.7.1 | N/A | Para obtener más información, consulta cómo actualizar Gradle. |
Herramientas de desarrollo del SDK | 30.0.2 | 30.0.2 | Instala o configura las herramientas de compilación del SDK. |
NDK | N/A | 21.4.7075529 | Instala o configura una versión diferente del NDK. |
Funciones nuevas
Esta versión del complemento de Android para Gradle incluye las siguientes funciones nuevas:
Versión 8 del lenguaje Java según la configuración predeterminada
A partir de la versión 4.2, el AGP usará el nivel de lenguaje Java 8 de forma predeterminada. Java 8 proporciona acceso a varias funciones más recientes del lenguaje, incluidas las expresiones lambda, las referencias de métodos y los métodos de la interfaz estáticos. Si quieres obtener una lista completa de las funciones compatibles, consulta la documentación de Java 8.
Para mantener el comportamiento anterior, especifica Java 7 de forma explícita en el archivo build.gradle.kts
o build.gradle
de nivel de módulo:
Groovy
// build.gradle android { ... compileOptions { sourceCompatibility JavaVersion.VERSION_1_7 targetCompatibility JavaVersion.VERSION_1_7 } // For Kotlin projects, compile to Java 6 instead of 7 kotlinOptions { jvmTarget = "1.6" } }
Kotlin
// build.gradle.kts android { ... compileOptions { sourceCompatibility = JavaVersion.VERSION_1_7 targetCompatibility = JavaVersion.VERSION_1_7 } // For Kotlin projects, compile to Java 6 instead of 7 kotlinOptions { jvmTarget = "1.6" } }
Nuevo compilador de recursos JVM
Un nuevo compilador de recursos JVM del complemento de Android para Gradle 4.2 reemplaza parte del compilador de recursos AAPT2, lo que podría mejorar el rendimiento de compilación, especialmente en los equipos con Windows. El nuevo compilador de recursos JVM viene habilitado de forma predeterminada.
Las firmas v3 y v4 ahora son compatibles
El complemento de Gradle para Android 4.2 ahora es compatible con los formatos de firma APK v3 y APK v4.
Para habilitar uno o ambos formatos en tu compilación, agrega las siguientes propiedades a tu archivo build.gradle
o build.gradle.kts
a nivel de módulo:
Groovy
// build.gradle android { ... signingConfigs { config { ... enableV3Signing true enableV4Signing true } } }
Kotlin
// build.gradle.kts android { ... signingConfigs { config { ... enableV3Signing = true enableV4Signing = true } } }
La firma de APK v4 te permite implementar rápidamente APK grandes mediante la instalación de APK de adb incremental en Android 11. Esta nueva marca se encarga del paso de la firma del APK en el proceso de implementación.
Cómo configurar la firma de apps por variante
Ahora es posible habilitar o inhabilitar la firma de apps en el complemento de Android para Gradle por variante.
En este ejemplo, se muestra cómo establecer la firma de apps por variante con el método onVariants()
en Kotlin o Groovy:
androidComponents {
onVariants(selector().withName("fooDebug"), {
signingConfig.enableV1Signing.set(false)
signingConfig.enableV2Signing.set(true)
})
Nueva propiedad de Gradle: android.native.buildOutput
A fin de ordenar el resultado de la compilación, AGP 4.2 filtra los mensajes de las compilaciones nativas que usan CMake y ndk-build
, y solo muestra el resultado del compilador C/C++. de forma predeterminada. Anteriormente, se mostraba una línea de resultado por cada archivo compilado, lo que generaba una gran cantidad de mensajes informativos.
Si deseas ver el resultado nativo completo, configura la nueva propiedad de Gradle android.native.buildOutput
como verbose
.
Puedes configurar esta propiedad en el archivo gradle.properties
o por medio de la línea de comandos.
gradle.properties
android.native.buildOutput=verbose
Línea de comandos
-Pandroid.native.buildOutput=verbose
El valor predeterminado de esta propiedad es quiet
.
Cambio de comportamiento de los archivos gradle.properties
A partir de AGP 4.2, ya no se pueden anular las propiedades de Gradle en los subproyectos. En otras palabras, se ignorarán las propiedades que declares en un archivo gradle.properties
dentro de un subproyecto en lugar de hacerlo en el proyecto raíz.
Por ejemplo, en versiones anteriores, AGP leía los valores de projectDir/gradle.properties
, projectDir/app/gradle.properties
, projectDir/library/gradle.properties
, etc. Para los módulos de apps, si la misma propiedad de Gradle se encontraba en projectDir/gradle.properties
y projectDir/app/gradle.properties
, el valor de projectDir/app/gradle.properties
tenía prioridad.
En AGP 4.2, se modificó este comportamiento, de modo que AGP ya no cargará valores de gradle.properties
que estén en subproyectos (p. ej.,
projectDir/app/gradle.properties
). Este cambio refleja el nuevo comportamiento de Gradle y admite el almacenamiento en caché de configuración.
Si quieres obtener más información para establecer valores en archivos gradle.properties
, consulta la documentación de Gradle.
Cambios en la compatibilidad y la configuración de Gradle
Cuando se ejecuta en Android Studio, la herramienta de compilación de Gradle usa el JDK incluído en el paquete de Studio. En las versiones anteriores, se empaquetaba el JDK 8 con Studio. Sin embargo, en 4.2, ahora se incluye el JDK 11. Cuando se ejecuta el nuevo JDK empaquetado con Gradle, es posible que se generen algunas incompatibilidades o se vea afectado el rendimiento de JVM debido a los cambios en el recolector de elementos no utilizados. Estos errores se describen a continuación.
Nota: Si bien recomendamos ejecutar Gradle con JDK 11, es posible cambiar el JDK que se usó para ejecutar Gradle en el diálogo Project Structure. Si ajustas esta configuración, solo cambiarás el JDK con el cual se ejecutará Gradle, pero no el que se usa para ejecutar Studio en sí.
Compatibilidad de Studio con el complemento de Android para Gradle (AGP)
Android Studio 4.2 puede abrir proyectos que usen AGP 3.1 y versiones posteriores, siempre y cuando AGP ejecute Gradle 4.8.1 y versiones posteriores. Para obtener más información sobre la compatibilidad de Gradle, consulta Cómo actualizar Gradle.
Cómo optimizar las compilaciones de Gradle para JDK 11
Esta actualización a JDK 11 afecta la configuración predeterminada del recolector de elementos no utilizados de JVM, ya que el JDK 8 usa el recolector paralelo, mientras que el JDK 11 usa el recolector G1.
A fin de mejorar potencialmente el rendimiento de compilación, te recomendamos que pruebes las compilaciones de Gradle con el recolector de elementos no utilizados paralelo. En gradle.properties
, establece lo siguiente:
org.gradle.jvmargs=-XX:+UseParallelGC
Si ya hay otras opciones configuradas en este campo, agrega una opción nueva:
org.gradle.jvmargs=-Xmx1536m -XX:+UseParallelGC
Para medir la velocidad de compilación con diferentes configuraciones, consulta Cómo generar un perfil para tu compilación.
Archivos DEX sin comprimir en APK cuando minSdk
es igual a 28 o superior
AGP ahora empaqueta archivos DEX sin comprimir en APK de forma predeterminada cuando minSdk
es igual a 28 o superior. Esto genera un aumento en el tamaño del APK, pero genera un tamaño de instalación más pequeño en el dispositivo. El tamaño de descarga es más o menos igual.
Para forzar a que AGP en cambio empaquete archivos DEX comprimidos, puedes agregar lo siguiente a tu archivo build.gradle
:
android {
packagingOptions {
dex {
useLegacyPackaging true
}
}
}
Cómo usar el DSL para empaquetar bibliotecas nativas comprimidas
Recomendamos empaquetar bibliotecas nativas en un formato sin comprimir, ya que esto reduce el tamaño de instalación de la app, el tamaño de descarga y el tiempo de carga de la app para los usuarios. Sin embargo, si quieres que el complemento de Android para Gradle empaquete bibliotecas nativas comprimidas cuando compiles tu app, establece useLegacyPackaging
en true
en el archivo build.gradle
de tu app.
android {
packagingOptions {
jniLibs {
useLegacyPackaging true
}
}
}
La marca useLegacyPackaging
reemplaza el atributo del manifiesto extractNativeLibs
.
Para obtener más información, consulta la nota de la versión Bibliotecas nativas empaquetadas sin comprimir de forma predeterminada.
4.1.0 (agosto de 2020)
Compatibilidad
Versión mínima | Versión predeterminada | Notas | |
---|---|---|---|
Gradle | 6.5 | N/A | Para obtener más información, consulta cómo actualizar Gradle. |
Herramientas de desarrollo del SDK | 29.0.2 | 29.0.2 | Instala o configura las herramientas de compilación del SDK. |
NDK | N/A | 21.1.6352462 | Instala o configura una versión diferente del NDK. |
Funciones nuevas
Esta versión del complemento de Android para Gradle incluye las siguientes funciones nuevas:
Compatibilidad con la secuencia de comandos DSL de Kotlin
Para ayudar a mejorar la experiencia de edición de los usuarios buildscript de Kotlin, ahora el DSL y las API del complemento de Android para Gradle 4.1 se definen en un conjunto de interfaces Kotlin independientes de las clases de implementación. Eso significa lo siguiente:
- La nulabilidad y la mutación ahora se declaran de forma explícita en los tipos de Kotlin.
- La documentación que se genera a partir de esas interfaces se publica en la referencia de la API de Kotlin.
- La plataforma de la API del complemento de Android para Gradle está claramente definida a fin de que las extensiones de las compilaciones de Android sean menos inestables en el futuro.
Los tipos de colección diseñados para mutar en el DSL ahora se definen de manera uniforme de la siguiente manera:
val collection: MutableCollectionType
Eso significa que ya no es posible escribir lo siguiente en las secuencias de comandos de Kotlin para algunas colecciones que antes lo admitían:
collection = collectionTypeOf(...)
Sin embargo, la mutación de la colección es compatible de manera uniforme, por lo que collection += …
y collection.add(...)
ahora deberían funcionar en todas partes.
Si encuentras algún problema cuando actualizas un proyecto que usa las API y el DSL de Kotlin del complemento de Android para Gradle, informa un error.
Cómo exportar dependencias C/C++ desde AAR
El complemento de Android para Gradle 4.0 agregó la capacidad de importar paquetes Prefab en dependencias de AAR. En el AGP 4.1, ahora es posible exportar bibliotecas desde tu compilación nativa externa en un AAR para un proyecto de biblioteca de Android.
Para exportar tus bibliotecas nativas, agrega lo siguiente al bloque android
del archivo build.gradle
de tu proyecto de biblioteca.
Groovy
buildFeatures { prefabPublishing true } prefab { mylibrary { headers "src/main/cpp/mylibrary/include" } myotherlibrary { headers "src/main/cpp/myotherlibrary/include" } }
Kotlin
buildFeatures { prefabPublishing = true } prefab { create("mylibrary") { headers = "src/main/cpp/mylibrary/include" } create("myotherlibrary") { headers = "src/main/cpp/myotherlibrary/include" } }
En este ejemplo, las bibliotecas mylibrary
y myotherlibrary
de tu ndk-build o compilación nativa externa de CMake se empaquetarán en el AAR que generó tu compilación, y cada una exportará los encabezados del directorio especificado a sus dependientes.
Compatibilidad de R8 con metadatos de Kotlin
Kotlin utiliza metadatos personalizados en los archivos de clase de Java a fin de identificar las construcciones de lenguaje Kotlin. R8 ahora es compatible con el mantenimiento y la reescritura de metadatos de Kotlin para admitir por completo la reducción de bibliotecas y aplicaciones de Kotlin mediante kotlin-reflect
.
Para conservar los metadatos de Kotlin, agrega las siguientes reglas:
-keep class kotlin.Metadata { *; }
-keepattributes RuntimeVisibleAnnotations
Eso le indicará a R8 que conserve los metadatos de Kotlin para todas las clases que se guardan en forma directa.
Para obtener más información, consulta Cómo reducir las bibliotecas y las aplicaciones de Kotlin mediante su reflexión con R8 en Medium.
Aserciones en compilaciones de depuración
Cuando compilas la versión de depuración de tu app con el complemento de Android para Gradle 4.1.0 y versiones posteriores, el compilador integrado (D8) reescribe el código de tu app para habilitar las aserciones durante el tiempo de compilación, de modo que siempre tengas comprobaciones de aserción activas.
Cambios en el comportamiento
Se quitó la caché de compilación del complemento de Android para Gradle
Se quitó la caché de compilación de AGP en AGP 4.1. Introducida en AGP 2.3 para complementar la caché de compilación de Gradle, la caché de compilación de AGP se reemplazó por completo por la caché de compilación de Gradle en AGP 4.1. Este cambio no afecta el tiempo de compilación.
La tarea cleanBuildCache
y las propiedades android.enableBuildCache
y android.buildCacheDir
dejaron de estar disponibles y se quitarán en AGP 7.0. Actualmente, la propiedad android.enableBuildCache
no tiene efecto, mientras que la propiedad android.buildCacheDir
y la tarea cleanBuildCache
estarán disponibles hasta que AGP 7.0 borre cualquier contenido de caché de compilación AGP existente.
Se achicó significativamente el tamaño de la app para las apps que usan la reducción de código.
A partir de esta versión, los campos de las clases R ya no se conservan de forma predeterminada, lo que puede generar un ahorro de tamaño significativo en el APK para las apps que permiten la reducción de código. Esto no debería generar un cambio en el comportamiento, a menos que accedas a las clases R por reflejo, en cuyo caso es necesario agregar reglas de conservación para esas clases R.
Se cambió el nombre de la propiedad android.namespacedRClass por android.nonTransitiveRClass
Se cambió el nombre de la marca experimental android.namespacedRClass
por android.nonTransitiveRClass
.
En el archivo gradle.properties
, esta marca habilita el espacio de nombres de la clase R de cada biblioteca para que su clase R incluya solo los recursos declarados en la biblioteca y ninguno de las dependencias de la biblioteca, lo que reduce el tamaño de la clase R para esa biblioteca.
DSL de Kotlin: coreLibraryDesugaringEnabled cambió de nombre
Se cambió la opción de compilación coreLibraryDesugaringEnabled
de DSL de Kotlin a isCoreLibraryDesugaringEnabled
.
Para obtener más información sobre esta marca, consulta Compatibilidad con la expansión de sintaxis de API en Java 8 y versiones posteriores (complemento de Gradle para Android 4.0.0 y versiones posteriores).
Se quitaron las propiedades de la versión de la clase BuildConfig en proyectos de biblioteca
Solo para proyectos de biblioteca, se quitaron las propiedades BuildConfig.VERSION_NAME
y BuildConfig.VERSION_CODE
de la clase BuildConfig
generada, ya que esos valores estáticos no reflejaban los valores finales del nombre y el código de la versión correspondientes a la aplicación, lo cual resultaba engañoso. Además, esos valores se descartaron durante la combinación de manifiestos.
En una versión futura del complemento de Android para Gradle, también se quitarán las propiedades versionName
y versionCode
del DSL de las bibliotecas.
En la actualidad, no hay manera de acceder automáticamente al nombre y código de la versión de la app desde un subproyecto de biblioteca.
No hay cambios en los módulos de la aplicación. Puedes seguir asignando valores a versionCode
y versionName
en el DSL, que se propagarán al manifiesto y a los campos BuildConfig
de la app.
Cómo establecer la ruta de acceso del NDK
Puedes configurar la ruta de acceso a la instalación del NDK local con la propiedad android.ndkPath
en el archivo build.gradle
de tu módulo.
Groovy
android { ndkPath "your-custom-ndk-path" }
Kotlin
android { ndkPath = "your-custom-ndk-path" }
Si usas esta propiedad junto con la propiedad android.ndkVersion
, la ruta deberá contener una versión del NDK que coincida con android.ndkVersion
.
Cambios en el comportamiento de las pruebas de unidades de la biblioteca
Cambiamos el comportamiento de las compilaciones y las ejecuciones de pruebas de las unidades de la biblioteca. Ahora las pruebas de unidades de una biblioteca se compilan y se ejecutan en clases de compilación o de tiempo de ejecución de la propia biblioteca, lo que hace que la prueba de unidades consuma la biblioteca de la misma manera que lo hacen los subproyectos externos. Esa configuración suele generar mejores pruebas.
En algunos casos, las pruebas de unidades de biblioteca que usan vinculaciones de datos pueden encontrar clases DataBindingComponent
o BR
faltantes. Esas pruebas deben transferirse a una prueba de instrumentación en el proyecto androidTest
, ya que la compilación y ejecución en esas clases en una prueba de unidades podría generar un resultado incorrecto.
El complemento de Gradle io.fabric ya no está disponible
El complemento de Gradle io.fabric dejó de estar disponible y no es compatible con la versión 4.1 del complemento de Android para Gradle. Si necesitas obtener más información sobre el SDK de Fabric obsoleto y la manera de migrar al SDK de Firebase Crashlytics, consulta Cómo actualizar al SDK de Firebase Crashlytics.
4.0.0 (abril de 2020)
Esta versión del complemento para Android requiere lo siguiente:
Gradle 6.1.1. (para obtener más información, consulta la sección sobre cómo actualizar Gradle)
Herramientas de compilación del SDK 29.0.2 o versiones posteriores.
Esta actualización menor es compatible con la nueva configuración predeterminada y las funciones para la visibilidad de los paquetes en Android 11.
En las versiones anteriores de Android, era posible ver una lista de todas las apps instaladas en un dispositivo. A partir de Android 11 (nivel de API 30), de forma predeterminada, las apps solo tienen acceso a una lista filtrada de paquetes instalados.
Para ver una lista más amplia de las apps en el sistema, ahora debes agregar un elemento <queries>
en el manifiesto de Android de la app o biblioteca.
El complemento de Android para Gradle 4.1 y versiones posteriores ya es compatible con la nueva declaración <queries>
. Sin embargo, las versiones anteriores no lo son. Si agregas el elemento <queries>
o si comienzas a depender de una biblioteca o un SDK que admite la orientación a Android 11, es posible que se produzcan errores de combinación de manifiestos durante la compilación de tu app.
Para solucionar este problema, lanzaremos un conjunto de parches para el AGP 3.3 y versiones posteriores. Si usas una versión anterior del AGP, actualízalo a una de las siguientes versiones:
Si usas la versión del AGP… |
… actualiza a: |
---|---|
4.0.* | 4.0.1 |
3.6.* | 3.6.4 |
3.5.* | 3.5.4 |
3.4.* | 3.4.3 |
3.3.* | 3.3.3 |
Para obtener más información sobre esta nueva función, consulta Visibilidad de los paquetes en Android 11.
Funciones nuevas
Esta versión del complemento de Android para Gradle incluye las siguientes funciones nuevas:
Compatibilidad con Build Analyzer de Android Studio
La ventana Build Analyzer te ayuda a comprender y diagnosticar problemas con el proceso de compilación, como optimizaciones inhabilitadas y tareas mal configuradas.
Esta función está disponible cuando usas Android Studio 4.0 y versiones posteriores con el complemento de Android para Gradle 4.0.0
y versiones posteriores. Puedes abrir la ventana Build Analyzer de Android Studio de la siguiente manera:
- Si aún no lo hiciste, selecciona la opción Build > Make Project de la barra de menú para compilar tu app.
- En la barra de menú, selecciona View > Tool Windows > Build.
- En la ventana Build, abre la ventana Build Analyzer de una de las siguientes maneras:
- Cuando Android Studio termine de compilar el proyecto, haz clic en la pestaña Build Analyzer.
- Cuando Android Studio termine de compilar el proyecto, haz clic en el vínculo que se encuentra en el lado derecho de la ventana Build Output.
En el lado izquierdo, la ventana Build Analyzer organiza los posibles problemas de compilación en un árbol. Puedes explorar cada problema y hacer clic en ellos para analizar los detalles en el panel de la derecha. Cuando Android Studio analiza tu compilación, procesa el conjunto de tareas que determinaron la duración de la compilación y proporciona una visualización para ayudarte a comprender el impacto de cada una de esas tareas. Para obtener más detalles sobre las advertencias, expande el nodo Warnings.
Si quieres obtener más información, consulta cómo identificar regresiones de velocidad de compilación.
Expansión de sintaxis de la biblioteca de Java 8 en D8 y R8
El complemento de Android para Gradle ahora admite la utilización de varias API de lenguaje Java 8 sin necesidad de un nivel de API mínimo para tu app.
Mediante un proceso llamado expansión de sintaxis, el compilador DEX, D8, de Android Studio 3.0 y versiones posteriores ya proporcionaba compatibilidad sustancial con funciones del lenguaje Java 8 (como expresiones lambda, métodos de interfaz predeterminados, la prueba con recursos, etc.). En Android Studio 4.0, se amplió el motor correspondiente para poder expandir la sintaxis de las API del lenguaje Java. Eso significa que ahora puedes incluir API de lenguaje estándar que solo estaban disponibles en las versiones recientes de Android (como java.util.streams
) en apps que admiten versiones anteriores de Android.
El siguiente conjunto de API es compatible con esta versión:
- Flujos secuenciales (
java.util.stream
) - Un subconjunto de
java.time
java.util.function
- Adiciones recientes a
java.util.{Map,Collection,Comparator}
- Opcionales (
java.util.Optional
,java.util.OptionalInt
yjava.util.OptionalDouble
) y algunas otras clases nuevas que son útiles para las API anteriores - Algunas adiciones a
java.util.concurrent.atomic
(métodos nuevos enAtomicInteger
,AtomicLong
yAtomicReference
) ConcurrentHashMap
(con correcciones de errores para Android 5.0)
Para admitir esas API de lenguaje, D8 compila un archivo DEX de biblioteca independiente que contiene una implementación de las API faltantes y lo incluye en tu app. El proceso de expansión de sintaxis reescribe el código de tu app para que se pueda usar esa biblioteca durante el tiempo de ejecución.
Para agregar compatibilidad con esas API de lenguaje, incluye lo siguiente en el archivo build.gradle
del módulo de la app:
Groovy
android { defaultConfig { // Required when setting minSdkVersion to 20 or lower multiDexEnabled true } compileOptions { // Flag to enable support for the new language APIs coreLibraryDesugaringEnabled true // Sets Java compatibility to Java 8 sourceCompatibility JavaVersion.VERSION_1_8 targetCompatibility JavaVersion.VERSION_1_8 } } dependencies { coreLibraryDesugaring 'com.android.tools:desugar_jdk_libs:1.0.4' }
Kotlin
android { defaultConfig { // Required when setting minSdkVersion to 20 or lower multiDexEnabled = true } compileOptions { // Flag to enable support for the new language APIs isCoreLibraryDesugaringEnabled = true // Sets Java compatibility to Java 8 sourceCompatibility = JavaVersion.VERSION_1_8 targetCompatibility = JavaVersion.VERSION_1_8 } } dependencies { coreLibraryDesugaring("com.android.tools:desugar_jdk_libs:1.0.4") }
Ten en cuenta que también es posible que debas incluir el fragmento de código anterior en un archivo build.gradle
del módulo de biblioteca en los siguientes casos:
Las pruebas de instrumentación del módulo de biblioteca usan estas API de lenguaje (ya sea directamente o a través del módulo de biblioteca o sus dependencias). Por lo tanto, las API faltantes se proporcionan para el APK de la prueba de instrumentación.
Deseas ejecutar lint en el módulo de biblioteca de forma aislada. Esto permite que lint reconozca los usos válidos de las API de lenguaje y evite denunciar advertencias falsas.
Opciones nuevas para habilitar o inhabilitar las funciones de compilación
El complemento de Android para Gradle 4.0.0 presenta una nueva manera de controlar las funciones de compilación que deseas habilitar o inhabilitar, como la Vinculación de vista y la Vinculación de datos. De forma predeterminada, se inhabilitarán las funciones nuevas que se agreguen. Luego, podrás usar el bloque buildFeatures
para habilitar solamente las funciones que desees, lo que ayudará a optimizar el rendimiento de la compilación del proyecto. Puedes configurar las opciones de cada módulo en el archivo build.gradle
de nivel de módulo de la siguiente manera:
Groovy
android { // The default value for each feature is shown below. You can change the value to // override the default behavior. buildFeatures { // Determines whether to generate a BuildConfig class. buildConfig = true // Determines whether to support View Binding. // Note that the viewBinding.enabled property is now deprecated. viewBinding = false // Determines whether to support Data Binding. // Note that the dataBinding.enabled property is now deprecated. dataBinding = false // Determines whether to generate binder classes for your AIDL files. aidl = true // Determines whether to support RenderScript. renderScript = true // Determines whether to support injecting custom variables into the module’s R class. resValues = true // Determines whether to support shader AOT compilation. shaders = true } }
Kotlin
android { // The default value for each feature is shown below. You can change the value to // override the default behavior. buildFeatures { // Determines whether to generate a BuildConfig class. buildConfig = true // Determines whether to support View Binding. // Note that the viewBinding.enabled property is now deprecated. viewBinding = false // Determines whether to support Data Binding. // Note that the dataBinding.enabled property is now deprecated. dataBinding = false // Determines whether to generate binder classes for your AIDL files. aidl = true // Determines whether to support RenderScript. renderScript = true // Determines whether to support injecting custom variables into the module’s R class. resValues = true // Determines whether to support shader AOT compilation. shaders = true } }
También puedes especificar la configuración predeterminada para esas funciones en todos los módulos de un proyecto incluyendo uno o más de los siguientes elementos en el archivo gradle.properties
de tu proyecto, como se muestra más abajo. Ten en cuenta que puedes usar el bloque buildFeatures
del archivo build.gradle
a nivel de módulo para anular la configuración predeterminada de todo el proyecto.
android.defaults.buildfeatures.buildconfig=true
android.defaults.buildfeatures.aidl=true
android.defaults.buildfeatures.renderscript=true
android.defaults.buildfeatures.resvalues=true
android.defaults.buildfeatures.shaders=true
Dependencias entre funciones
En versiones anteriores del complemento de Android para Gradle, todos los módulos de funciones podían depender únicamente del módulo base de la app. Pero si usas la versión 4.0.0 del complemento, puedes incluir un módulo de funciones que depende de otro. Es decir, una función :video
puede depender de la función :camera
, que depende del módulo base, como se muestra en la siguiente figura.
El módulo de funciones :video
depende de la función :camera
, que depende del módulo base :app
.
Eso significa que, cuando la app solicita descargar un módulo de funciones, también descarga otros módulos de los que depende. Después de crear módulos de funciones para tu app, puedes declarar una dependencia entre funciones del archivo build.gradle
del módulo. Por ejemplo, el módulo :video
declara que depende de :camera
de la siguiente manera:
Groovy
// In the build.gradle file of the ':video' module. dependencies { // All feature modules must declare a dependency // on the base module. implementation project(':app') // Declares that this module also depends on the 'camera' // feature module. implementation project(':camera') ... }
Kotlin
// In the build.gradle file of the ':video' module. dependencies { // All feature modules must declare a dependency // on the base module. implementation(project(":app")) // Declares that this module also depends on the 'camera' // feature module. implementation(project(":camera")) ... }
Además, debes habilitar la función de dependencia entre funciones en Android Studio (para admitir la función a la hora de editar la configuración de ejecución). Para ello, haz clic en Help > Edit Custom VM Options en la barra de menú y agrega lo siguiente:
-Drundebug.feature.on.feature=true
Metadatos de dependencias
Cuando compilas tu app con el complemento de Android para Gradle 4.0.0 y versiones posteriores, el complemento incluye metadatos que describen las dependencias que se compilan en la app. Cuando subes tu app, Play Console inspecciona esos metadatos para brindarte los siguientes beneficios:
- Recibir alertas de problemas conocidos con SDK y dependencias
- Recibir comentarios prácticos para resolver esos problemas
Los datos se comprimen, se encriptan con una clave de firma de Google Play y se almacenan en el bloque de firma de tu app de lanzamiento. Sin embargo, puedes inspeccionar los metadatos por tu cuenta desde los archivos de compilación intermedios locales que se encuentran en el directorio <project>/<module>/build/outputs/sdk-dependencies/release/sdkDependency.txt
.
Si prefieres no compartir esa información, puedes incluir lo siguiente en el archivo build.gradle
de tu módulo:
Groovy
android { dependenciesInfo { // Disables dependency metadata when building APKs. includeInApk = false // Disables dependency metadata when building Android App Bundles. includeInBundle = false } }
Kotlin
android { dependenciesInfo { // Disables dependency metadata when building APKs. includeInApk = false // Disables dependency metadata when building Android App Bundles. includeInBundle = false } }
Cómo importar bibliotecas nativas desde dependencias de AAR
Ahora puedes importar bibliotecas C/C++ desde las dependencias AAR de tu app. Si sigues los pasos de configuración que se describen a continuación, Gradle hará que esas bibliotecas nativas estén disponibles automáticamente para que se puedan usar con tu sistema de compilación nativo externo, como CMake. Ten en cuenta que Gradle solo pone esas bibliotecas a disposición de tu compilación. Para usarlas, deberás configurar tus secuencias de comandos de compilación.
Las bibliotecas se exportan con el formato de paquete Prefab.
Cada dependencia puede exponer como máximo un paquete Prefab, que comprenda uno o más módulos. Un módulo Prefab es una biblioteca única, que puede ser compartida, estática o solo de encabezado.
Por lo general, el nombre del paquete coincide con el del artefacto de Maven, y el nombre del módulo con el de la biblioteca, aunque no siempre es así. Debido a que necesitas conocer los nombres del paquete y del módulo de las bibliotecas, es posible que debas consultar la documentación de la dependencia para determinar cuáles son esos nombres.
Cómo configurar un sistema de compilación nativo externo
Para ver los pasos que debes seguir, haz clic en el sistema de compilación nativo externo que tienes pensado usar.
Las dependencias nativas incluidas en un AAR se exponen a tu proyecto CMake mediante la variable CMAKE_FIND_ROOT_PATH. Gradle establecerá automáticamente ese valor cuando se invoque CMake, por lo que, si tu sistema de compilación modifica la variable, asegúrate de adjuntarla en lugar de asignarla.
Cada dependencia expone un paquete de archivo de configuración a tu compilación de CMake, que importas con el comando find_package
. Ese comando busca paquetes de archivos de configuración que coincidan con el nombre y la versión del paquete específico, y expone los destinos que define para su uso en tu compilación. Por ejemplo, si tu aplicación define libapp.so
y usa curl, debes incluir lo siguiente en tu archivo CMakeLists.txt
:
add_library(app SHARED app.cpp)
# Add these two lines.
find_package(curl REQUIRED CONFIG)
target_link_libraries(app curl::curl)
Ahora puedes especificar #include "curl/curl.h"
en app.cpp
. Cuando compilas un proyecto, tu sistema de compilación nativo externo vincula automáticamente libapp.so
con libcurl.so
y los paquetes libcurl.so
del APK o paquete de aplicación. Para obtener más información, consulta el ejemplo de prefab de curl.
Cambios en el comportamiento
Si usas esta versión del complemento, es posible que ocurran los siguientes cambios de comportamiento.
Actualizaciones de configuración de firmas v1/v2
Se modificó el comportamiento de las configuraciones de firma de apps en el bloque signingConfig
de la siguiente manera:
Firma v1
- Si
v1SigningEnabled
está habilitado explícitamente, AGP realiza la firma de apps v1. - Si el usuario inhabilita explícitamente
v1SigningEnabled
, no se realiza la firma de apps v1. - Si el usuario no habilitó explícitamente la firma v1, se puede inhabilitar de manera automática en función de
minSdk
ytargetSdk
.
Firma v2
- Si
v2SigningEnabled
está habilitado explícitamente, AGP realiza la firma de apps v2. - Si el usuario inhabilita explícitamente
v2SigningEnabled
, no se realiza la firma de apps v2. - Si el usuario no habilitó explícitamente la firma v2, se puede inhabilitar de manera automática en función de
targetSdk
.
Estos cambios permiten que AGP optimice las compilaciones mediante la inhabilitación del mecanismo de firma en función de si el usuario habilitó explícitamente estas marcas. Antes de esta versión, era posible que v1Signing
se inhabilitara incluso cuando se habilitaba de manera explícita, lo que podría ser confuso.
Se quitaron los complementos de Android para Gradle feature
y instantapp
En el complemento de Android para Gradle 3.6.0, el complemento de Feature (com.android.feature
) y el complemento de Instant App (com.android.instantapp
) dejaron de estar disponibles, y fueron reemplazados por el complemento de Dynamic Feature (com.android.dynamic-feature
) para compilar y empaquetar apps instantáneas mediante Android App Bundles.
En el complemento de Android para Gradle 4.0.0 y versiones posteriores, se quitaron por completo esos complementos obsoletos. Por lo tanto, a fin de usar el complemento de Android para Gradle más reciente, debes migrar tu app instantánea de modo que sea compatible con Android App Bundles. Si migras tus apps instantáneas, puedes aprovechar los beneficios de los paquetes de aplicaciones y simplificar el diseño modular de tu app.
Se quitó la función de procesamiento de anotaciones independiente
Se quitó la posibilidad de separar el procesamiento de anotaciones en una tarea exclusiva. Esa opción se usa para mantener la compilación incremental de Java cuando se utilizan procesadores de anotaciones no incrementales en proyectos solo de Java. Se habilitó mediante la configuración de android.enableSeparateAnnotationProcessing
en true
en el archivo gradle.properties
, que ya no funciona.
En su lugar, debes migrar al uso de procesadores de anotaciones incrementales para mejorar el rendimiento de la compilación.
Se dio de baja includeCompileClasspath
El complemento de Android para Gradle ya no comprueba ni incluye procesadores de anotaciones que declares en la ruta de clase de la compilación, y la propiedad DSL annotationProcessorOptions.includeCompileClasspath
ya no tiene ningún efecto. Si incluyes procesadores de anotaciones en la ruta de clase de la compilación, es posible que obtengas el siguiente error:
Error: Annotation processors must be explicitly declared now.
Para resolver ese problema, debes incluir procesadores de anotaciones en tus archivos build.gradle
mediante la configuración de dependencia annotationProcessor
.
Para obtener más información, consulta Cómo agregar procesadores de anotaciones.
Empaquetado automático de dependencias compiladas previamente que usa CMake
Las versiones anteriores del complemento de Android para Gradle requerían que empaquetaras de forma explícita las bibliotecas compiladas previamente que usaba tu compilación nativa externa de CMake con jniLibs
. Es posible que tengas bibliotecas en el directorio src/main/jniLibs
de tu módulo o, quizás, en otro directorio configurado de tu archivo build.gradle
:
Groovy
sourceSets { main { // The libs directory contains prebuilt libraries that are used by the // app's library defined in CMakeLists.txt via an IMPORTED target. jniLibs.srcDirs = ['libs'] } }
Kotlin
sourceSets { main { // The libs directory contains prebuilt libraries that are used by the // app's library defined in CMakeLists.txt via an IMPORTED target. jniLibs.setSrcDirs(listOf("libs")) } }
Con el complemento de Android para Gradle 4.0, la configuración anterior ya no es necesaria y generará una falla de compilación:
* What went wrong:
Execution failed for task ':app:mergeDebugNativeLibs'.
> A failure occurred while executing com.android.build.gradle.internal.tasks.Workers$ActionFacade
> More than one file was found with OS independent path 'lib/x86/libprebuilt.so'
La compilación nativa externa ahora empaqueta automáticamente esas bibliotecas, de modo que hacerlo de forma explícita con jniLibs
genera una duplicación. Para evitar el error de compilación, mueve la biblioteca compilada con anterioridad a una ubicación fuera de jniLibs
o quita la configuración jniLibs
del archivo build.gradle
.
Errores conocidos
En esta sección, se describen los problemas conocidos presentes en el complemento de Android para Gradle 4.0.0.
Condición de carrera en el mecanismo de trabajador de Gradle
Los cambios en el complemento de Android para Gradle 4.0 pueden activar una condición de carrera en Gradle cuando se ejecuta con --no-daemon
y las versiones de Gradle 6.3 o anteriores, lo que hace que las compilaciones se bloqueen después de que termine el proceso de compilación.
Ese error se corregirá en Gradle 6.4.
3.6.0 (febrero de 2020)
Esta versión del complemento para Android requiere lo siguiente:
Gradle 5.6.4 (para obtener más información, consulta la sección sobre cómo actualizar Gradle)
Herramientas de compilación del SDK 28.0.3 o versiones posteriores
Esta actualización menor es compatible con la nueva configuración predeterminada y las funciones para la visibilidad de los paquetes en Android 11.
Consulta las notas de la versión 4.0.1 para obtener más detalles.
Funciones nuevas
Esta versión del complemento de Android para Gradle incluye las siguientes funciones nuevas:
Vinculación de vistas
La vinculación de vistas proporciona seguridad en el tiempo de compilación cuando se hace referencia a vistas en el código.
Ahora puedes reemplazar findViewById()
con la referencia de clase de vinculación generada automáticamente. A fin de comenzar a usar la vinculación de vista, incluye lo siguiente en el archivo build.gradle
de cada módulo:
Groovy
android { viewBinding.enabled = true }
Kotlin
android { viewBinding.enabled = true }
Para obtener más información, consulta la documentación sobre la vinculación de vista.
Compatibilidad con el complemento de Maven Publish
El complemento de Android para Gradle incluye compatibilidad con el complemento de Maven Publish para Gradle, que te permite publicar artefactos de compilación en un repositorio de Maven de Apache. El complemento de Android para Gradle crea un componente para cada artefacto de variante de compilación en tu app o módulo de biblioteca que puedes usar para personalizar una publicación en un repositorio de Maven.
Si quieres obtener más información, consulta la página que indica cómo usar el complemento de Maven Publish.
Nueva herramienta de empaquetado predeterminada
Cuando compilas la versión de depuración de tu app, el complemento usa una herramienta de empaquetado nueva, llamada zipflinger, a fin de compilar tu APK. Esa nueva herramienta debería proporcionar mejoras en la velocidad de compilación. Si no funciona como esperabas, informa un error. Para volver a usar la herramienta de empaquetado anterior, incluye lo siguiente en tu archivo gradle.properties
:
android.useNewApkCreator=false
Atribución de compilación nativa
Ahora puedes determinar el tiempo que tarda Clang en compilar y vincular cada archivo C/C++ de tu proyecto. Gradle puede generar un registro de Chrome que contenga marcas de tiempo para esos eventos del compilador a fin ayudarte a entender mejor el tiempo que lleva compilar tu proyecto. Para generar ese archivo de atribución de compilación, haz lo siguiente:
Agrega la marca
-Pandroid.enableProfileJson=true
cuando ejecutes una compilación de Gradle. Por ejemplo:gradlew assembleDebug -Pandroid.enableProfileJson=true
Abre el navegador Chrome y escribe
chrome://tracing
en la barra de búsqueda.Haz clic en el botón Load y navega hasta
project-root/build/android-profile
para encontrar el archivo. El nombre del archivo esprofile-timestamp.json.gz
.
Puedes ver los datos de la atribución de compilación nativa cerca de la parte superior del visor:
Cambios en el comportamiento
Si usas esta versión del complemento, es posible que ocurran los siguientes cambios de comportamiento.
Bibliotecas nativas empaquetadas sin comprimir de forma predeterminada
Cuando compilas la app, el complemento ahora establece extractNativeLibs
en "false"
de forma predeterminada. Es decir, tus bibliotecas nativas están alineadas con la página y empaquetadas sin comprimir. Si bien esto genera un tamaño de carga más grande, los usuarios se benefician de lo siguiente:
- Un tamaño de instalación de app más pequeño, ya que la plataforma puede acceder a las bibliotecas nativas directamente desde el APK instalado, sin crear una copia de las bibliotecas
- Un tamaño de descarga menor, ya que la compresión de Play Store suele ser mejor cuando incluyes bibliotecas nativas sin comprimir en tu APK o Android App Bundle
Si quieres que el complemento de Android para Gradle empaquete bibliotecas nativas comprimidas, incluye lo siguiente en el manifiesto de tu app:
<application
android:extractNativeLibs="true"
... >
</application>
Versión predeterminada del NDK
Si descargas varias versiones del NDK, el complemento de Android para Gradle ahora selecciona una versión predeterminada que usará en la compilación de tus archivos de código fuente. Anteriormente, el complemento seleccionaba la última versión descargada del NDK. Usa la propiedad android.ndkVersion
en el archivo build.gradle
del módulo para anular el valor predeterminado que seleccionó el complemento.
Generación simplificada de la clase R
El complemento de Android para Gradle simplifica la ruta de clase de compilación, ya que genera solo una clase R para cada módulo de biblioteca en tu proyecto y comparte esas clases R con otras dependencias del módulo. Esa optimización debería generar compilaciones más rápidas, pero es necesario que tengas en cuenta lo siguiente:
- Como el compilador comparte clases R con dependencias de módulos ascendentes, es importante que cada módulo de tu proyecto utilice un nombre de paquete único.
- La configuración que se utilice para incluir la biblioteca como una dependencia determinará en qué medida las otras dependencias del proyecto podrán ver su clase R.
Por ejemplo, si la Biblioteca A incluye a la Biblioteca B como una dependencia "api", la Biblioteca A y otras que dependan de la Biblioteca A tendrán acceso a la clase R de la Biblioteca B. Sin embargo, es posible que otras bibliotecas no tengan acceso a la clase R de la Biblioteca B si la Biblioteca A usa la configuración de dependencia
implementation
. Para obtener más información, consulta las opciones de configuración de dependencias.
Cómo quitar los recursos que faltan de la configuración predeterminada
En el caso de los módulos de biblioteca, si incluyes un recurso para un idioma que no agregaste al conjunto predeterminado de recursos (por ejemplo, si incluyes hello_world
como un recurso de strings en /values-es/strings.xml
, pero no lo defines en /values/strings.xml
), el complemento de Android para Gradle dejará de incluir ese recurso cuando compile tu proyecto. Este cambio en el comportamiento debería dar como resultado menos excepciones en tiempo de ejecución Resource Not Found
y una mejor velocidad de compilación.
D8 ahora respeta la política de retención de CLASS para las anotaciones
Cuando compilas tu app, D8 ahora respeta cuando las anotaciones aplican una política de retención de CLASS, y esas anotaciones ya no están disponibles durante el tiempo de ejecución. Este comportamiento también ocurre cuando se configura el SDK de destino de la app en el nivel de API 23, que antes permitía el acceso a esas anotaciones durante el tiempo de ejecución al momento de compilar tu app con versiones más antiguas del complemento de Android para Gradle y D8.
Otros cambios en el comportamiento
aaptOptions.noCompress
ya no distingue entre mayúsculas y minúsculas en todas las plataformas (tanto para APK como para paquetes), y respeta las rutas de acceso que utilizan caracteres en mayúsculas.- La vinculación de datos ahora es incremental de forma predeterminada. Para obtener más información, consulta el problema n.° 110061530.
- Todas las pruebas de unidades, incluidas las de Robolectric, ahora se pueden almacenar por completo en caché. Para obtener más información, consulta el problema n.° 115873047.
Correcciones de errores
Esta versión del complemento de Android para Gradle incluye las siguientes correcciones de errores:
- Las pruebas de unidades de Robolectric ahora son compatibles con los módulos de bibliotecas que usan la vinculación de datos. Para obtener más información, consulta el problema n.° 126775542.
- Ahora puedes ejecutar tareas de
connectedAndroidTest
en varios módulos mientras el modo de ejecución paralela de Gradle está habilitado.
Errores conocidos
En esta sección, se describen los problemas conocidos presentes en el complemento de Android para Gradle 3.6.0.
Rendimiento lento de la tarea de Android Lint
Android Lint puede tardar mucho más en completarse en algunos proyectos debido a una regresión en su infraestructura de análisis, lo que genera un cálculo más lento de tipos inferidos para lambdas en ciertas construcciones de código.
El problema se informa como un error en IDEA y se corregirá en el complemento de Android para Gradle 4.0.
Falta la clase del manifiesto
Si tu app define permisos personalizados en su manifiesto, el complemento de Android para Gradle suele generar una clase Manifest.java
que incluye tus permisos personalizados como constantes de string. El complemento empaqueta esa clase con tu app para que puedas hacer referencia más fácilmente a esos permisos durante el tiempo de ejecución.
La generación de la clase del manifiesto no funciona en el complemento de Android para Gradle 3.6.0. Si creas tu app con esa versión del complemento y hace referencia a la clase de manifiesto, es posible que veas una excepción ClassNotFoundException
. Para solucionar ese problema, realiza una de las siguientes acciones:
- Haz referencia a tus permisos personalizados por su nombre completamente calificado. Por ejemplo,
"com.example.myapp.permission.DEADLY_ACTIVITY"
. Define tus propias constantes, como se muestra a continuación:
public final class CustomPermissions { public static final class permission { public static final String DEADLY_ACTIVITY="com.example.myapp.permission.DEADLY_ACTIVITY"; } }
3.5.0 (agosto de 2019)
El complemento de Android para Gradle 3.5.0, junto con Android Studio 3.5, es una actualización importante y el resultado de Project Marble, que se enfoca en mejorar tres áreas principales de las herramientas para desarrolladores de Android: estado del sistema, perfeccionamiento de funciones y corrección de errores. Cabe destacar que mejorar la velocidad de compilación del proyecto fue uno de los enfoques principales de esa actualización.
Si deseas obtener más información sobre esas y otras actualizaciones de Project Marble, consulta la entrada del Blog para desarrolladores de Android o las secciones que se incluyen más abajo.
Esta versión del complemento para Android requiere lo siguiente:
Gradle 5.4.1 (para obtener más información, consulta la sección sobre cómo actualizar Gradle)
Herramientas de compilación del SDK 28.0.3 o versiones posteriores
Esta actualización menor es compatible con la nueva configuración predeterminada y las funciones para la visibilidad de los paquetes en Android 11.
Consulta las notas de la versión 4.0.1 para obtener más detalles.
3.5.3 (diciembre de 2019)
Esta actualización menor es compatible con Android Studio 3.5.3 e incluye varias correcciones de errores y mejoras de rendimiento.
3.5.2 (noviembre de 2019)
Esta actualización menor es compatible con Android Studio 3.5.2 e incluye varias correcciones de errores y mejoras de rendimiento. Para ver una lista de las correcciones de errores más importantes, consulta la entrada relacionada en el blog de actualizaciones de versiones.
3.5.1 (octubre de 2019)
Esta actualización menor es compatible con Android Studio 3.5.1 e incluye varias correcciones de errores y mejoras de rendimiento. Para ver una lista de las correcciones de errores más importantes, consulta la entrada relacionada en el blog de actualizaciones de versiones.
Procesamiento de anotación incremental
El procesador de anotaciones de vinculación de datos admite el procesamiento de anotación incremental si configuras android.databinding.incremental=true
en tu archivo gradle.properties
. Esta optimización mejora el rendimiento de la compilación incremental. Si deseas obtener la lista completa de procesadores de anotaciones optimizados, consulta la tabla de procesadores de anotaciones incrementales.
Además, KAPT 1.3.30 y las versiones posteriores también admiten los procesadores de anotaciones incrementales, que puedes habilitar si incluyes kapt.incremental.apt=true
en tu archivo gradle.properties
.
Pruebas de unidades que se pueden almacenar en caché
Cuando configuras includeAndroidResources
en true
a fin de permitir que las pruebas de unidades usen recursos, elementos y manifiestos de Android, el complemento de Android para Gradle genera un archivo de configuración de prueba con rutas de acceso absolutas, que destruyen la capacidad de reubicación de la caché. Puedes indicarle al complemento que, en su lugar, genere la configuración de prueba mediante rutas de acceso relativas, que permiten que la tarea AndroidUnitTest
se pueda almacenar en caché por completo, si incluyes lo siguiente en tu archivo gradle.properties
:
android.testConfig.useRelativePath = true
Errores conocidos
Si usas el complemento Kotlin-Gradle 1.3.31 o versiones anteriores, es posible que veas la siguiente advertencia mientras compilas o sincronizas tu proyecto:
WARNING: API 'variant.getPackageLibrary()' is obsolete and has been replaced with 'variant.getPackageLibraryProvider()'.
Para resolver este error, actualiza el complemento a la versión 1.3.40 o superior.
3.4.0 (abril de 2019)
Esta versión del complemento para Android requiere lo siguiente:
Gradle 5.1.1 o posterior. (para obtener más información, consulta la sección sobre cómo actualizar Gradle)
Herramientas de compilación del SDK 28.0.3 o versiones posteriores
Esta actualización menor es compatible con la nueva configuración predeterminada y las funciones para la visibilidad de los paquetes en Android 11.
Consulta las notas de la versión 4.0.1 para obtener más detalles.
3.4.2 (julio de 2019)
Esta actualización menor es compatible con Android Studio 3.4.2 e incluye varias correcciones de errores y mejoras de rendimiento. Para ver una lista de las correcciones de errores más importantes, consulta la entrada relacionada en el blog de actualizaciones de versiones.
3.4.1 (mayo de 2019)
Esta actualización menor es compatible con Android Studio 3.4.1 e incluye varias correcciones de errores y mejoras de rendimiento. Para ver una lista de las correcciones de errores más importantes, consulta la entrada relacionada en el blog de actualizaciones de versiones.
Funciones nuevas
Nuevas configuraciones de dependencia de comprobación de lint: cambió el comportamiento de
lintChecks
y se introdujo una configuración de dependencia nueva,lintPublish
, a fin de brindar mayor control sobre qué comprobaciones de lint se empaquetan en las bibliotecas de Android.lintChecks
: esta es una configuración existente que debes usar para las comprobaciones de lint que solo deseas ejecutar cuando compilas el proyecto de forma local. Si anteriormente usabas la configuración de dependencialintChecks
para incluir comprobaciones de lint en el archivo AAR publicado, debes migrar esas dependencias para usar la configuración delintPublish
nueva que se describe a continuación.lintPublish
: usa esta configuración nueva en proyectos de biblioteca para las comprobaciones de lint que desees incluir en el archivo AAR publicado, como se muestra a continuación. Eso significa que los proyectos que consumen la biblioteca también aplican esas comprobaciones de lint.
En la siguiente muestra de código, se usan ambas configuraciones de dependencia en un proyecto de biblioteca local de Android.
Groovy
dependencies { // Executes lint checks from the ':lint' project at build time. lintChecks project(':lint') // Packages lint checks from the ':lintpublish' in the published AAR. lintPublish project(':lintpublish') }
Kotlin
dependencies { // Executes lint checks from the ':lint' project at build time. lintChecks(project(":lint")) // Packages lint checks from the ':lintpublish' in the published AAR. lintPublish(project(":lintpublish")) }
En general, debería mejorar la velocidad de compilación para las tareas de empaquetado y firma. Si observas una regresión de rendimiento relacionada con esas tareas, informa el error.
Cambios en el comportamiento
Advertencia de baja del complemento de la función Apps instantáneas Android: Si todavía usas el complemento
com.android.feature
para compilar apps instantáneas, el complemento de Android para Gradle 3.4.0 te advertirá que aquel dejará de estar disponible. Para asegurarte de que podrás seguir compilando apps instantáneas en versiones futuras del complemento, migra tus apps con el complemento de funciones dinámicas, que también te permite publicar las experiencias de apps instantáneas e instaladas desde un único Android App Bundle.R8 habilitado en la configuración predeterminada: R8 integra en un solo paso los procesos de expansión de sintaxis, reducción, ofuscación, optimización y conversión a dex. Eso mejora notablemente el rendimiento de las compilaciones. R8 se presentó en el complemento de Android para Gradle 3.3.0 y ahora está habilitado de forma predeterminada para proyectos de bibliotecas de apps y Android que utilicen el complemento 3.4.0 y versiones posteriores.
En la siguiente imagen, se proporciona una descripción general del proceso de compilación antes de la incorporación de R8.
Con R8, ahora los procesos de expansión de sintaxis, reducción, ofuscación, optimización y conversión a dex (D8) se completan en un único paso, como se muestra a continuación.
Ten en cuenta que R8 está diseñado para trabajar con las reglas de ProGuard existentes, de modo que es probable que R8 funcione correctamente sin necesidad de que realices ninguna acción. Sin embargo, dado que se trata de una tecnología diferente a la de ProGuard, diseñada específicamente para proyectos de Android, es posible que durante la reducción y la optimización se quite código que ProGuard no quitaría. Por lo tanto, en esta situación poco probable, es posible que sea necesario agregar reglas adicionales para mantener ese código en la compilación de salida.
Si tienes inconvenientes con el uso de R8, consulta las Preguntas frecuentes sobre compatibilidad de R8 para comprobar si hay una solución a tu problema. Si no la hay, informa el error. Para inhabilitar R8, agrega una de las siguientes líneas al archivo
gradle.properties
de tu proyecto:# Disables R8 for Android Library modules only. android.enableR8.libraries = false # Disables R8 for all modules. android.enableR8 = false
ndkCompile
dejó de estar disponible: si intentas usarndkBuild
para compilar bibliotecas nativas, se mostrará un error de compilación. En su lugar, debes usar CMake o ndk-build para agregar código C y C++ a tu proyecto.
Errores conocidos
El uso correcto de nombres de paquetes únicos no se aplica actualmente, pero será más estricto en las versiones posteriores del complemento. En la versión 3.4.0 del complemento de Android para Gradle, puedes optar por comprobar si tu proyecto declara nombres de paquete aceptables. Para ello, agrega la siguiente línea al archivo
gradle.properties
.android.uniquePackageNames = true
Si necesitas obtener más información sobre cómo configurar un nombre de paquete mediante el complemento de Android para Gradle, consulta Cómo establecer el ID de aplicación.
3.3.0 (enero de 2019)
Esta versión del complemento para Android requiere lo siguiente:
Gradle 4.10.1 o una versión posterior. (para obtener más información, consulta la sección sobre cómo actualizar Gradle)
Herramientas de compilación del SDK 28.0.3 o versiones posteriores
Esta actualización menor es compatible con la nueva configuración predeterminada y las funciones para la visibilidad de los paquetes en Android 11.
Consulta las notas de la versión 4.0.1 para obtener más detalles.
3.3.2 (marzo de 2019)
Esta actualización menor es compatible con Android Studio 3.3.2 e incluye varias correcciones de errores y mejoras de rendimiento. Para ver una lista de las correcciones de errores más importantes, consulta la entrada relacionada en el blog de actualizaciones de versiones.
3.3.1 (febrero de 2019)
Esta actualización menor es compatible con Android Studio 3.3.1 e incluye varias correcciones de errores y mejoras de rendimiento.
Funciones nuevas
Sincronización de ruta de clase mejorada: cuando se resuelven dependencias en las rutas de clase de tiempo de compilación y ejecución, el complemento de Android para Gradle intenta corregir determinados conflictos de versiones descendentes para las dependencias que aparecen en varias rutas de clase.
Por ejemplo, si la ruta de clase de tiempo de ejecución incluye una Biblioteca A versión 2.0 y la de compilación incluye una Biblioteca A versión 1.0, el complemento actualizará la dependencia automáticamente en la ruta de clase de compilación a la versión 2.0 de la Biblioteca A para evitar errores.
Sin embargo, si la ruta de clase incluye una Biblioteca A versión 1.0 y la compilación incluye una Biblioteca A versión 2.0, el complemento no pasará la dependencia de la clase de ruta de compilación a la versión anterior (la Biblioteca A versión 1.0), y se mostrará un error. Para obtener más información, consulta Cómo solucionar conflictos entre rutas de clase.
Compilación incremental de Java mejorada cuando se usan procesadores de anotaciones: Esta actualización disminuye el tiempo de compilación, ya que mejora el soporte de compilación de Java incremental cuando se usan procesadores de anotaciones.
- Para proyectos que usan Kapt (la mayoría de los proyectos específicos de Kotlin e híbridos de Kotlin y Java): está habilitada la compilación de Java incremental, incluso cuando se usa la vinculación de datos o el complemento retro-lambda. El procesamiento de anotaciones de la tarea Kapt aún no es incremental.
Para proyectos que no usan Kapt (solo Java): Si todos los procesadores de anotaciones que usas admiten el procesamiento de anotaciones incrementales, la compilación incremental de Java estará habilitada de forma predeterminada. Para supervisar la adopción incremental del procesador de anotaciones, consulta el error 5277 de Gradle.
Sin embargo, si uno o más procesadores de anotaciones no admiten compilaciones incrementales, la compilación incremental de Java no estará habilitada. En su lugar, puedes incluir la siguiente marca en el archivo
gradle.properties
:android.enableSeparateAnnotationProcessing=true
Cuando incluyes esa marca, el complemento de Android para Gradle ejecuta los procesadores de anotaciones en una tarea separada y permite que se ejecuten de forma incremental las tareas de compilación de Java.
Información de depuración mejorada cuando se usa una API obsoleta: si el complemento detecta que se está usando una API que ya no se admite, ahora puede proporcionar información más detallada para ayudarte a determinar dónde se está usando la API. Para ver la información adicional, debes incluir lo siguiente en el archivo
gradle.properties
del proyecto:android.debug.obsoleteApi=true
También puedes habilitar la marca pasando
-Pandroid.debug.obsoleteApi=true
desde la línea de comandos.Puedes ejecutar pruebas de instrumentación en módulos de funciones desde la línea de comandos.
Cambios en el comportamiento
Configuración de tareas diferidas: El complemento ahora usa la API de creación de tareas nuevas de Gradle a fin de evitar la inicialización y configuración de tareas que no son necesarias para completar la compilación actual (o que no están en el gráfico de tareas de ejecución). Por ejemplo, si tienes muchas variantes de compilación, como "actualización" y "depuración", y estás compilando la versión de "depuración" de tu app, el complemento evita la inicialización y la configuración de tareas de la versión de "actualización".
Si se llama a determinados métodos anteriores en la API de variantes, como
variant.getJavaCompile()
, es posible que aún se fuerce la configuración de tareas. A fin de asegurarte de que esté optimizada la compilación para la configuración de tareas diferidas, invoca métodos nuevos que, en su lugar, muestren un objetoTaskProvider
, comovariant.getJavaCompileProvider()
.Si ejecutas tareas de compilación personalizadas, obtén información para adaptarte a la API de creación de tareas nuevas de Gradle.
Para un tipo de compilación determinado, cuando se configura
useProguard false
, el complemento usa R8 en lugar de ProGuard a fin de reducir y ofuscar el código y los recursos de la app. Si deseas obtener más información sobre R8, consulta esta entrada del blog para desarrolladores de Android.Generación de clase R más rápida para proyectos de biblioteca: Anteriormente, el complemento de Android para Gradle generaba un archivo
R.java
en cada una de las dependencias del proyecto y, luego, compilaba esas clases R junto con el resto de las clases de tu app. Ahora el complemento genera un JAR que contiene la clase R compilada de la app directamente, sin tener que compilar clasesR.java
intermedias primero. Esa optimización puede aumentar la velocidad de indexación en Android Studio y mejorar de manera considerable el rendimiento de la compilación para proyectos que incluyen muchos subproyectos y dependencias de biblioteca.Cuando se compila Android App Bundle, los APK generados desde ese paquete de aplicación orientados a Android 6.0 (nivel de API 23) o a una versión posterior, ahora incluyen de forma predeterminada versiones sin comprimir de las bibliotecas nativas. Esa optimización evita la necesidad de que el dispositivo cree una copia de la biblioteca y, por lo tanto, reduce el tamaño de la app en el disco. Si prefieres inhabilitar esta optimización, agrega lo siguiente al archivo
gradle.properties
:android.bundle.enableUncompressedNativeLibs = false
El complemento aplica las versiones mínimas de algunos complementos de terceros.
Sincronización de proyectos de una sola variante: Sincronizar el proyecto con tu configuración de compilación es un paso importante para permitir que Android Studio comprenda cómo se estructura el proyecto. Sin embargo, en el caso de proyectos grandes, el proceso puede consumir mucho tiempo. Si tu proyecto usa múltiples variantes de compilación, ahora puedes optimizar las sincronizaciones del proyecto limitándolas solo a la variante que hayas seleccionado.
Debes usar Android Studio 3.3 o una versión posterior con el complemento de Android para Gradle 3.3.0 o una versión posterior a fin de habilitar esta optimización. Cuando cumples con esos requisitos, el IDE te solicita que habilites la optimización al momento de sincronizar el proyecto. La optimización también está habilitada de forma predeterminada en proyectos nuevos.
Para habilitarla manualmente, haz clic en File > Settings > Experimental > Gradle (Android Studio > Preferences > Experimental > Gradle en Mac) y selecciona la casilla de verificación Only sync the active variant.
Nota: Esta optimización es completamente compatible con proyectos que incluyen Java y lenguajes C++, y ofrece compatibilidad limitada con Kotlin. Cuando se habilita la optimización para proyectos con contenido de Kotlin, la sincronización de Gradle vuelve a usar variantes completas de forma interna.
Descarga automática de paquetes de SDK faltantes: Se expandió esta funcionalidad para brindar compatibilidad con el NDK. Si quieres obtener más información, consulta Cómo descargar automáticamente los paquetes que faltan con Gradle.
Correcciones de errores
El complemento de Android para Gradle 3.3.0 corrige los siguientes errores:
- El proceso de compilación llama a
android.support.v8.renderscript.RenderScript
en lugar de la versión de AndroidX, a pesar de que esté habilitado Jetifier - Conflictos que se producen cuando
androidx-rs.jar
incluyeannotation.AnyRes
con paquetes estáticos - Cuando se usa RenderScript, ya no es necesario configurar manualmente la versión de las herramientas de compilación en archivos
build.gradle
- El proceso de compilación llama a
3.2.0 (septiembre de 2018)
Esta versión del complemento para Android requiere lo siguiente:
- Gradle 4.6 o una versión posterior (para obtener más información, consulta la sección sobre cómo actualizar Gradle)
- Herramientas de compilación del SDK 28.0.3 o versiones posteriores
3.2.1 (octubre de 2018)
Con esta actualización, ya no es necesario especificar la versión de las herramientas de compilación de SDK. El complemento de Android para Gradle ahora usa la versión 28.0.3 de forma predeterminada.
Funciones nuevas
Compatibilidad con compilación de Android App Bundles: El paquete de aplicación es un formato de carga nuevo que incluye todos los recursos y códigos compilados de la app, a la vez que se aplaza la generación de APK y el proceso de firma en Google Play Store. Ya no es necesario compilar, firmar y administrar varios APK, y los usuarios obtienen descargas de menor tamaño optimizadas para su dispositivo. Si quieres obtener más información, consulta Android App Bundles.
Compatibilidad con velocidades de compilación incremental mejoradas cuando se usan los procesadores de anotaciones: El DSL de
AnnotationProcessorOptions
ahora amplíaCommandLineArgumentProvider
, que te permite a ti o al autor del procesador de anotaciones tomar anotaciones de los argumentos del procesador mediante anotaciones de tipo de propiedad de compilación incremental. El uso de esas anotaciones mejora la corrección y el rendimiento de las compilaciones limpias incrementales y almacenadas en caché. Para obtener más información, consulta Cómo pasar argumentos a procesadores de anotaciones.Herramienta de migración para AndroidX: cuando se usa el complemento de Android para Gradle 3.2.0 con Android 3.2 y versiones posteriores, puedes migrar las dependencias de Maven y las locales del proyecto a fin de usar las nuevas bibliotecas de AndroidX. Para ello, selecciona Refactor > Migrate to AndroidX en la barra de menú. El uso de esta herramienta de migración también configura las siguientes marcas como
true
en el archivogradle.properties
:android.useAndroidX
: cuando se establece esta marca entrue
, el complemento para Android usa la biblioteca de AndroidX apropiada en lugar de una biblioteca de compatibilidad. Si no se especifica la marca, el complemento la configura comofalse
de forma predeterminada.android.enableJetifier
: cuando se establece esta marca entrue
, el complemento para Android reescribe sus objetos binarios a fin de migrar automáticamente las bibliotecas de terceros existentes para usar las dependencias de AndroidX. Si no se especifica la marca, el complemento la configura enfalse
de forma predeterminada. Puedes configurarla entrue
solo siandroid.useAndroidX
también está configurado entrue
; de lo contrario, se mostrará un error de compilación.
Para obtener más información, consulta la descripción general de AndroidX.
Reductor de código nuevo, R8: R8 es una herramienta nueva para reducir y ofuscar código que reemplaza a ProGuard. Puedes comenzar a usar la versión de vista previa de R8 incluyendo lo siguiente en el archivo
gradle.properties
del proyecto:Groovy
android.enableR8 = true
Kotlin
android.enableR8 = true
Cambios en el comportamiento
- La eliminación de accesos directos con D8 ahora está habilitada de forma predeterminada.
AAPT2 ahora está en el repositorio Maven de Google. Para usar AAPT2, asegúrate de tener la dependencia
google()
en el archivobuild.gradle
, como se muestra a continuación:Groovy
buildscript { repositories { google() // here jcenter() } dependencies { classpath 'com.android.tools.build:gradle:3.2.0' } } allprojects { repositories { google() // and here jcenter() }
Kotlin
buildscript { repositories { google() // here jcenter() } dependencies { classpath 'com.android.tools.build:gradle:3.2.0' } } allprojects { repositories { google() // and here jcenter() }
El multidex nativo ahora está habilitado de forma predeterminada. Las versiones anteriores de Android Studio habilitaban multidex nativo cuando se implementaba la versión de depuración de una app en un dispositivo con el nivel de API 21 o posterior de Android. Independientemente de si haces una implementación en un dispositivo o compilas un APK para actualización, el complemento de Android para Gradle habilita multidex nativo en todos los módulos con
minSdkVersion=21
o una versión posterior.El complemento ahora aplica una versión mínima del complemento protobuf (0.8.6), Kotlin (1.2.50) y Crashlytics (1.25.4).
El complemento de módulo de función,
com.android.feature
, ahora aplica el uso de solo letras, dígitos y guiones bajos cuando se especifica un nombre de módulo. Por ejemplo, si el nombre del módulo incluye guiones, se mostrará un error. Este comportamiento coincide con el del complemento de funciones dinámicas.
Correcciones de errores
- Ahora se puede almacenar JavaCompile en la memoria caché en proyectos con vinculación de datos (Problema #69243050)
- Elusión de compilación mejorada para módulos de biblioteca con vinculación de datos (Error #77539932)
- Ahora puedes volver a habilitar la configuración a pedido si la inhabilitaste en versiones anteriores debido a errores de compilación impredecibles (Error #77910727)
3.1.0 (marzo de 2018)
Esta versión del complemento para Android requiere lo siguiente:
- Gradle 4.4 o una versión posterior (para obtener más información, consulta la sección sobre cómo actualizar Gradle)
- Herramientas de compilación 27.0.3 o versiones posteriores
(ten en cuenta que ya no es necesario especificar una versión para las herramientas de compilación mediante la propiedad
android.buildToolsVersion
, ya que el complemento usa la versión mínima requerida de forma predeterminada)
Compilador de DEX nuevo, D8
De forma predeterminada, Android Studio ahora usa un compilador de DEX nuevo denominado D8. La compilación de DEX es el proceso de transformar el código de bytes .class
en .dex
para el tiempo de ejecución de Android (o Dalvik, para las versiones anteriores de Android). En comparación con el compilador anterior, denominado DX, D8 compila más rápido y genera archivos DEX más pequeños. Además, mantiene el mismo rendimiento de tiempo de ejecución de la app o lo mejora.
D8 no debería modificar el flujo de trabajo diario de desarrollo de apps. Sin embargo, si tienes problemas relacionados con el compilador nuevo, informa el error. Puedes inhabilitar D8 de forma temporal y usar DX incluyendo lo siguiente en el archivo gradle.properties
del proyecto:
android.enableD8=false
En el caso de los proyectos que usan funciones del lenguaje Java 8, la expansión de sintaxis incremental está habilitada de forma predeterminada. Para inhabilitarla, especifica lo siguiente en el archivo gradle.properties
de tu proyecto:
android.enableIncrementalDesugaring=false.
Vista previa para usuarios: Si ya estás usando una versión de vista previa de D8, ten en cuenta que ahora compila las bibliotecas incluidas en las herramientas de compilación del SDK, no en JDK. Por lo tanto, si accedes a API que existen en JDK, pero no en las bibliotecas de compilación de SDK, se mostrará un error de compilación.
Cambios en el comportamiento
Cuando compilas varios APK orientados a una ABI diferente, el complemento ya no genera APK para las siguientes ABI de forma predeterminada:
mips
,mips64
yarmeabi
.Para compilar un APK que se oriente a esas ABI, usa NDK r16b o una versión anterior, y especifica las ABI en el archivo
build.gradle
, como se muestra a continuación:
Groovy
splits { abi { include 'armeabi', 'mips', 'mips64' ... } }
Kotlin
splits { abi { include("armeabi", "mips", "mips64") ... } }
- La caché de compilación del complemento para Android ahora desaloja las entradas de caché que tienen más de 30 días.
- Cuando pasas
"auto"
aresConfig
, ya no se seleccionan automáticamente los recursos de strings para empaquetar en el APK. Si continuas usando"auto"
, el complemento empaqueta todos los recursos de strings que proporcionan la app y sus dependencias. Por lo tanto, en su lugar, debes especificar cada configuración regional que quieras que el complemento empaquete en el APK. Debido a que los módulos locales no pueden depender del APK de prueba de tu app, agregar dependencias a tus pruebas instrumentadas mediante la configuración de
androidTestApi
, en lugar deandroidTestImplementation
, provoca que Gradle emita la siguiente advertencia:Groovy
WARNING: Configuration 'androidTestApi' is obsolete and has been replaced with 'androidTestImplementation'
Kotlin
WARNING: Configuration 'androidTestApi' is obsolete and has been replaced with 'androidTestImplementation'
Correcciones
- Se corrige el error por el que Android Studio no reconoce correctamente las dependencias en compilaciones compuestas.
- Se corrige el error en el que se muestra un error de sincronización de proyecto cuando se carga el complemento para Android varias veces en una única compilación (por ejemplo, cuando varios subproyectos incluyen el complemento para Android en la ruta de la clase buildscript).
3.0.0 (octubre de 2017)
El complemento de Android para Gradle 3.0.0 incluye una variedad de cambios que están destinados a solucionar problemas de rendimiento de proyectos grandes.
Por ejemplo, en un proyecto preliminar de muestra con aproximadamente 130 módulos y una gran cantidad de dependencias externas (pero sin código ni recursos), puedes experimentar mejoras de rendimiento similares a las siguientes:
Versión del complemento de Android y Versión de Gradle | Complemento de Android 2.2.0 y Gradle 2.14.1 | Complemento de Android 2.3.0 y Gradle 3.3 | Complemento de Android 3.0.0 y Gradle 4.1 |
---|---|---|---|
Configuración (p. ej., ejecución de ./gradlew --help ) |
Aprox. 2 min | Aprox. 9 s | Aprox. 2.5 s |
Cambio en Java de 1 línea (cambio de implementación) | Aprox. 2 min y 15 s | Aprox. 29 s | Aprox. 6.4 s |
Algunos de estos cambios dividen las compilaciones existentes. Por lo tanto, debes considerar el esfuerzo de migrar el proyecto antes de usar el nuevo complemento.
Si no experimentas las mejoras de rendimiento que se describen anteriormente, informa un error e incluye un seguimiento de la compilación mediante Gradle Profiler.
Esta versión del complemento para Android requiere lo siguiente:
- Gradle 4.1 o una versión posterior (para obtener más información, consulta la sección sobre cómo actualizar Gradle)
- Herramientas de compilación 26.0.2 o versiones posteriores
(con esta actualización, ya no es necesario especificar una versión para las herramientas de compilación; el complemento usa la versión mínima requerida de forma predeterminada,
por lo que puedes quitar la propiedad
android.buildToolsVersion
)
3.0.1 (noviembre de 2017)
Esta es una actualización menor que brinda compatibilidad con Android Studio 3.0.1 e incluye correcciones de errores y mejoras de rendimiento.
Optimizaciones
- Se mejoró el paralelismo en proyectos que tienen varios módulos mediante un gráfico de tareas refinado.
- Cuando se realizan cambios en una dependencia, Gradle lleva a cabo compilaciones más rápidas, ya que no vuelve a compilar módulos que no tienen acceso a la API de esa dependencia. Debes restringir qué dependencias filtran sus API a otros módulos. Para ello, usa las configuraciones de dependencia nuevas de Gradle:
implementation
,api
,compileOnly
yruntimeOnly
. - La velocidad de compilación incremental es mayor debido a la conversión a dex por clase. Cada clase se compila en archivos DEX independientes y solo las clases que se modifican se vuelven a convertir a dex. También se mejoraron las velocidades de compilación para apps que configuran
minSdkVersion
en un valor 20 o inferior, y usan legacy multi-dex. - Velocidades de compilación mejoradas mediante la optimización de determinadas tareas para usar resultados en caché. Si quieres beneficiarte de esta optimización, primero debes habilitar la caché de compilación de Gradle.
- Procesamiento incremental de recursos mejorado gracias al uso de AAPT2, que ahora está habilitada de forma predeterminada.
Si tienes problemas al usar AAPT2, informa el error. También puedes inhabilitar AAPT2 si configuras
android.enableAapt2=false
en tu archivogradle.properties
y reinicias el daemon de Gradle mediante la ejecución de./gradlew --stop
desde la línea de comandos.
Funciones nuevas
- Administración de dependencias con detección de variantes. Cuando se compila la variante de un módulo, el complemento hace coincidir automáticamente las variantes de dependencias de módulos de biblioteca locales con la del módulo que estás compilando.
- Se incluye un complemento de módulo de función nuevo compatible con Apps instantáneas Android y su SDK (que puedes descargar con SDK Manager). A fin de obtener más información para crear módulos de función con el complemento nuevo, consulta Estructura de una app instantánea con varias funciones.
- Compatibilidad integrada para usar determinadas funciones de lenguaje y bibliotecas Java 8. Se dio de baja Jack y ya no se usa. Para poder usar la compatibilidad con Java 8 mejorada que está integrada en la cadena de herramientas predeterminada, primero debes inhabilitar Jack. Para obtener más información, consulta Cómo usar funciones del lenguaje Java 8.
- Se agregó compatibilidad para ejecutar pruebas con Android Test Orchestrator, que permite ejecutar cada una de las pruebas de la app dentro de la invocación de
Instrumentation
. Dado que cada prueba se ejecuta en su propia instancia deInstrumentation
, los estados compartidos entre pruebas no se acumulan en la CPU ni en la memoria del dispositivo. Incluso si falla una de las pruebas, se elimina solo su propia instancia deInstrumentation
, de modo que aún se siguen ejecutando el resto de las pruebas.- Se agregó
testOptions.execution
para determinar si se usará la organización de prueba en el dispositivo. Si deseas usar Android Test Orchestrator, debes especificarANDROID_TEST_ORCHESTRATOR
, como se muestra a continuación. De forma predeterminada, esta propiedad se configura enHOST
, que inhabilita la organización en el dispositivo y es el método estándar para ejecutar pruebas.
- Se agregó
Groovy
android { testOptions { execution 'ANDROID_TEST_ORCHESTRATOR' } }
Kotlin
android { testOptions { execution = "ANDROID_TEST_ORCHESTRATOR" } }
- La nueva configuración de dependencia
androidTestUtil
permite instalar otro APK de asistencia de prueba antes de ejecutar las pruebas de instrumentación, como Android Test Orchestrator:
Groovy
dependencies { androidTestUtil 'com.android.support.test:orchestrator:1.0.0' ... }
Kotlin
dependencies { androidTestUtil("com.android.support.test:orchestrator:1.0.0") ... }
- Se agregó
testOptions.unitTests.includeAndroidResources
para brindar compatibilidad con pruebas de unidades que requieren recursos de Android, como Roboelectric. Cuando se configura esta propiedad entrue
, el complemento lleva a cabo la combinación de recursos, elementos y manifiestos antes de ejecutar las pruebas de unidades. Luego, las pruebas pueden inspeccionarcom/android/tools/test_config.properties
en la ruta de clase para las siguientes claves:android_merged_assets
: Es la ruta de acceso absoluta del directorio de recursos combinados.Nota: Para los módulos de biblioteca, los elementos combinados no contienen los elementos de las dependencias (consulta Error n.° 65550419).
android_merged_manifest
: es la ruta de acceso absoluta del archivo de manifiesto combinado.android_merged_resources
: es la ruta absoluta al directorio de recursos combinados, que contiene todos los recursos del módulo y todas sus dependencias.android_custom_package
: es el nombre del paquete de la clase R final. Si modificas de manera dinámica el ID de aplicación, es posible que el nombre de ese paquete no coincida con el atributopackage
en el manifiesto de la app.
- Se incluye compatibilidad con fuentes como recursos (una función nueva que se introdujo en Android 8.0 (nivel de API 26)).
- Se incluye compatibilidad para APK específicos de idioma con el SDK de Apps instantáneas Android 1.1 y versiones posteriores.
- Ahora es posible cambiar el directorio de salida del proyecto de compilación nativo externo, como se muestra a continuación:
Groovy
android { ... externalNativeBuild { // For ndk-build, instead use the ndkBuild block. cmake { ... // Specifies a relative path for outputs from external native // builds. You can specify any path that's not a subdirectory // of your project's temporary build/ directory. buildStagingDirectory "./outputs/cmake" } } }
Kotlin
android { ... externalNativeBuild { // For ndk-build, instead use the ndkBuild block. cmake { ... // Specifies a relative path for outputs from external native // builds. You can specify any path that's not a subdirectory // of your project's temporary build/ directory. buildStagingDirectory = "./outputs/cmake" } } }
- Ahora puedes usar CMake 3.7 o versiones posteriores cuando compiles proyectos nativos desde Android Studio.
- La nueva configuración de dependencia
lintChecks
permite compilar un JAR que define reglas de lint personalizadas y empaquetarlo en tus proyectos AAR y APK. Las reglas de lint personalizadas deben pertenecer a un proyecto separado que genere un único JAR e incluya solo dependenciascompileOnly
. Luego, otros módulos de app y biblioteca pueden depender del proyecto de lint mediante la configuraciónlintChecks
:
Groovy
dependencies { // This tells the Gradle plugin to build ':lint-checks' into a lint.jar file // and package it with your module. If the module is an Android library, // other projects that depend on it automatically use the lint checks. // If the module is an app, lint includes these rules when analyzing the app. lintChecks project(':lint-checks') }
Kotlin
dependencies { // This tells the Gradle plugin to build ':lint-checks' into a lint.jar file // and package it with your module. If the module is an Android library, // other projects that depend on it automatically use the lint checks. // If the module is an app, lint includes these rules when analyzing the app. lintChecks(project(":lint-checks")) }
Cambios en el comportamiento
- El complemento para Android 3.0.0 quita determinadas API y, si se usan, se daña la compilación. Por ejemplo, ya no es posible usar la API de variantes para acceder a objetos
outputFile()
ni usarprocessManifest.manifestOutputFile()
para obtener el archivo de manifiesto de cada variante. Si necesitas obtener más información, consulta Cambios en la API. - Ya no es necesario especificar una versión para las herramientas de compilación (por lo tanto, ahora se puede quitar la propiedad
android.buildToolsVersion
). De forma predeterminada, el complemento usa automáticamente la versión mínima requerida de las herramientas de compilación correspondiente a la versión del complemento para Android que estás usando. - Ahora puedes habilitar o inhabilitar la compresión de PNG en el bloque
buildTypes
, como se muestra a continuación. La compresión de PNG ahora está habilitada de forma predeterminada para todas las compilaciones, excepto para las de depuración, ya que aumentan el tiempo de compilación en proyectos que incluyen muchos archivos PNG. Por lo tanto, para mejorar los tiempos de compilación en otros tipos de compilaciones, debes inhabilitar la compresión de PNG o convertir las imágenes a WebP.
Groovy
android { buildTypes { release { // Disables PNG crunching for the release build type. crunchPngs false } } }
Kotlin
android { buildTypes { release { // Disables PNG crunching for the release build type. isCrunchPngs = false } } }
- El complemento para Android ahora compila automáticamente los objetivos ejecutables que se configuran en los proyectos CMake externos.
- Ahora debes agregar procesadores de anotaciones a la ruta de clase del procesador usando la configuración de dependencia
annotationProcessor
. - Ahora, el uso del elemento obsoleto
ndkCompile
tiene más restricciones. En su lugar, debes comenzar a utilizar CMake o ndk-build para compilar código nativo que quieras empaquetar en tu APK. A fin de obtener más información, consulta Cómo migrar desde ndkcompile.
2.3.0 (febrero de 2017)
2.3.3 (junio de 2017)
Esta es una actualización menor que agrega compatibilidad con Android Studio 2.3.3.
2.3.2 (mayo de 2017)
Esta es una actualización menor que agrega compatibilidad con Android Studio 2.3.2.
2.3.1 (abril de 2017)
Esta es una actualización menor del complemento de Android 2.3.0 que corrige un error en el que algunos dispositivos Android físicos no funcionaban correctamente con Instant Run (consulta el Error #235879).
- Dependencias:
-
- Gradle 3.3 o una versión posterior
- Herramientas de compilación 25.0.0 o una versión posterior
- Nuevo:
-
- Usa Gradle 3.3, que incluye mejoras de rendimiento y funciones nuevas. Para obtener más información, consulta las notas de la versión de Gradle.
- Caché de compilación: Almacena determinada información de salida que genera el complemento para Android cuando se compila el proyecto (como AAR sin empaquetar y dependencias remotas que pasaron un proceso de pre-dexing). Tus compilaciones limpias son mucho más rápidas mientras se usa la caché, ya que el sistema de compilación puede simplemente reutilizar esos archivos almacenados en caché, en compilaciones posteriores, en lugar de volver a crearlos. Los proyectos que usan el complemento para Android 2.3.0 y versiones posteriores utilizan la caché de compilación de forma predeterminada. Para obtener más información, consulta Cómo mejorar la velocidad de compilación con la caché de compilación.
- Incluye una tarea
cleanBuildCache
que borra la caché de compilación. - Si estás usando la versión experimental de la caché de compilación (que se incluye en versiones anteriores del complemento), debes actualizar el complemento a la versión más reciente.
- Incluye una tarea
- Cambios:
-
- Admite los cambios de Instant Run que se incluyen en Android Studio 2.3.
- Los tiempos de configuración en proyectos muy grandes deberían ser mucho más rápidos.
- Se corrigieron errores relacionados con la descarga automática en la biblioteca de diseño de restricciones.
- El complemento ahora usa la versión 5.3.2 de ProGuard.
- Incluye muchas correcciones para los errores informados. Si encuentras errores, continúa enviando informes.
2.2.0 (septiembre de 2016)
- Dependencias:
-
- Gradle 2.14.1 o versiones posteriores
- Herramientas de compilación 23.0.2 o versiones posteriores
- Nuevo:
-
- Usa Gradle 2.14.1, que incluye mejoras de rendimiento y funciones nuevas, además de corregir una vulnerabilidad de seguridad que permite la elevación de privilegios local cuando se usa el daemon de Gradle. Para obtener más información, consulta las notas de la versión de Gradle.
- Con el DSL de
externalNativeBuild {}
, Gradle ahora permite vincular a fuentes nativas y compilar bibliotecas nativas usando CMake o ndk-build. Después de compilar las bibliotecas nativas, Gradle las empaqueta en tu APK. Si deseas obtener más información para usar CMake y ndk-build con Gradle, lee Cómo agregar código C y C++ a tu proyecto. - Cuando ejecutas una compilación desde la línea de comandos, Gradle ahora intenta descargar automáticamente los componentes o las actualizaciones del SDK faltantes de los que depende el proyecto. Para obtener más información, consulta Cómo descargar automáticamente los paquetes que faltan con Gradle.
- Una nueva función de almacenamiento en caché experimental permite a Gradle acelerar los tiempos de compilación a través del proceso de pre-dexing, el almacenamiento y la reutilización de las versiones anteriores de las bibliotecas convertidas a dex. Si quieres obtener más información para usar esta función experimental, consulta la guía Caché de compilación.
- Mejora el rendimiento de compilación, ya que adopta una canalización de empaquetado predeterminada nueva que controla la compresión, la firma y el uso de zipalign en una tarea. Puedes volver a usar las herramientas de empaquetado anteriores agregando
android.useOldPackaging=true
al archivogradle.properties
. Mientras se usa la nueva herramienta de empaquetado, no está disponible la tareazipalignDebug
. Sin embargo, puedes crear una llamando al métodocreateZipAlignTask(String taskName, File inputFile, File outputFile)
. - La firma de APK ahora usa el esquema de firma de APK v2, además de la de JAR tradicional. Todas las plataformas de Android aceptan los APK resultantes. Cualquier modificación a esos APK después de firmar invalida las firmas v2 y evita la instalación en un dispositivo. Para inhabilitar esta función, agrega lo siguiente al archivo
build.gradle
de nivel de módulo:Groovy
android { ... signingConfigs { config { ... v2SigningEnabled false } } }
Kotlin
android { ... signingConfigs { create("config") { ... v2SigningEnabled = false } } }
- Para compilaciones multidex, ahora puedes usar las reglas de ProGuard a fin de determinar qué clases debe compilar Gradle en el archivo DEX principal de la app. Dado que el sistema de Android primero carga el archivo DEX principal cuando se inicia la app, puedes priorizar ciertas clases en el inicio mediante la compilación en ese archivo DEX. Después de crear un archivo de configuración ProGuard especial para el archivo DEX principal, pasa la ruta de acceso del archivo de configuración a Gradle mediante
buildTypes.multiDexKeepProguard
. El uso de este DSL es diferente del uso debuildTypes.proguardFiles
, que proporciona reglas generales de ProGuard para la app y no especifica las clases del archivo DEX principal. - Agrega compatibilidad con la marca
android:extractNativeLibs
, que puede reducir el tamaño de la app cuando la instalas en un dispositivo. Cuando configuras esta marca comofalse
en el elemento<application>
del manifiesto de la app, Gradle empaqueta las versiones sin comprimir y alineadas de las bibliotecas nativas con el APK. De esta manera, se evita quePackageManager
copie las bibliotecas nativas del APK en el sistema de archivos del dispositivo durante la instalación y permite realizar actualizaciones delta de la app más pequeñas. - Ahora puedes especificar
versionNameSuffix
yapplicationIdSuffix
para las variantes de producto. (Error 59614)
- Cambios:
-
getDefaultProguardFile
ahora muestra los archivos ProGuard predeterminados que proporciona el complemento de Android para Gradle y ya no usa los del SDK de Android.- Rendimiento y funciones mejorados del compilador Jack:
- Jack ahora es compatible con la cobertura de prueba Jacoco cuando se configura
testCoverageEnabled
entrue
. - Compatibilidad mejorada para procesadores de anotaciones. Los procesadores de anotaciones de la ruta de clase, como cualquier dependencia de
compile
, se aplican automáticamente a la compilación. También puedes especificar un procesador de anotaciones en tu compilación y pasar argumentos mediante el DSL dejavaCompileOptions.annotationProcessorOptions {}
en el archivobuild.gradle
de nivel de módulo:Groovy
android { ... defaultConfig { ... javaCompileOptions { annotationProcessorOptions { className 'com.example.MyProcessor' // Arguments are optional. arguments = [ foo : 'bar' ] } } } }
Kotlin
android { ... defaultConfig { ... javaCompileOptions { annotationProcessorOptions { className = "com.example.MyProcessor" // Arguments are optional. arguments(mapOf(foo to "bar")) } } } }
Si deseas aplicar un procesador de anotaciones durante el tiempo de compilación, pero no quieres incluirlo en el APK, usa el alcance de la dependencia
annotationProcessor
.Groovy
dependencies { compile 'com.google.dagger:dagger:2.0' annotationProcessor 'com.google.dagger:dagger-compiler:2.0' // or use buildVariantAnnotationProcessor to target a specific build variant }
Kotlin
dependencies { implementation("com.google.dagger:dagger:2.0") annotationProcessor("com.google.dagger:dagger-compiler:2.0") // or use buildVariantAnnotationProcessor to target a specific build variant }
Para obtener una lista de los parámetros que puedes configurar, ejecuta lo siguiente desde la línea de comandos:
java -jar /build-tools/jack.jar --help-properties
- Jack ahora es compatible con la cobertura de prueba Jacoco cuando se configura
- De forma predeterminada, si el tamaño del montón del daemon de Gradle es de al menos 1.5 GB, Jack ahora se ejecutará en el mismo proceso que Gradle. Para ajustar el tamaño del montón de daemon, agrega lo siguiente a tu archivo
gradle.properties
:# This sets the daemon heap size to 1.5GB. org.gradle.jvmargs=-Xmx1536M
2.1.0 (abril de 2016)
2.1.3 (agosto de 2016)
Esta actualización requiere Gradle 2.14.1 o una versión posterior. Gradle 2.14.1 incluye mejoras de rendimiento, funciones nuevas y una corrección de seguridad importante. Para obtener más información, consulta las notas de la versión de Gradle.
- Dependencias:
-
- Gradle 2.10 o versiones posteriores
- Herramientas de compilación 23.0.2 o una versión posterior
- Nuevo:
-
- Se agregó compatibilidad con la Vista previa para desarrolladores de N, JDK 8 y funciones del lenguaje Java 8 usando la cadena de herramientas de Jack. Para obtener más información, consulta la Guía de versiones preliminares de N.
Nota: Por el momento, Instant Run no funciona con Jack y se inhabilitará durante el uso de la nueva cadena de herramientas. Solo debes usar Jack si estás desarrollando contenido para las vistas previas de N y quieres usar las funciones del lenguaje Java 8 compatibles.
- Se agregó compatibilidad predeterminada para la compilación incremental de Java con el fin de reducir el tiempo de compilación durante el desarrollo. Para ello, se vuelven a compilar partes de la fuente que cambiaron o que es necesario volver a compilar. Para inhabilitar esta función, agrega el siguiente código al archivo
build.gradle
de nivel de módulo:Groovy
android { ... compileOptions { incremental false } }
Kotlin
android { ... compileOptions { incremental = false } }
-
Se agregó compatibilidad con el proceso de conversión a Dex, que lleva a cabo la conversión a dex durante la compilación, en lugar de hacerlo en procesos de VM externos separados. Esto no solo acelera las compilaciones incrementales, sino también las compilaciones completas. Esta función está habilitada de forma predeterminada para proyectos que tienen configurado el tamaño de montón máximo del daemon de Gradle en al menos 2,048 MB. Para ello, incluye lo siguiente en el archivo
```none org.gradle.jvmargs = -Xmx2048m ```gradle.properties
del proyecto:Si defines un valor para
```none org.gradle.jvmargs = -Xmx3072m ```javaMaxHeapSize
en tu archivobuild.gradle
de nivel de módulo, debes establecerorg.gradle.jvmargs
en un valor dejavaMaxHeapSize
+ 1,024 MB. Por ejemplo, si establecesjavaMaxHeapSize
en "2048m", debes agregar lo siguiente al archivogradle.properties
de tu proyecto:Para inhabilitar el proceso de conversión a dex, agrega el siguiente código al archivo
build.gradle
a nivel de módulo:Groovy
android { ... dexOptions { dexInProcess false } }
Kotlin
android { ... dexOptions { dexInProcess = false } }
- Se agregó compatibilidad con la Vista previa para desarrolladores de N, JDK 8 y funciones del lenguaje Java 8 usando la cadena de herramientas de Jack. Para obtener más información, consulta la Guía de versiones preliminares de N.
2.0.0 (abril de 2016)
- Dependencias:
-
- Gradle 2.10 o versiones posteriores
- Herramientas de compilación 21.1.1 o una versión posterior.
- Nuevo:
-
- Puedes habilitar Instant Run si brindas compatibilidad con la inserción de código de bytes y envías actualizaciones de código y recursos a una app en ejecución en el emulador o en un dispositivo físico.
- Se agregó compatibilidad con compilaciones incrementales, incluso si no se está ejecutando la app. Se mejoraron los tiempos de compilación completa mediante la aplicación de cambios incrementales en el dispositivo conectado a través de Android Debug Bridge.
- Se agregó
maxProcessCount
para controlar cuántos procesos de trabajo subordinados se pueden generar al mismo tiempo. En el siguiente código, en el archivobuild.gradle
de nivel de módulo, se configura el número máximo de procesos simultáneos en 4:Groovy
android { ... dexOptions { maxProcessCount = 4 // this is the default value } }
Kotlin
android { ... dexOptions { maxProcessCount = 4 // this is the default value } }
- Se agregó un reductor de código experimental para brindar compatibilidad con el proceso de pre-dexing y para reducir la conversión a Dex de las dependencias, que no se admiten con Proguard. Eso mejora la velocidad de compilación de la variante de compilación de la depuración. Debido a que el reductor experimental no admite la optimización y la ofuscación, debes habilitar ProGuard a fin de que realice las compilaciones de lanzamientos. Si deseas habilitar el reductor experimental para tus compilaciones de depuración, agrega lo siguiente al archivo
build.gradle
a nivel de módulo:Groovy
android { ... buildTypes { debug { minifyEnabled true useProguard false } release { minifyEnabled true useProguard true // this is a default setting } } }
Kotlin
android { ... buildTypes { getByName("debug") { minifyEnabled = true useProguard = false } getByName("release") { minifyEnabled = true useProguard = true // this is a default setting } } }
- Se agregó compatibilidad de registro y rendimiento mejorado para el reductor de recursos,
que ahora registra todas las operaciones en un archivo
resources.txt
ubicado en la misma carpeta que los archivos de registro de Proguard.
- Comportamiento modificado:
-
- Cuando se configura
minSdkVersion
en 18 o en un valor superior, la firma del APK usa SHA256. - Las claves de DSA y ECDSA ahora pueden firmar paquetes APK.
Nota: El proveedor de almacén de claves de Android ya no admite claves de DSA en Android 6.0 (nivel de API 23) ni versiones posteriores.
- Cuando se configura
- Errores corregidos:
-
- Se corrigió un error que generaba dependencias de AAR duplicadas en las configuraciones de compilación principal y de prueba.