lightbulb_outline Help shape the future of the Google Play Console, Android Studio, and Firebase. Start survey

Realizar la migración al complemento de Android para Gradle 3.0.0

Problema conocido: si tienes un proyecto de Android Studio que usa una versión alfa del complemento de Android 3.0.0 (como 3.0.0-alpha9), es posible que veas el siguiente error cuando realices la migración al complemento de Android 3.0.0-beta4 y sincronices tu proyecto: Gradle project refresh failed.

Resuelve este problema seleccionando Build > Clean Project en la barra de menú. Debes realizar esta acción solo una vez para cada proyecto. Luego, puedes sincronizar los archivos de tu proyecto con Gradle haciendo clic en Sync Project en la barra de menú.

Si deseas migrar tu proyecto al complemento de Android 3.0.0-beta4 o a una versión posterior, lee esta página para aprender a aplicar el complemento y la versión específica de Gradle, y a adaptar tu proyecto a algunos cambios importantes.

Actualizar la versión de Gradle

El nuevo complemento de Android requiere la versión de Gradle 4.1-rc-1 o una posterior. Si abres un proyecto existente usando Android Studio 3.0 Beta 1 o una versión posterior, sigue las indicaciones para actualizar automáticamente un proyecto existente a la versión compatible de Gradle.

Para actualizar Gradle manualmente, actualiza la URL engradle-wrapper.properties de la siguiente manera:

distributionUrl=\
  https\://services.gradle.org/distributions/gradle-4.1-rc-1-all.zip

Aplica el complemento

Si abres un proyecto existente usando Android Studio 3.0 Beta 1 o una versión posterior, sigue las indicaciones para actualizar automáticamente tu proyecto a la última versión del complemento de Android. Para actualizar tu proyecto manualmente, incluye el repositorio de Maven y cambia la versión del complemento en tu archivo build.gradle de nivel de proyecto de la siguiente manera:

buildscript {
    repositories {
        ...
        // You need to add the following repository to download the
        // new plugin.
        google()
    }

    dependencies {
        classpath 'com.android.tools.build:gradle:3.0.0-beta4'
    }
}

Usar dimensiones de tipos para la administración de dependencias con reconocimiento de variantes

En la versión 3.0.0 del complemento se incluye un nuevo mecanismo de dependencias que establece coincidencias entre variantes de forma automática cuando se consume una biblioteca. Esto significa que la variante debug de la app consume automáticamente la variante debug de una biblioteca, y así sucesivamente. También funciona cuando se usan tipos; la variante redDebug de una app consumirá la variante redDebug de una biblioteca. Para que esto funcione, el complemento ahora exige que todos los tipos pertenezcan a una dimensión de tipos determinada, incluso si deseas usar una sola dimensión. De lo contrario, verás el siguiente error de compilación:

Error:All flavors must now belong to a named flavor dimension.
The flavor 'flavor_name' is not assigned to a flavor dimension.

Para resolver este error, asigna cada tipo a una dimensión específica, como se muestra en el ejemplo siguiente. Debido a que ahora el complemento es el que establece coincidencias para las dependencias, debes denominar tus dimensiones de tipos con cuidado. Por ejemplo, si los módulos de tu app y de bibliotecas usan la dimensión foo, tendrás menos control sobre los tipos que el complemento considere para establecer coincidencias.

// Specifies a flavor dimension.
flavorDimensions "color"

productFlavors {
     red {
      // Assigns this product flavor to the 'color' flavor dimension.
      // This step is optional if you are using only one dimension.
      dimension "color"
      ...
    }

    blue {
      dimension "color"
      ...
    }
}

Resolver errores de compilación relacionados con el establecimiento de coincidencias para las dependencias

El complemento de Android intenta hacer coincidir cada variante de tu app con la misma variante de la biblioteca. Por lo tanto, cuando compilas una versión “freeDebug” de tu app, el complemento intenta establecer una coincidencia con las versiones “freeDebug” de las dependencias de su biblioteca local.

No obstante, considera el caso de que tu app configura un tipo de compilación llamado “staging”, pero una de las dependencias de su biblioteca no lo hace. Cuando el complemento intente compilar la versión “staging” de tu app, no sabrá qué versión de la biblioteca debe usar y verás un mensaje de error similar al siguiente:

Error:Failed to resolve: Could not resolve project :mylibrary.
Required by:
    project :app

