Próxima versión principal del complemento Gradle de Android

Publicado por Murat Yener, Defensor de los desarrolladores

Hoy marca el lanzamiento de la primera versión canaria de Android Studio Arctic Fox (2020.3.1), junto con la versión 7.0.0-alpha01 del complemento de Android Gradle (AGP). Con esta versión, cambiamos la numeración de la versión de nuestro complemento de Gradle y lo desacoplamos del esquema de control de versiones de Android Studio. En esta publicación de blog, explicaremos las razones del cambio, así como también daremos una vista previa de algunos cambios importantes que estamos realizando en nuestra nueva incubadora. API de complemento de DSL y Gradle de Android.

Nuevo esquema de control de versiones

Con AGP 7.0.0 estamos adoptando los principios de control de versiones semántico. Esto significa que solo los cambios importantes en la versión romperán la compatibilidad de la API. Planeamos lanzar una versión principal cada año, justo después de que Gradle presente su versión principal anual.

Además, en caso de cambios sustanciales, nos aseguraremos de que la API eliminada esté marcada con @Deprecated aproximadamente con un año de anticipación y que su reemplazo esté disponible al mismo tiempo. Esto les dará a los desarrolladores alrededor de un año para migrar y probar sus complementos con la nueva API antes de que se elimine la antigua.

Alineación con La versión de Gradle también es la razón por la que nos saltamos las versiones 5 y 6 y nos trasladamos directamente a AGP 7.0.0. Esta alineación indica que AGP 7.x está diseñado para funcionar con la API de Gradle 7.x. Si bien también puede ejecutarse en Gradle 8.x, esto no está garantizado y dependerá de que 8.x elimine las API en las que se basa AGP.

Con este cambio, el número de versión de AGP se separará del número de versión de Android Studio. Sin embargo, continuaremos lanzando Android Studio y el complemento de Android Gradle juntos en el futuro previsible.

La compatibilidad entre Android Studio y el complemento de Android Gradle permanece sin cambios. Como regla general, los proyectos que utilizan versiones estables de AGP se puede abrir con las últimas versiones de Android Studio.

Requisito 11 de Java

Aún puede usar el lenguaje de programación Java versión 8 con AGP 7.0.0-alpha01, pero estamos cambiando la versión mínima del lenguaje de programación Java requerida en Java 11, comenzando con AGP 7.0.0-alpha02. Anunciamos esto al comienzo del programa Canary y varios meses antes de la versión estable para que los desarrolladores tengan tiempo de prepararse.

Incubación de API y cambios importantes de API

Esta versión de AGP también introduce algunos cambios en la API. Como recordatorio, una serie de API introducidas en AGP 4.1 se han marcado como en incubación y están sujetas a cambios. De hecho, algunas de estas API han cambiado en AGP 4.2. Las API que se están incubando actualmente no siguen el ciclo de desactivación explicado anteriormente.

A continuación se muestra un resumen de algunos cambios importantes de la API.

  • los onVariants, onProperties es onVariantProperties los bloques se eliminan en la versión 4.2 beta.
  • Estas API se reemplazan por beforeVariants es onVariants en el nuevo androidComponents bloquear. Ambos beforeVariants es onVariants opcionalmente puede usar un archivo VariantSelector para reducir la cantidad de variantes en las que se ejecutará la devolución de llamada, según el tipo de compilación, el nombre o el sabor utilizando withBuildType, withName es withFlavor Por consiguiente. La lambda onVariants es beforeVariants recibe se ejecuta después de que AGP ha calculado las combinaciones de variantes en afterEvaluate. Propiedad de anidación en el interior onVariants es removido.
  • Se agregan API similares a androidComponents para permitir bloques separados para UnitTests (beforeUnitTest es unitTest) y AndroidTests (beforeAndroidTest es androidTest) en lugar de anidar pruebas dentro de variantes.
  • Se ha cambiado el nombre de dos clases que se utilizan tanto en la forma antigua como en la nueva de registrar acciones para variantes. Variant y ahora VariantBuilder, y se usa en beforeVariants fase. VariantProperties y ahora Variant y se trasladó a la nueva onVariants bloquear.

Echemos un vistazo a algunos de estos cambios. Aquí hay un ejemplo onVariants bloque que apunta a la versión de lanzamiento. los onVariants el bloque se cambia a beforeVariants y utiliza un selector de variantes en el siguiente ejemplo.

```
android {
   …
   //onVariants.withName("release") {
   //   ...
   //}
   …
}
androidComponents {
   val release = selector().withBuildType("release")
   beforeVariants(release) { variant ->
      ...
   }
}

```

Igualmente onVariantProperties el bloque se cambia a onVariants.

```
android {
   ...
   //onVariantProperties {
   //   ... 
   //}
   …
}

androidComponents.onVariants { variant ->
      ... 
}

```

Tenga en cuenta que esta personalización generalmente se realiza en un complemento y no debería estar en build.gradle. Estamos dejando de usar funciones con receptores que se ajustan a la sintaxis DSL pero que no son necesarias en el código del complemento.

Estamos planeando hacer que estas API sean estables con AGP 7.0.0 y todos los autores de complementos deben migrar a los nuevos componentes de Android. Si desea evitar el manejo de dichos cambios, asegúrese de que sus complementos solo usen API estables y no dependan de las API marcadas como en incubación.

Si desea obtener más información sobre los otros cambios que vienen con esta versión, asegúrese de consultar la Notas de lanzamiento.

Java es una marca comercial registrada de Oracle y / o sus afiliadas.



Compruebe también

Nuevos gadgets de Android y wearables en el Mobile World Congress + ¡Sintoniza un nuevo episodio de #TheAndroidShow la próxima semana!

Publicado por Anirudh Dewani, Director de Relaciones con Desarrolladores de Android Hoy, en el Mobile …

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *