Un-pin url_launcher_android in flutter/flutter

[christopherfujino]

PR with broken build tests: https://github.com/flutter/flutter/pull/111197/files#diff-9aeff568c87b1d587222c343afb84ef72fc07e0692d50ecb3de670e5606f9505R46

I believe it is this change: flutter/plugins#6194. Note, something similar happened in #109397 with path_provider_android, and what happened was that the change was reverted upstream and a new version released.

I imagine we will eventually need to find a way to get the migrated versions of these plugins passing flutter/flutter CI.

[christopherfujino]

I will work around this by pinning url_launcher_android so that the pub autoroller can continue

[christopherfujino]

cc @GaryQian and @stuartmorgan

[GaryQian]

These gradle bumps that skip many version have been causing us pain elsewhere as well. It'll take a slow process to eventually get everything upgraded and passing. We should probably just revert for now and hold off on dependabot gradle bumps

[stuartmorgan]

Why are we reverting public packages instead of just pinning in the CI?

[stuartmorgan]

These gradle bumps that skip many version have been causing us pain elsewhere as well. It'll take a slow process to eventually get everything upgraded and passing.

If we keep reverting because of flutter/flutter CI, how will we make progress on this?

Unless we think this will affect clients other that flutter/flutter CI it seems like pinning allows us to make progress for everything else with minimal impact.

[christopherfujino]

These gradle bumps that skip many version have been causing us pain elsewhere as well. It'll take a slow process to eventually get everything upgraded and passing.

If we keep reverting because of flutter/flutter CI, how will we make progress on this?

Unless we think this will affect clients other that flutter/flutter CI it seems like pinning allows us to make progress for everything else with minimal impact.

So I am pinning: #111309. I'm ok with not reverting provided that work on eventually landing the newer versions with the new gradle is prioritized. Eventually a pinned dependency will hold back other packages with shared transitive dependencies from being upgraded.

[stuartmorgan]

Have we root-caused either this or the previous case yet to understand what exactly broke and why? We should definitely prioritize that to make sure we understand client effects and paths forward.

[stuartmorgan]

@GaryQian Could you take a look at what exactly the issue was, so we know what we need to do before making future plugin gradle version changes?

[stuartmorgan]

Re-titling and re-labeling since at this point it looks this is an issue with updating flutter/flutter example projects rather than a problem with the plugin itself.

[flutter-triage-bot]

This issue is marked P1 but has had no recent status updates.

The P1 label indicates high-priority issues that are at the top of the work list. This is the highest priority level a bug can have if it isn't affecting a top-tier customer or breaking the build. Bugs marked P1 are generally actively being worked on unless the assignee is dealing with a P0 bug (or another P1 bug). Issues at this level should be resolved in a matter of months and should have monthly updates on GitHub.

Please consider where this bug really falls in our current priorities, and label it or assign it accordingly. This allows people to have a clearer picture of what work is actually planned. Thanks!

[github-actions]

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 -v and a minimal reproduction of the issue.