El complemento de Android 3.0.0-beta4 y las versiones posteriores incluyen elementos DSL para ayudarte a controlar la manera en la que el complemento debe resolver situaciones en las cuales no es posible establecer una coincidencia directa de variantes entre una app y una dependencia. La tabla siguiente te ayuda a determinar la propiedad DSL que debes usar para resolver determinados errores de compilación relacionados con el establecimiento de coincidencias de dependencias con reconocimiento de variantes.

Causa del error de compilaciónResolución

Tu app incluye un tipo de compilación que no figura en una dependencia de la biblioteca.

Por ejemplo, tu app incluye el tipo de compilación “staging”, pero una dependencia incluye solo los tipos de compilación “debug” y “release”.

Ten en cuenta que no habrá problema si una dependencia de la biblioteca incluye un tipo de compilación que tu app no tiene. Eso ocurre porque el complemento simplemente nunca solicita el tipo de compilación a la dependencia.

Usa matchingFallbacks para especificar coincidencias alternativas para un tipo de compilación específico, como se muestra a continuación:
// In the app's build.gradle file.
android {
    buildTypes {
        debug {}
        release {}
        staging {
            // Specifies a sorted list of fallback build types that the
            // plugin should try to use when a dependency does not include a
            // "staging" build type. You may specify as many fallbacks as you
            // like, and the plugin selects the first build type that's
            // available in the dependency.
            matchingFallbacks = ['debug', 'qa', 'release']
        }
    }
}

Para una dimensión de tipos determinada que existe tanto en la app como en la dependencia de la biblioteca, tu app incluye tipos que no figuran en la biblioteca.

Por ejemplo, tanto tu app como las dependencias de su biblioteca incluyen una dimensión de tipos “tier”. No obstante, la dimensión “tier” de la app incluye los tipos “free” y “paid”, pero una dependencia solo incluye los tipos “demo” y “paid” para la misma dimensión.

Ten en cuenta que, en el caso de una dimensión de tipos determinada que existe en la app y en las dependencias de su biblioteca, no habrá problema cuando una biblioteca incluya un tipo de producto que no se encuentre en tu app. Eso ocurre porque el complemento simplemente nunca solicita ese tipo a la dependencia.

Usa matchingFallbacks para especificar coincidencias alternativas para el tipo de producto “free” de la app, como se muestra a continuación:
// In the app's build.gradle file.
android {
    defaultConfig{
    // Do not configure matchingFallbacks in the defaultConfig block.
    // Instead, you must specify fallbacks for a given product flavor in the
    // productFlavors block, as shown below.
  }
    flavorDimensions 'tier'
    productFlavors {
        paid {
            dimension 'tier'
            // Because the dependency already includes a "paid" flavor in its
            // "tier" dimension, you don't need to provide a list of fallbacks
            // for the "paid" flavor.
        }
        free {
            dimension 'tier'
            // Specifies a sorted list of fallback flavors that the plugin
            // should try to use when a dependency's matching dimension does
            // not include a "free" flavor. You may specify as many
            // fallbacks as you like, and the plugin selects the first flavor
            // that's available in the dependency's "tier" dimension.
            matchingFallbacks = ['demo', 'trial']
        }
    }
}

Una dependencia de biblioteca incluye una dimensión de tipos que no figura en tu app.

Por ejemplo, una dependencia de biblioteca incluye tipos para una dimensión “minApi”, pero tu app incluye tipos únicamente para la dimensión “tier”. Por lo tanto, cuando desees compilar la versión “freeDebug” de tu app, el complemento no sabrá si debe usar la versión “minApi23Debug” o “minApi18Debug” de la dependencia.

Ten en cuenta que no habrá problema cuando tu app incluya una dimensión de tipos que no figure en una dependencia de biblioteca. Esto ocurre porque el complemento establece coincidencias únicamente entre tipos de las dimensiones que existen en la dependencia. Por ejemplo, si una dependencia no incluyera una dimensión para ABI, la versión “freeX86Debug” de tu app simplemente usaría la versión “freeDebug” de la dependencia.

