Repository navigation
Conversation
This is a very rough proof of concept. It functions on simple app cases given manual tweaking. It basically works by adding extra logic to `gradle.dart` before the APK of an app is compiled. - Get a flat list of all transitive Flutter plugin dependencies. - Run an `init-script` on each one to add the local `flutter-jar` as a `compileOnly` dependency to it. - Compile each dependency as an AAR. - Use the plugin AARs as dependencies for compiling the APK in the `flutter.gradle` plugin. There's two big blockers on this still that I'm currently aware of. 1. This requires apps to manually remove the `subprojects` declarations from `android/build.gradle` and the `plugins.each` loop from `android/settings.gradle`. It's both breaking and requiring manual intervention on the app side to work. 2. Transitive gradle dependencies within our Flutter plugins cause crashes at runtime, since the inner deps aren't being included in the aar. To see a failing case, use this code with a sample app requiring `firebase_auth`. At runtime it will crash because the firebase library isn't found.
| } else { | ||
| project.logger.error("Plugin project :$name not found. Please update settings.gradle.") | ||
| // TODO(mklim): This replacement currently requires apps to remove their | ||
| // `subproject {}` declarations or else break. If we're going to |
There was a problem hiding this comment.
Can we do that programatically in gradle.dart?
| // instead. | ||
| plugins.each { name, path -> | ||
| def String artifactDir = Paths.get(path, 'android', 'build', 'outputs', 'aar').toString(); | ||
| def Set<File> aars = project.fileTree(dir: artifactDir, include: '*.aar').getFiles(); |
There was a problem hiding this comment.
How about just compile project.fileTree(dir: artifactDir, include: '*.aar')?
And is compile right here or api?
|
|
||
| // TODO(mklim): Fix the obvious bugs. | ||
| // - Do we need logic for passing along build architecture, local engine, etc? | ||
| // - Make this smart enough to not rebuild the plugin every time? |
There was a problem hiding this comment.
Shouldn't gradle take care of that?
I'd time how long that takes, and if it's more than a few ms then we should just be able to check for the build output ourselves.
| } | ||
|
|
||
| // TODO(mklim): Fix the obvious bugs. | ||
| // - Do we need logic for passing along build architecture, local engine, etc? |
There was a problem hiding this comment.
Yes, we really should support that.
That said, I'm not sure the plugins actually need libflutter.so - while it's probably possible for some plugin to try to use JNI on that, I think it's probably very uncommon and we're safer to break that (totally a gut sense though, I have no hard data). This is where it'd be nice to just have a set of interfaces the engine exposes in a lighter weight JAR that plugins could use.
| bool isBuildingBundle, | ||
| ) async { | ||
| // TODO(mklim): This is breaking, should fix the incompatibility or only case | ||
| // into this for migrated apps (_buildGradleProjectV3)? |
There was a problem hiding this comment.
I think we probably want this to be considered a new type of project, and we should offer some kind of auto-migration for it (e.g. removing any flutter/plugin related subproject nodes).
|
|
goderbauer
added
the
tool
|
This work is being continued in #29849 |
4 participants
Description
This is a very rough proof of concept. It functions on simple app cases
given manual tweaking.
It basically works by adding extra logic to
gradle.dartbefore the APKof an app is compiled.
init-scripton each one to add the localflutter-jaras acompileOnlydependency to it.flutter.gradleplugin.There's two big blockers on this still that I'm currently aware of.
subprojectsdeclarationsfrom
android/build.gradleand theplugins.eachloop fromandroid/settings.gradle. It's both breaking and requiring manualintervention on the app side to work.
crashes at runtime, since the inner deps aren't being included in the
aar. To see a failing case, use this code with a sample app requiring
firebase_auth. At runtime it will crash because the firebaselibrary isn't found.
Related Issues
#29328
Checklist
Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes (
[x]). This will ensure a smooth and quick review process.///).flutter analyze --flutter-repo) does not report any problems on my PR.Breaking Change
Does your PR require Flutter developers to manually update their apps to accommodate your change?
(This is a WIP. It shouldn't be merged until there's tests, it's no longer a breaking change, etc.)