[flutter_plugin_android_lifecycle] use flutter.compileSdkVersion to see what breaks

[reidbaker]

Related to flutter/flutter/issues/149836

The entire repo uses compile sdk 34 so this a change to 35 but tooling changes are supposed to be safe. Aditionally most projects uses flutter.targetSdkVersion which means that they are using tools at api 34 but targeting 35 which is not ok.

This pr is a canary to see if any unexpected issues pop up and to validate that we agree on if a version/changelog change is required. The second part will update this for all plugins.

Pre-launch Checklist

• I read the [Contributor Guide] and followed the process outlined there for submitting PRs.
• I read the [Tree Hygiene] page, which explains my responsibilities.
• I read and followed the [relevant style guides] and ran the auto-formatter. (Unlike the flutter/flutter repo, the flutter/packages repo does use dart format.)
• I signed the [CLA].
• The title of the PR starts with the name of the package surrounded by square brackets, e.g. [shared_preferences]
• I [linked to at least one issue that this PR fixes] in the description above.
• I updated pubspec.yaml with an appropriate new version according to the [pub versioning philosophy], or this PR is [exempt from version changes].
• I updated CHANGELOG.md to add a description of the change, [following repository CHANGELOG style], or this PR is [exempt from CHANGELOG changes].
• 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].
• All existing and new tests are passing.

[flutter-dashboard]

It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption, contact "@test-exemption-reviewer" in the #hackers channel in Discord (don't just cc them here, they won't see it!).

If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix?

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing. The test exemption team is a small volunteer group, so all reviewers should feel empowered to ask for tests, without delegating that responsibility entirely to the test exemption group.

[reidbaker]

test-exempt: Passing builds are the only signal that this is ok to land.

[stuartmorgan-g]

I can never remember, does this value affect plugin clients? Is this the one that is documented not to, but sometimes actually does? (And did we ever get a doc written up about this?)

If it does, this seems dangerous, because people running with a new version of Flutter would get a configuration we have never tested.

This also has the downside that if anything breaks in the future due to compileSdk changing, it will break the roller rather than break an Android-specific PR that bumps the SDKs. That seems like it'll be much more difficult to deal with (and debug the cause of).

[reidbaker]

can never remember, does this value affect plugin clients? Is this the one that is documented not to, but sometimes actually does? (And did we ever get a doc written up about this?)

@gmackall do you remember I am leaning towards yes. I dont remember writing a doc for packages.
I checked https://github.com/flutter/flutter/blob/master/docs/ecosystem/contributing/README.md and dont see any guidance.
I did write Android-API-And-Related-Versions.md very recently and this pr is following that advice.

If it does, this seems dangerous, because people running with a new version of Flutter would get a configuration we have never tested.

In general it is supposed to be safe to update the compileSdkVersion immediately. Additionally if this is unsafe we are already using flutter.targetSdkVersion which is way less safe than bumping tooling.
Assuming I am correct that the non example build.gradle files are shipped to users this is actually helpful in one situation. Plugins that have not been updated in a while have older android sdk versions that must be downloaded at build time because they are used. This change will ensure that for more plugins the android version is already downloaded.
See flutter/flutter#63533 (comment) and flutter/flutter#41462 (comment)

This also has the downside that if anything breaks in the future due to compileSdk changing, it will break the roller rather than break an Android-specific PR that bumps the SDKs. That seems like it'll be much more difficult to deal with (and debug the cause of).

I think you are correct here. The flutter.compile sdk version bump happens once per android sdk release which historically is once per year and we control when flutter.compileSdkVersions changes so it should not be an out of band change.

[stuartmorgan-g]

that must be downloaded at build time because they are used

Ah, right. I think that's what I was thinking of when I had the suspicion that this had surprised us at some point.

So we should version and publish this, as it has client benefits.

The flutter.compile sdk version bump happens once per android sdk release which historically is once per year and we control when flutter.compileSdkVersions changes so it should not be an out of band change.

Right, but moving from "this PR that does nothing but changes X breaks things, so clearly changing X is a problem" to "the roller is broken, and now the gardener has to bisect and try to figure out which underlying PR caused it" is not great.

But since this has client benefits, I think that drawback is warranted; there are a whole lot more of them than us :)

[reidbaker]

that must be downloaded at build time because they are used

Ah, right. I think that's what I was thinking of when I had the suspicion that this had surprised us at some point.

So we should version and publish this, as it has client benefits.

The flutter.compile sdk version bump happens once per android sdk release which historically is once per year and we control when flutter.compileSdkVersions changes so it should not be an out of band change.

Right, but moving from "this PR that does nothing but changes X breaks things, so clearly changing X is a problem" to "the roller is broken, and now the gardener has to bisect and try to figure out which underlying PR caused it" is not great.

But since this has client benefits, I think that drawback is warranted; there are a whole lot more of them than us :)

Ok and for future readers that hit this pain point you can do something like Math.min(35, flutter.compileSdkVersion) for any plugins that are negatively impacted which can allow for a fast resolution of the roll and then let us address the failures one at a time.

[stuartmorgan-g]

LGTM