Notas de la versión del complemento de Android para Gradle

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 de Android para Gradle
• Referencia del DSL de Gradle
• Guía del usuario sobre el rendimiento 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 configura el complemento en la versión 7.2.2 del archivo build.gradle:

plugins {
    id 'com.android.application' version '7.2.2' apply false
    id 'com.android.library' version '7.2.2' apply false
    id 'org.jetbrains.kotlin.android' version '1.5.31' apply false
}

plugins {
    id("com.android.application") version "7.2.2" apply false
    id("com.android.library") version "7.2.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.

Puedes especificar la versión de Gradle en el menú File > Project Structure > Project en Android Studio o actualizar tu versión de Gradle con la línea de comandos. La forma recomendada es usar la herramienta de línea de comandos Gradle Wrapper, que actualiza las secuencias de comandos gradlew. En el siguiente ejemplo, se configura la versión de Gradle en 7.5.1 con Gradle Wrapper. Ten en cuenta que debes ejecutar este comando dos veces para actualizar tanto Gradle como el wrapper de Gradle (si quieres obtener más información, consulta el artículo para actualizar el wrapper de Gradle).

./gradle wrapper --gradle-version --7.5.1

Sin embargo, en algunos casos, esto puede fallar; por ejemplo, si acabas de actualizar AGP y ya no es compatible con la versión actual de Gradle. En este caso, debes editar la referencia a la 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.5.1 en el archivo gradle-wrapper.properties.

...
distributionUrl = "https\://services.gradle.org/distributions/gradle-7.5.1-bin.zip"
...

Compatibilidad del complemento de Android para Gradle y Android Studio

El sistema de compilación de Android Studio se basa en Gradle, y el complemento de Android para Gradle incorpora varias funciones específicas para compilar apps para Android. En la siguiente tabla, se muestra qué versión del complemento de Android para Gradle se requiere en cada versión de Android Studio.

A fin de conocer las novedades del complemento de Android para Gradle, consulta las notas de la versión del complemento de Android para Gradle.

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 APIs obsoletas en la próxima actualización importante.

7.2.0 (mayo de 2022)

El complemento de Android para Gradle 7.2.0 es una actualización importante que incluye una variedad de nuevas funciones y mejoras.

Advertencia de Jetifier y comprobación en Build Analyzer

Ahora, Build Analyzer muestra una advertencia si el archivo gradle.properties de tu proyecto incluye android.enableJetifier=true. Esta marca se introdujo en una versión anterior de Android Studio a fin de habilitar AndroidX para las bibliotecas que no lo admiten de forma nativa. Sin embargo, el ecosistema de la biblioteca se trasladó principalmente para admitir AndroidX de forma nativa, y es probable que tu proyecto ya no necesite la marca de Jetifier. Además, la marca puede ralentizar el rendimiento de compilación. Si ves esta advertencia, puedes ejecutar una verificación dentro de Build Analyzer para confirmar si se puede quitar la marca.

Compatibilidad con dispositivos de prueba

A partir de Android Studio Chipmunk beta 1, Android Studio es compatible con dispositivos de prueba Android y Java. Consulta la guía de Gradle sobre cómo usar dispositivos de prueba para obtener más información sobre la función de instalación de prueba y cómo usarla en un proyecto de Java.

Si quieres habilitar los dispositivos de prueba en el módulo de biblioteca de Android, agrega lo siguiente al archivo build.gradle en el nivel de la biblioteca:

android {
    testFixtures {
        enable true

        // enable testFixtures's android resources (disabled by default)
        // androidResources true
    }
}

De forma predeterminada, al publicar la biblioteca, también se publica el AAR de los dispositivos de prueba con la biblioteca principal. El archivo de metadatos del módulo de Gradle contendrá información para que Gradle pueda consumir el artefacto correcto cuando se solicite el componente testFixtures.

Para inhabilitar la publicación de los AAR de las bibliotecas de prueba de una biblioteca en la variante de lanzamiento, agrega lo siguiente a tu archivo build.gradle en el nivel de la biblioteca:

afterEvaluate {
    components.release.withVariantsFromConfiguration(
        configurations.releaseTestFixturesVariantReleaseApiPublication) { skip() }
    components.release.withVariantsFromConfiguration(
        configurations.releaseTestFixturesVariantReleaseRuntimePublication) { skip() }
}

Para consumir el AAR del dispositivo de prueba de una biblioteca de Android publicada, puedes usar el método de ayuda testFixtures() de Gradle.

dependencies {
    testImplementation testFixtures('com.example.company:publishedLib:1.0')
}

De forma predeterminada, lint analizará las fuentes de los dispositivos de prueba. Puedes configurar lint para que ignore las fuentes de los dispositivos de pruebas de la siguiente manera:

android {
    lint {
        ignoreTestFixturesSources true
    }
}

No se admiten raíces de contenido duplicadas

A partir de AGP 7.2, ya no puedes compartir el mismo directorio del código fuente en varios conjuntos de orígenes. Por ejemplo, no puedes usar las mismas fuentes de prueba para las pruebas de unidades y de instrumentación. Para obtener más información, consulta Cómo cambiar las configuraciones predeterminadas de conjuntos de orígenes.

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.

Compatibilidad

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 no ndk-build. La compatibilidad con ndk-build requerirá una actualización futura del NDK. El módulo publishing puede ser CMake o ndk-build.

• El módulo consuming debe habilitar prefab en el archivo build.gradle.

android {
  buildFeatures {
    prefab true
  }
}

• El módulo publishing debe habilitar prefabPublishing en el archivo build.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 archivo build.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 usar find_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.

Compatibilidad

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.

Ten en cuenta que SDK Manager y el Administrador de AVD en el paquete de herramientas del SDK obsoleto no funcionan con JDK 11. Para seguir usando SDK Manager y el Administrador de AVD con AGP 7.0 y posteriores, debes cambiar a las nuevas versiones de las herramientas en el Paquete de herramientas de línea de comandos del SDK de Android actual.

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.

// build.gradle

android {
  ...
  lintOptions {
    checkDependencies true
  }
}

// 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:

1. 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).

