Gestionar plugins y dependencias en add-to-app

Esta guía describe cómo configurar tu proyecto para consumir plugins y cómo gestionar tus dependencias de biblioteca de Gradle entre tu aplicación Android existente y los plugins de tu módulo Flutter.

En los casos simples:

• Tu módulo Flutter utiliza un plugin que no tiene ninguna dependencia adicional de Gradle en Android porque solo utiliza APIs del sistema operativo Android, como el plugin de la cámara.
• Tu módulo Flutter utiliza un plugin que tiene una dependencia de Gradle en Android, como ExoPlayer del plugin video_player, pero tu aplicación Android existente no dependía de ExoPlayer.

No se requieren pasos adicionales. Tu módulo add-to-app funcionará de la misma manera que una aplicación Flutter completa. Ya sea que integres usando Android Studio, un subproyecto de Gradle o archivos AAR, las bibliotecas transitivas de Gradle en Android se empaquetan automáticamente según sea necesario en tu aplicación externa existente.

Algunos plugins requieren que realices algunas modificaciones en la parte de Android de tu proyecto.

Por ejemplo, las instrucciones de integración para el plugin firebase_crashlytics requieren modificaciones manuales en el archivo build.gradle de tu proyecto contenedor de Android.

Para aplicaciones de Flutter completas, estas modificaciones se realizan en el directorio /android/ de tu proyecto Flutter.

En el caso de un módulo Flutter, solo hay archivos Dart en tu proyecto de módulo. Realiza esas modificaciones del archivo de Gradle de Android en tu aplicación Android externa existente en lugar de en tu módulo Flutter.

El escenario que requiere un poco más de atención es si tu aplicación Android existente ya depende de la misma biblioteca de Android de la que depende tu módulo Flutter (de forma transitiva a través de un plugin).

Por ejemplo, el Gradle de tu aplicación existente ya podría tener:

…
dependencies {
    …
    implementation("com.crashlytics.sdk.android:crashlytics:2.10.1")
    …
}
…

…
dependencies {
    …
    implementation "com.crashlytics.sdk.android:crashlytics:2.10.1"
    …
}
…

Y tu módulo Flutter también depende de firebase_crashlytics a través de pubspec.yaml:

…
dependencies:
  …
  firebase_crashlytics: ^0.1.3
  …
…

Este uso del plugin añade de forma transitiva una dependencia de Gradle nuevamente a través del propio archivo Gradle de firebase_crashlytics v0.1.3:

…
dependencies {
    …
    implementation "com.crashlytics.sdk.android:crashlytics:2.9.9"
    …
}
…

Es posible que las dos dependencias com.crashlytics.sdk.android:crashlytics no sean de la misma versión. En este ejemplo, la aplicación anfitriona solicitó la v2.10.1 y el plugin del módulo Flutter solicitó la v2.9.9.

Por defecto, Gradle v5 resuelve los conflictos de versiones de dependencias utilizando la versión más reciente de la biblioteca.

Por lo general, esto está bien siempre y cuando no haya cambios disruptivos en la API o en la implementación entre las versiones. Por ejemplo, podrías usar la nueva biblioteca de Crashlytics en tu aplicación existente de la siguiente manera:

…
dependencies {
    …
    implementation("com.crashlytics.sdk.android:crashlytics:2.10.1")
    …
}
…

…
dependencies {
    …
    implementation "com.google.firebase:firebase-crashlytics:17.0.0-beta03"
    …
}
…

Este enfoque no funcionará ya que existen diferencias importantes en la API entre las versiones de la biblioteca Gradle de Crashlytics v17.0.0-beta03 y v2.9.9.

Para las bibliotecas de Gradle que siguen el versionado semántico, generalmente puedes evitar errores de compilación y de tiempo de ejecución utilizando la misma versión semántica principal en tu aplicación existente y en el plugin del módulo Flutter.