1)These plugins are for crash reporting, so I don’t need them to be applied all the time (ex: I don’t need them for my daily local builds because I’m not going to track the crash on those builds, they are for development propose, no for sharing or tracking the crashes).
2)One of the benefits of this chance will be reducing the compilation time (because we need Gradle to apply these plugin), among others.
I just want to apply one of those crash reporting (not both).
Said that, I think I would be useful in some cases to be able to have the chance to apply plugin just for some build types.
A plugin really is a project-scoped concept. A project either has it or not.
But the plugin should allow you to configure it at a finer grained level. For instance, the crash reporting plugin you mentioned should allow you to specify which buildTypes it should apply to. I guess it would be best to get in touch with the maintainers of those plugins. Maybe they already have an option for that.
Execution failed for task: ':app:processCurrentDebugGoogleServices'.
> Please fix the version conflict either by updating the version of the google-services plugin (information about the latest version is available at https://bintray.com/android/android-tools/com.google.gms.google-services/) or updating the version of com.google.android.gms to 10.2.6.
If I understand correctly, this may be an issue with the com.google.gms.google-services plugin, but I would really like to get this working, because my app needs to support ridiculously old versions of Android.
Plug-ins may be a project-level concept, but why? Downloading application of the plug-in based on build type to the plug-in itself doesn’t make any sense considering that Gradle itself is a build configuration tool .
What is the reasoning against letting build.gradle decide when plug-ins are applied?