2. 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:

// build.gradle

android {
    compileSdkVersion 30

    compileOptions {
      sourceCompatibility JavaVersion.VERSION_11
      targetCompatibility JavaVersion.VERSION_11
    }

    // For Kotlin projects
    kotlinOptions {
      jvmTarget = "11"
    }
}

// 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ó con api o implementation.
  También se aplica a las variantes *Compile. Por ejemplo: debugCompile.
• provided
  Se reemplazó por compileOnly.
  También se aplica a las variantes *Provided. Por ejemplo: releaseProvided.
• apk
  Se reemplazó por runtimeOnly.
• publish
  Se reemplazó por runtimeOnly.

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

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:

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

// 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:

// build.gradle

android {
  ...
  signingConfigs {
    config {
        ...
        enableV3Signing true
        enableV4Signing true
    }
  }
}

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

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

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.

buildFeatures {
    prefabPublishing true
}

prefab {
    mylibrary {
      headers "src/main/cpp/mylibrary/include"
    }

    myotherlibrary {
        headers "src/main/cpp/myotherlibrary/include"
    }
}

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.

android {
   ndkPath "your-custom-ndk-path"
}

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.

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:

1. Si aún no lo hiciste, selecciona la opción Build > Make Project de la barra de menú para compilar tu app.
2. En la barra de menú, selecciona View > Tool Windows > Build.
3. 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 y java.util.OptionalDouble) y algunas otras clases nuevas que son útiles para las API anteriores
• Algunas adiciones a java.util.concurrent.atomic (métodos nuevos en AtomicInteger, AtomicLong y AtomicReference)
• 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:

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

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:

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

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:

// 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')
    ...
}

// 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:

android {
    dependenciesInfo {
        // Disables dependency metadata when building APKs.
        includeInApk = false
        // Disables dependency metadata when building Android App Bundles.
        includeInBundle = false
    }
}

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.

CMake ndk-build

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 y targetSdk.

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:

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']
    }
}

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

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:

android {
    viewBinding.enabled = true
}

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:

1. Agrega la marca -Pandroid.enableProfileJson=true cuando ejecutes una compilación de Gradle. Por ejemplo:

   gradlew assembleDebug -Pandroid.enableProfileJson=true

2. Abre el navegador Chrome y escribe chrome://tracing en la barra de búsqueda.

3. Haz clic en el botón Load y navega hasta project-root/build/android-profile para encontrar el archivo. El nombre del archivo es profile-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

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

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 dependencia lintChecks para incluir comprobaciones de lint en el archivo AAR publicado, debes migrar esas dependencias para usar la configuración de lintPublish 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 usar ndkBuild 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 Gradle para Android, 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

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 objeto TaskProvider, como variant.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 clases R.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 incluye annotation.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

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

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ía CommandLineArgumentProvider, 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 archivo gradle.properties:

  • android.useAndroidX: cuando se establece esta marca en true, 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 como false de forma predeterminada.
  • android.enableJetifier: cuando se establece esta marca en true, 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 en false de forma predeterminada. Puedes configurarla en true solo si android.useAndroidX también está configurado en true; 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 archivo build.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 y armeabi.

  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:

  splits {
      abi {
          include 'armeabi', 'mips', 'mips64'
          ...
      }
  }

  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" a resConfig, 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 de androidTestImplementation, 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:

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)

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 y runtimeOnly.
• 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 archivo gradle.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 de Instrumentation, 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 de Instrumentation, 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 especificar ANDROID_TEST_ORCHESTRATOR, como se muestra a continuación. De forma predeterminada, esta propiedad se configura en HOST, que inhabilita la organización en el dispositivo y es el método estándar para ejecutar pruebas.

android {
  testOptions {
    execution 'ANDROID_TEST_ORCHESTRATOR'
  }
}

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:

dependencies {
  androidTestUtil 'com.android.support.test:orchestrator:1.0.0'
  ...
}

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 en true, el complemento lleva a cabo la combinación de recursos, elementos y manifiestos antes de ejecutar las pruebas de unidades. Luego, las pruebas pueden inspeccionar com/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 atributo package 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:

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

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 dependencias compileOnly. Luego, otros módulos de app y biblioteca pueden depender del proyecto de lint mediante la configuración lintChecks:

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

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 usar processManifest.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.

android {
  buildTypes {
    release {
      // Disables PNG crunching for the release build type.
      crunchPngs false
    }
  }
}

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)

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.

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 archivo gradle.properties. Mientras se usa la nueva herramienta de empaquetado, no está disponible la tarea zipalignDebug. Sin embargo, puedes crear una llamando al método createZipAlignTask(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 de buildTypes.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 como false 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 que PackageManager 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 y applicationIdSuffix 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 en true.
  • 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 de javaCompileOptions.annotationProcessorOptions {} en el archivo build.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
  

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

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 gradle.properties del proyecto:

  ```none org.gradle.jvmargs = -Xmx2048m ```

  Si defines un valor para javaMaxHeapSize en tu archivo build.gradle de nivel de módulo, debes establecer org.gradle.jvmargs en un valor de javaMaxHeapSize + 1,024 MB. Por ejemplo, si estableces javaMaxHeapSize en "2048m", debes agregar lo siguiente al archivo gradle.properties de tu proyecto:

  ```none org.gradle.jvmargs = -Xmx3072m ```

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

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 archivo build.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.

Errores corregidos:

• Se corrigió un error que generaba dependencias de AAR duplicadas en las configuraciones de compilación principal y de prueba.

Versiones anteriores