Usa missingDimensionStrategy en el bloque defaultConfig para especificar el tipo predeterminado que el complemento debe seleccionar de cada dimensión faltante, como se muestra en el siguiente ejemplo. También puedes anular tus selecciones en el bloque productFlavors, de modo que cada tipo pueda especificar una estrategia de establecimiento de coincidencias diferente para una dimensión faltante.
// In the app's build.gradle file.
android {
    defaultConfig{
    // Specifies a sorted list of flavors that the plugin should try to use from
    // a given dimension. The following tells the plugin that, when encountering
    // a dependency that includes a "minApi" dimension, it should select the
    // "minApi18" flavor. You can include additional flavor names to provide a
    // sorted list of fallbacks for the dimension.
    missingDimensionStrategy 'minApi', 'minApi18', 'minApi23'
    // You should specify a missingDimensionStrategy property for each
    // dimension that exists in a local dependency but not in your app.
    missingDimensionStrategy 'abi', 'x86', 'arm64'
    }
    flavorDimensions 'tier'
    productFlavors {
        free {
            dimension 'tier'
            // You can override the default selection at the product flavor
            // level by configuring another missingDimensionStrategy property
            // for the "minApi" dimension.
            missingDimensionStrategy 'minApi', 'minApi23', 'minApi18'
        }
        paid {}
    }
}

Migrar configuraciones de dependencias para módulos locales

Si configuraste correctamente tus dimensiones de tipos para aprovechar la resolución de dependencias con reconocimiento de variantes, ya no necesitas usar configuraciones específicas de variantes, como redDebugImplementation, para dependencias de módulos locales porque lo hace el complemento. El uso de configuraciones específicas de variantes es opcional y no afecta tu compilación.

No obstante, apuntar a una variante específica de una dependencia de un módulo local (por ejemplo, usar configuration: 'debug') genera el siguiente error de compilación:

Error:Could not resolve all dependencies for configuration
  ':app:prodDebugCompileClasspath'.
Project :app declares a dependency from configuration 'compile'
  to configuration 'debug' which is not declared in the descriptor
  for project :foo.

En lugar de ello, debes configurar tus dependencias de la siguiente manera:

dependencies {
    // This is the old method and no longer works for local
    // library modules:
    // debugCompile project(path: ':foo', configuration: 'debug')
    // releaseCompile project(path: ':foo', configuration: 'release')

    // Instead, simply use the following to take advantage of
    // variant-aware dependency resolution. You can learn more about
    // the 'implementation' configuration in the section about
    // new dependency configurations.
    implementation project(':foo')

    // You can, however, keep using variant-specific configurations when
    // targeting external dependencies. The following line adds 'app-magic'
    // as a dependency to only the 'debug' version of your module.

    debugImplementation 'com.example.android:app-magic:12.3'
}

Nota: Ya no es posible usar fácilmente el mecanismo anterior para configurar de forma manual la dependencia de la variante, aunque aún exista la Gradle API para esa dependencia. La configuración proporcionada para project() DSL ahora debe coincidir con el consumidor en tipo y clases de compilación (y otros atributos). Por ejemplo, no es posible hacer que una variante 'debug' consuma una variante 'release' con este mecanismo, ya que el productor y el consumidor no coincidirían. (En este caso, el nombre 'debug' hace referencia al objeto de configuración publicado que se mencionó anteriormente en la sección Publicación de dependencias). Ahora que se publican dos configuraciones, una para la compilación y otra para el tiempo de ejecución, la forma antigua de selección de una configuración ya no funciona.

Configurar dependencias de app para Wear

A fin de admitir la resolución de dependencias con reconocimiento de variantes para apps para Wear integradas, en el complemento 3.0.0 ahora se combinan todos los gráficos antes de su resolución, procedimiento similar al que se emplea para el manejo de otras dependencias. En versiones anteriores del complemento, los gráficos de la dependencia<component>WearApp se resolvían por separado. Por lo tanto, por ejemplo, podrías hacer algo como lo siguiente, y las variantes azules usarían :wear2 y todas las demás variantes usarían :wear1:

dependencies {
    // This is the old way of configuring Wear App dependencies.
    wearApp project(':wear1')
    blueWearApp project(':wear2')
}

La configuración anterior ya no funciona con el complemento nuevo. No obstante, si tu módulo wearable configura los mismos tipos que tu app principal, no necesitas usar la configuración <flavor>WearApp. Simplemente, especifica la configuración wearApp. Cada variante de la app principal consumirá la variante coincidente de wearable:

dependencies {
    // If the main app and wearable modules have the same flavors,
    // the following configuration uses automatic dependency matching.
    wearApp  project(':wearable')
}

Si deseas especificar un módulo diferente de la app para Wear según el tipo de app, aún puedes usar la configuración <flavor>WearApp de la siguiente manera (no obstante, no puedes combinarla con la configuración wearApp):

dependencies {
    redWearApp project(':wear1')
    greenWearApp project(':wear1')
    blueWearApp project(':wear2')
}

