Complemento de Android para Gradle 4.1.0 (agosto de 2020)

Compatibilidad

<p>This version of the Android plugin requires the following:</p>
<ul>
  <li>
    <p><a href="https://docs.gradle.org/6.5.1/release-notes.html">Gradle 6.5</a>.
    To learn more, read the section about <a href="#updating-gradle">updating
    Gradle</a>.</p>
  </li>
  <li>
    <p><a href="/studio/releases/build-tools.html#notes">SDK Build Tools
    29.0.2</a> or higher.</p>
  </li>
</ul>
<p>The default NDK version in this release is 21.1.6352462. To install a
different NDK version, see <a href="/studio/projects/install-ndk#specific-version">Install a specific version of the NDK</a>.</p>

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

Importante: Si ya implementaste secuencias de comandos de compilación KTS o usas Kotlin en buildSrc, es posible que se produzcan fallas de compatibilidad con el código fuente para ciertos errores que se habrían manifestado como errores de tiempo de ejecución en versiones anteriores.

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 APIs y el DSL de Kotlin del complemento de Android para Gradle, informa un error.

Cómo exportar dependencias C/C++ desde AARs

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 {
    <var>mylibrary</var&;gt {
      headers "src/main/cpp/<var>mylibrary</var>/include"
    }
<var>myotherlibrary</var> {
    headers "src/main/cpp/<var>myotherlibrary</var>/include"
}

}
      
buildFeatures {
    prefabPublishing = true
}


prefab {
    create("<var>mylibrary</var>") {
      headers = "src/main/cpp/<var>mylibrary</var>/include"
    }
create("<var>myotherlibrary</var>") {
    headers = "src/main/cpp/<var>myotherlibrary</var>/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.

Nota: En el caso de los usuarios del complemento de Android para Gradle 4.0 y versiones posteriores, cambió la configuración relacionada con la importación de bibliotecas nativas previamente compiladas. Para obtener más información, consulta las notas de la versión 4.0.

Compatibilidad de R8 con metadatos de Kotlin

Kotlin utiliza metadatos personalizados en los archivos de clase de Java para 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{:.external} 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 Android para Gradle 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 de 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.