Graph [stolen from Barteks
comment](https://github.com/flutter/flutter/pull/161352#issuecomment-2611252732)
documenting the existing (pre pr) state:
```mermaid
graph TD;
flutter.groovy -- import --> native_plugin_loader.groovy;
flutter.groovy -- import --> BaseApplicationNameHandler.kt;
module_plugin_loader.groovy -- "ext" --> native_plugin_loader.groovy;
app_plugin_loader.groovy -- import --> native_plugin_loader.groovy;
include_flutter.groovy -- "apply from: " --> module_plugin_loader.groovy;
```
1. Converts the `app_plugin_loader.groovy` to kotlin source.
2. Converts the `module_plugin_loader.groovy` to kotlin script. This
can't be changed to kotlin source yet, as we will need to instruct users
to make a change to their host app-level gradle files before we can turn
down script application of this separate gradle plugin. This is a
breaking change, and will need a quarter at least of notice.
3. Unfortunately, the main Flutter Gradle plugin depends on being able
to call methods of the `native_plugin_loader`, which we could do in
groovy via wacky dynamic behavior, calling across the compiled
plugin->script plugin barrier. We can't do this in Kotlin source, and we
also can't fully convert `native_plugin_loader` to kotlin source yet
because of (2), so I've added a `NativePluginLoaderReflectionBridge`
that allows us to access the methods in the
`native_plugin_loader.gradle.kts` from the Kotlin source files, calling
across the compiled plugin->script plugin barrier as we were before.
The plan here is
1. to follow up by adding a converted `native_plugin_loader.gradle.kts`
in Kotlin source, and migrating all paths but the host-app using a
module-as-source to use the converted approach (but not deleting the old
way)
2. maintaining both ways for a release or two, with the script
application printing a message notifying users to update to the
non-script based application of the `module_plugin_loader`.
3. Then we can delete the script based apply, and also the reflection
bridge.
## Pre-launch Checklist
- [x] I read the [Contributor Guide] and followed the process outlined
there for submitting PRs.
- [x] I read the [Tree Hygiene] wiki page, which explains my
responsibilities.
- [x] I read and followed the [Flutter Style Guide], including [Features
we expect every widget to implement].
- [x] I signed the [CLA].
- [x] I listed at least one issue that this PR fixes in the description
above.
- [x] I updated/added relevant documentation (doc comments with `///`).
- [ ] I added new tests to check the change I am making, or this PR is
[test-exempt].
- [x] I followed the [breaking change policy] and added [Data Driven
Fixes] where supported.
- [x] All existing and new tests are passing.
If you need help, consider asking for advice on the #hackers-new channel
on [Discord].
<!-- Links -->
[Contributor Guide]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#overview
[Tree Hygiene]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md
[test-exempt]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#tests
[Flutter Style Guide]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Style-guide-for-Flutter-repo.md
[Features we expect every widget to implement]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Style-guide-for-Flutter-repo.md#features-we-expect-every-widget-to-implement
[CLA]: https://cla.developers.google.com/
[flutter/tests]: https://github.com/flutter/tests
[breaking change policy]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#handling-breaking-changes
[Discord]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Chat.md
[Data Driven Fixes]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Data-driven-Fixes.md
---------
Co-authored-by: Gray Mackall <mackall@google.com>
Relands #97823
When the tool migrated to `.flutter-plugins-dependencies`, the Gradle plugin was never changed.
Until now, the plugin had the heuristic that a plugin with a `android/build.gradle` file supported the Android platform.
Also applies schema of `getPluginDependencies` to `getPluginList` which uses a `List` of Object instead of `Properties`.
Fixes#97729
Cause of the error: 5f105a6ca7/packages/flutter_tools/gradle/flutter.gradle (L421C25-L421C25)Fixes#98048
The deprecated line `include ":$name"` in `settings.gradle` (pluginEach) in old projects causes the `project.rootProject.findProject` to also find the plugin "project", so it is not failing on the `afterEvaluate` method. But the plugin shouldn't be included in the first place as it fails with `Could not find method implementation() for arguments` error in special cases.
Related to #48918, see [_writeFlutterPluginsListLegacy](27bc1cf61a/packages/flutter_tools/lib/src/flutter_plugins.dart (L248)).
Co-authored-by: Emmanuel Garcia <egarciad@google.com>