Usar las nuevas configuraciones de dependencias

Gradle 3.4 introdujo nuevas configuraciones para el complemento de la biblioteca Java que te permiten controlar la publicación para las classpaths compile y runtime (para dependencias internas del módulo). En el complemento de Android 3.0.0, se está produciendo una migración a estas nuevas configuraciones de dependencias. Para migrar tu proyecto, simplemente actualiza tus dependencias a fin de que usen las configuraciones nuevas en lugar de las obsoletas, como se indica en la siguiente tabla.

Configuración nueva Configuración obsoleta Comportamiento
implementation compile La dependencia está disponible en el momento de la compilación para el módulo y solo en el tiempo de ejecución para el consumidor del módulo. Para compilaciones grandes que abarcan varios proyectos, el uso de implementation en lugar de api o compile puede generar mejoras importantes en el tiempo de compilación, ya que reduce la cantidad de proyectos que el sistema de compilación debe volver a compilar. La mayoría de los módulos de apps y de prueba deben usar esta configuración.
api compile La dependencia está disponible para el módulo en el momento de la compilación, y también está disponible para el consumidor del módulo en el momento de la compilación y en el tiempo de ejecución. Esta configuración tiene el mismo comportamiento que compile (que ahora es obsoleta) y normalmente deberías usarla solo en los módulos de la biblioteca. Los módulos de la app deben usar implementation, a menos que desees exponer su API a otro módulo de prueba.
compileOnly provided La dependencia está disponible para el módulo solo en el momento de la compilación; no está disponible para sus consumidores en el momento de la compilación ni en el tiempo de ejecución. Esta configuración se comporta como provided (que ya es obsoleta).
runtimeOnly apk La dependencia está disponible para el módulo y sus consumidores solo en el tiempo de ejecución. Esta configuración se comporta como apk (que ya es obsoleta).

Como en el caso de las versiones estables actuales del complemento de Android, las configuraciones anteriores están disponibles para dependencias de clases o tipos de compilación específicas. Por ejemplo, puedes usar api para que la dependencia esté disponible para todas las variantes, o bien redApi para que esté disponible únicamente para las variantes red del módulo.

Nota: compile, provided y apk siguen estando disponibles. Sin embargo, desaparecerán en la próxima versión importante del complemento de Android.

Publicar dependencias

Las siguientes configuraciones contienen las dependencias transitivas de una biblioteca para que puedan utilizarlas sus consumidores:

  • <variant>ApiElements
  • <variant>RuntimeElements

Antes existía una sola configuración por variante llamada: <variant>. Debido a que una biblioteca ahora puede controlar lo que ven los consumidores para la compilación usando las configuraciones implementation y api descritas en la sección anterior, ahora hay dos configuraciones: una para la compilación del consumidor y una para el tiempo de ejecución.

Para obtener más información sobre las relaciones entre las diferentes configuraciones, dirígete a la configuración del complemento de la biblioteca Java.

Migrar estrategias de resolución de dependencias personalizadas

El complemento usa las siguientes configuraciones para resolver todas las dependencias de una variante:

  • <variant>CompileClasspath (_<variant>Compile ya no funciona)
  • <variant>RuntimeClasspath (_<variant>Apk ya no funciona)

Si todavía usas las configuraciones anteriores, verás un error de compilación similar al siguiente:

Error:Configuration with old name _debugCompile found.
Use new name debugCompileClasspath instead.

Los complementos o los archivos de compilación que establecen una estrategia de resolución en la configuración resuelta deberán adaptarse al nombre nuevo. Debido a la demora en la resolución de dependencias, ahora es posible configurar la estrategia de resolución mientras usas la API de la variante, como se muestra en el siguiente ejemplo. (El complemento de Android ahora incluye métodos de obtención para acceder a los objetos de configuración de una variante).

// Previously, you had to apply a custom resolution strategy during the
// configuration phase, rather than in the execution phase. That's
// because, by the time the variant was created and the Variant API was
// called, the dependencies were already resolved. This no longer works, and
// you should use this method only while using an older version of the plugin.
// configurations {
//     _debugCompile
//     _debugApk
// }
// ...
//
// configurations._debugCompile.resolutionStrategy {
//     ...
// }
//
// configurations.all {
//     resolutionStrategy {
//     ...
//     }
// }

// Because the new build model delays dependency resolution, you should
// query and modify the resolution strategy using the Variant API.
android {
    applicationVariants.all { variant ->
        variant.getCompileConfiguration().resolutionStrategy {
            ...
        }
        variant.runtimeConfiguration.resolutionStrategy {
            ...
        }
        variant.getAnnotationProcessorConfiguration().resolutionStrategy {
            ...
        }
    }
}

Nota: El nuevo complemento ahora busca configuraciones usando el nombre anterior y experimenta errores si las encuentra. También podría ignorar de forma silenciosa la estrategia de resolución personalizada. Podemos cambiar esto en base a comentarios, pero quisiéramos encontrar una manera de facilitar la migración.

Usar la configuración de dependencias del procesador de anotaciones

En versiones anteriores del complemento de Android para Gradle, las dependencias de la classpath de compilación se agregaban automáticamente a la classpath del procesador. Es decir, se podía agregar un procesador de anotaciones a la classpath de compilación y funcionaba de la forma prevista. No obstante, esto afecta notablemente el rendimiento al agregar una gran cantidad de dependencias innecesarias al procesador.

Con el nuevo complemento, los procesadores de anotaciones se deben agregar a la classpath del procesador usando la configuración de dependencia annotationProcessor, como se muestra a continuación:

dependencies {
    ...
    annotationProcessor 'com.google.dagger:dagger-compiler:<version-number>'
}

El complemento prevé que una dependencia es un procesador de anotaciones si su archivo JAR contiene el siguiente archivo: META- INF/services/javax.annotation.processing.Processor. Si el complemento detecta procesadores de anotaciones en la classpath de compilación, tu compilación fallará y verás un mensaje de error en el que figurará cada procesador de anotaciones en la classpath de compilación. Para solucionar el error, simplemente cambia la configuración de esas dependencias para que usen annotationProcessor. Si una dependencia incluye componentes que también deben estar en la classpath de compilación, declara esa dependencia por segunda vez y usa la configuración de dependencias compile.

Usuarios del complemento android-apt: este cambio en el comportamiento actualmente no tiene efecto en el complemento android-apt. No obstante, el complemento no será compatible con versiones futuras del complemento de Android para Gradle.

Inhabilitar la comprobación de errores

Si tienes dependencias en la classpath de compilación que incluyen procesadores de anotaciones que no necesitas, puedes inhabilitar la comprobación de errores agregando lo siguiente a tu archivo build.gradle. Recuerda que los procesadores de anotaciones que agregues a la classpath de compilación todavía no se agregaron a la classpath del procesador.

android {
    ...
    defaultConfig {
        ...
        javaCompileOptions {
            annotationProcessorOptions {
                includeCompileClasspath false
            }
        }
    }
}

Si tienes problemas para realizar la migración a una nueva estrategia de resolución de dependencias, puedes restaurar el comportamiento de modo que sea el del complemento de Android 2.3 configurando includeCompileClasspath true. Sin embargo, no se recomienda restaurar el comportamiento a la versión 2.3 y la opción para hacerlo se eliminará en una actualización futura. Para ayudarnos a mejorar la compatibilidad con las dependencias que estás usando, informa un error.

Usar módulos de prueba independientes

Los módulos de prueba independientes ahora reconocen variantes (consulta la sección anterior) cuando usan el complemento 3.0.0. Esto significa que ya no es necesario especificar targetVariant.

Cada variante del módulo de prueba intentará probar una variante coincidente en el proyecto de destino. De forma predeterminada, los módulos de prueba contienen solo una variante debug, pero puedes crear clases y tipos de compilación nuevos a fin de producir nuevas variantes para que coincidan con el proyecto de app sometido a prueba. Se crea una tarea connectedCheck para cada variante.

Para que el proyecto Test solo pruebe un tipo de compilación diferente, y no el de depuración, usa VariantFilter para inhabilitar la variante debug en el proyecto de prueba, como se muestra a continuación:

android {
    variantFilter { variant ->
        if (variant.buildType.name.equals('debug') {
            variant.setIgnore(true);
        }
    }
}

Si deseas que un módulo de prueba apunte solo a determinadas variantes de tipos de una app, puedes usar las propiedades flavorSelection para los tipos que quieras probar. Esto también evita que el módulo de prueba deba configurar esos tipos por sí mismo.

Archivos JAR locales en bibliotecas

Antes, los módulos de las bibliotecas controlaban dependencias en JAR locales de forma no estándar y las empaquetaban en su AAR. Incluso en una compilación con varios proyectos, los consumidores de AAR verían esos archivos JAR a través de la versión empaquetada.

El complemento de Android 3.0.0 y las versiones posteriores ahora usan Gradle API para permitir que los proyectos de consumo detecten los archivos JAR locales como dependencias transitivas regulares, caso similar al de las dependencias basadas en coordenadas de Maven. Para adaptarse a las nuevas Gradle API, debieron cambiar algunos aspectos vinculados a la forma en que el complemento controla los archivos JAR locales.

Publicación dentro del proyecto

  • Los módulos de la biblioteca ya no procesan archivos JAR locales. Esto tiene como objetivo acelerar las compilaciones incrementales producidas por cambios en el código de un módulo de la biblioteca.

  • Las transformaciones en los módulos de la biblioteca ahora pueden afectar solo el alcance de PROJECT. Si aplicas transformaciones usando PROJECT_LOCAL_DEPS, se producirá una falla, ya que este alcance ahora es obsoleto.

  • Para los módulos de la app cuyos archivos JAR locales formen parte de la transmisión EXTERNAL, las transmisiones PROJECT_LOCAL_DEPS y SUB_PROJECT_LOCAL_DEPS ahora estarán siempre vacías.

  • La habilitación de ProGuard para módulos de una biblioteca local ya no afecta el código de la biblioteca. En lugar de ello, debes ejecutar ProGuard en el módulo final de la app.

  • Antes, los conflictos de recursos Java entre el módulo de una biblioteca y sus dependencias JAR locales debían resolverse en el módulo de la biblioteca. Debido a que el módulo de la biblioteca ya no procesa los JAR locales, el conflicto debe resolverse en la aplicación que consume la biblioteca.

Publicación en el repositorio de Maven

  • Nada ha cambiado con respecto a la publicación en un repositorio de Maven. Los JAR locales se agrupan y sus recursos sin clase se combinan en el archivo JAR principal del archivo AAR. Si el módulo habilita ProGuard, todos los archivos JAR se combinan en el archivo JAR principal.

Cambios de API

En el complemento de Android 3.0.0 se introducen cambios en la API que eliminan ciertas funcionalidades y pueden afectar tus compilaciones existentes. En las versiones posteriores del complemento podrían introducirse nuevas API públicas que reemplacen las funcionalidades afectadas.

Resultados de variantes

No es posible usar la Variant API para manipular resultados de variantes con el nuevo complemento. Aún funciona para tareas simples, como modificar el nombre del APK durante el momento de la compilación, como se muestra a continuación:

// If you use each() to iterate through the variant objects,
// you need to start using all(). That's because each() iterates
// through only the objects that already exist during configuration time—
// but those object don't exist at configuration time with the new model.
// However, all() adapts to the new model by picking up object as they are
// added during execution.
android.applicationVariants.all { variant ->
    variant.outputs.all {
        outputFileName = "${variant.name}-${variant.versionName}.apk"
    }
}

No obstante, las tareas más complicadas que incluyen el acceso a objetos outputFile ya no funcionan. Esto se debe a que ya no se crean tareas específicas de las variantes durante la etapa de configuración. Como resultado, el complemento no reconoce todos sus resultados de antemano, pero también se reducen los tiempos de configuración.

manifestOutputFile

El método processManifest.manifestOutputFile() ya no está disponible; cuando intentes llamarlo, verás el siguiente error:

A problem occurred configuring project ':myapp'.
   Could not get unknown property 'manifestOutputFile' for task ':myapp:processDebugManifest'
   of type com.android.build.gradle.tasks.ProcessManifest.

En lugar de llamar a manifestOutputFile() para obtener el archivo de manifest para cada variante, puedes llamar a processManifest.manifestOutputDirectory() para que muestre la ruta de acceso del directorio que contiene todos los manifest generados. Luego puedes localizar un manifest y aplicarle tu lógica. En el ejemplo siguiente se cambia de forma dinámica el código de la versión en el manifest:

android.applicationVariants.all { variant ->
    variant.outputs.all { output ->
        output.processManifest.doLast {
            // Stores the path to the maifest.
            String manifestPath = "$manifestOutputDirectory/AndroidManifest.xml"
            // Stores the contents of the manifest.
            def manifestContent = file(manifestPath).getText()
            // Changes the version code in the stored text.
            manifestContent = manifestContent.replace('android:versionCode="1"',
                    String.format('android:versionCode="%s"', generatedCode))
            // Overwrites the manifest with the new text.
            file(manifestPath).write(manifestContent)
        }
    }
}