Complemento de Android para Gradle 4.2.0 (marzo de 2021)

Compatibilidad

Versión mínima Versión predeterminada Notas
Gradle 6.7.1 N/A Para obtener más información, consulta cómo actualizar Gradle.
Herramientas de desarrollo del SDK 30.0.2 30.0.2 Instala o configura las herramientas de compilación del SDK.
NDK N/A 21.4.7075529 Instala o configura una versión diferente del NDK.

Funciones nuevas

Esta versión del complemento de Android para Gradle incluye las siguientes funciones nuevas:

Versión 8 del lenguaje Java según la configuración predeterminada

A partir de la versión 4.2, el AGP usará el nivel de lenguaje Java 8 de forma predeterminada. Java 8 proporciona acceso a varias funciones más recientes del lenguaje, incluidas las expresiones lambda, las referencias de métodos y los métodos de la interfaz estáticos. Si quieres obtener una lista completa de las funciones compatibles, consulta la documentación de Java 8.

Para mantener el comportamiento anterior, especifica Java 7 de forma explícita en el archivo build.gradle.kts o build.gradle de nivel de módulo:

// 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 en la herramienta 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 las máquinas con Windows. El nuevo compilador de recursos JVM está 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 incremental de ADB 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

Para reducir el desorden en 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 generaba una línea de resultado para 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 desde 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 <var>projectDir</var>/gradle.properties, <var>projectDir</var>/app/gradle.properties, <var>projectDir</var>/library/gradle.properties, etc. Para los módulos de apps, si la misma propiedad de Gradle se encontraba en <var>projectDir</var>/gradle.properties y <var>projectDir</var>/app/gradle.properties, el valor de <var>projectDir</var>/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., <var>projectDir</var>/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 la JVM debido a los cambios en el recolector de elementos no utilizados. Estos errores se describen a continuación.

Nota: Si bien recomendamos ejecutar Gradle con JDK 11, es posible cambiar el JDK que se usó para ejecutar Gradle en el diálogo Project Structure. Si ajustas esta configuración, solo cambiarás el JDK con el cual se ejecutará Gradle, pero no el que se usa para ejecutar Studio en sí.

Compatibilidad de Studio con el complemento de Android para Gradle (AGP)

Android Studio 4.2 puede abrir proyectos que usen AGP 3.1 y versiones posteriores, siempre y cuando AGP ejecute Gradle 4.8.1 y versiones posteriores. Para obtener más información sobre la compatibilidad de Gradle, consulta Cómo actualizar Gradle.

Cómo optimizar las compilaciones de Gradle para JDK 11

Esta actualización a JDK 11 afecta la configuración predeterminada del recolector de elementos no utilizados de JVM, ya que el JDK 8 usa el recolector paralelo, mientras que el JDK 11 usa el recolector G1.

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