Users are hitting Gradle failures when upgrading Flutter to v1.12.13+hotfix.5 #46898
Description
There are multiple reports of users hitting Gradle failures following the upgrade (#46807, #46753, #46790).
The root cause is that we've added platform specific plugin packages for web and macos with no android/ folders as dependencies of popular plugins (url_launcher, google_sign_in, video_player, firebase_auth, and firebase_core).
Flutter's Android build configuration used to assume that every plugin has a buildable android/ folder. We have landed #40640 #46282 to mitigate this problem however there are still 2 classes of issues:
Cached build artifact
It's not clear to me exactly what, but it seems like right after upgrading flutter, the build system still tries to look for the buildable android/ folder (e.g #46282 does not take immediate effect), and users have to delete some locally cached state before it takes affect. It's unclear to me what cached state exactly matters, some users report that deleting pubspec.lock and running flutter clean solved the issue, and some report that they had to clean their .pub-cache folder.
This is a nuisance for many users who upgrade flutter and try to build their existing app. We should better understand which cached state is causing the problem and figure out how to mitigate. @blasten @jonahwilliams do you have any insights?
The aar build strategy
Flutter has a fallback build strategy to mitigate AndroidX issues, if the Android build fails Flutter may try a secondary build strategy which involves building each plugin as AAR, and then building the app. This aar build strategy was not updated to support non-Android plugins, and is failing when the project has a non-Android plugin dependency.
Note that this scenario is expected to be less common, it will fail for applications where the initial build fails due to an AndroidX failure and also have a non-Android plugin dependency.
@blasten has sent out #46835 to mitigate that issue, however it's yet clear if that fix qualifies for a hotfix.
Temporary mitigation in plugins code
One temporary mitigation which should address both issues would be to add a no-op android/ folder to all plugins, until there's a new stable release that addresses both issues. I suggest we start adding these to packages of the plugins mentioned above as a temporary remedy. Once the issues above are solved on stable we can clean these up.