Repository navigation
Allow plugins to not support Android #39657
Description
Activity
This makes sense. @amirh's proposal: "Distributed Platform Ownership for Flutter Plugins" touches on this--we could start by listing the platforms in the plugin's pubspec file. I saw you made some comments in the doc, is there general agreement around that (pubspec schema at least)?
we could start by listing the platforms in the plugin's pubspec file
#38632 already added support for that. This bug is specifically about making the right thing happen when you don't list Android there, which currently isn't the case.
oh excellent. I wasn't aware of that.
We might still need
.flutter-pluginsthough, but maybe we can split it by platform? Ootherwise, we need to pass the plugin list to Gradle as an argument, but that breaks add to app scenarios where the host app is built from Android Studio instead of the Flutter tool.We might still need .flutter-plugins though, but maybe we can split it by platform?
That's what I meant by "new platform-specific versions". (iOS and macOS would also benefit from having such files.)
So I guess the plan is to split
.flutter-pluginsinto multiple.flutter-plugins-<platform>files. It sounds like we will need to implement auto-migration for for the gradle/xcode stuff (e.g the tool will update existing settings.gradle to refer to.flutter-plugins-android).Any thoughts? better options?
We don't necessary have to migrate; we could keep making
.flutter-pluginsfor all existing projects, and tell people who want to start using plugins that don't support all of their project's platforms to manually delete the appropriate files (e.g., Podspec) and rebuild so it would generate a new version.Not ideal, but possible.
I think there are a few independent pieces of work here.
One would be for all of the tooling to gracefully handle a missing plugin implementation. This would at least unblock work in the short-term even it isn't the final strategy.
Separately, rather than create N
.flutter-plugins-platformfiles I think we should update the tooling to look in the platform projects' ephemeral/output directory and then fall back to the project root. We can output platform specific .flutter-plugins in these directories without breaking any current workflows.Once that is done, we can evaluate the cost of removing the project root plugins
One would be for all of the tooling to gracefully handle a missing plugin implementation. This would at least unblock work in the short-term even it isn't the final strategy.
@jonahwilliams can you sketch how you envision that? (to make sure we're all on the same page)
In the android case, it would mean updating
flutter.gradleto check for the correct files before creating a plugin task here:https://github.com/flutter/flutter/blob/master/packages/flutter_tools/gradle/flutter.gradle#L250
Maybe it should print an error or warning, but definitely not crash.
In the android case, it would mean updating flutter.gradle to check for the correct files before creating a plugin task here:
This also requires changes to
android/settings.gradlesince the plugins are still included as subprojects in app projects.Separately, rather than create N .flutter-plugins-platform files I think we should update the tooling to look in the platform projects' ephemeral/output directory and then fall back to the project root.
@jonahwilliams This sounds good too. Do you plan to change
flutter createso that it takes the list of target platforms as an argument?@jonahwilliams This sounds good too. Do you plan to change flutter create so that it takes the list of target platforms as an argument?
.flutter-plugins is not a part of flutter create.
This also requires changes to android/settings.gradle since the plugins are still included as subprojects in app projects.
Ahh yes, that's unfortunate. I would suggest @stuartmorgan's plan then
I prototyped excluding plugins without an
android/build.gradlefile from the list of plugins we're building in amirh@bdcf4c5. It seem to work, though I know very little about Gradle so am likely missing something. @blasten what should I expect to break if I didn't change anything inandroid/settings.gradle?Also - do we have a reasonable harness to test such a thing?
4 remaining items
Echoing my comment from the iOS bug: what's the advantage of doing this?
I see this as a general tool hardening, we shouldn't crash if files/folders are missing in easily anticipated ways. The fact that it unblocks some work temporarily is just a side effect.
Generating these platform-specific files in Dart should be trivial given that we already have all the code for filtering plugins by platform
I agree, it's not much more difficult- we should do that also.
Echoing my comment from the iOS bug: what's the advantage of doing this? This is the same file we'd need to change to point it to a different, Android-specific
.flutter-pluginsfile, so this is doing more throw-away work with no benefit that I can see. Generating these platform-specific files in Dart should be trivial given that we already have all the code for filtering plugins by platform, including handling of fallbacks depending on whether or not plugins are using the new or old schema. And if we do that once, we can do iOS and Android the way we want to support long term right now, without an intermediate step.I'm not sure how simple and/or reliable can the auto migration of existing apps'
settings.gradlebe (which currently points to `.flutter-plugins), without that migration we need something like the current patch.Oh, I missed that this is a file that's part of Flutter itself, not the project. I was assuming it would be similar to iOS, where the file is generated into the project and then left there, requiring some kind of update (migrated or manual). If we can retroactively fix all existing projects to handle this gracefully I definitely understand why it's worth doing.
I started playing around with generating platform-specific plugin files; WIP here. It's totally untested (even manually), and we'd need to figure out if those are the right file locations on mobile, but I think that's basically the right structure.
Then we can incrementally work on removing all internal use of
.flutter-plugins, except for continuing to write it for existing projects until/unless we migrate them.I'm not sure when I'll have time to continue with that so if someone wants to take that and turn it into a real PR please feel free.
@franciscojma86 Will this also be fixed by #47258?
@jmagman That's an obsolete PR for now. The JSON logic has already landed. The migration part will be discussed here , which might depend on the decisions taken in this proposal
@franciscojma86 Can this issue be closed? Or is there more work to track here?
We still need no-op implementations for plugins, so we can't close this yet. We will close after we migrate the templates.
Reacted by David IglesiasThis is great! Does this mean we can remove the noop
androiddirectories from plugin packages?This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.- locked and limited conversation to collaborators
on Apr 25, 2020
#10288 added a formal way to allow plugins to indicate which platforms they support, but any plugin that doesn't support Android (as in, has no
android/folder) will cause Gradle failures. It looks from initial investigation like this is becauseflutter.gradleuses.flutter-plugins, which isn't platform-specific and thus isn't subject to platform filtering.Presumably we should move away from having a single
.flutter-pluginsat all, and migrate all current clients to new platform-specific versions.Currently the only way to make, say, a desktop-specific plugin that doesn't break Android is with a dummy directory.