[various] Scrubs pre-SDK-21 Android code

[stuartmorgan-g]

• Removes any annotations or runtime checks related to Android API 20 or 21, as 21 is the minimum API version supported by the versions of Flutter these plugins support.
• Removes comment/README references to limitations for <21.
• Updates READMEs for app-facing packages to reflect the current support levels.

Fixes flutter/flutter#157106

Pre-Review 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.
• 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 I have commented below to indicate which version change exemption this PR falls under¹.
• I updated CHANGELOG.md to add a description of the change, following repository CHANGELOG style, or I have commented below to indicate which CHANGELOG exemption this PR falls under¹.
• I updated/added any relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or I have commented below to indicate which test exemption this PR falls under¹.
• All existing and new tests are passing.

Footnotes

1. Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling. ↩ ↩² ↩³

[reidbaker]

approve % comment about @config with minsdk set.

[reidbaker]

I think the @config annotation should stay and you should use the new minimum.

minSdk= is supposed to run the tests for every version of android after that version.

[stuartmorgan-g]

Maybe I misunderstood @Config. Does it restrict the APIs that this test can be run under, or does it cause the test to be run with multiple API levels? I thought it was the former.

If it's the latter, I'm skeptical we want this. We don't do this pretty much anywhere else in the repo, and I can't think of any reason we would want to multi-run things for the maps SDK in particular, since the SDK isn't system-API-level based.

[reidbaker]

My understanding is it is the latter. Here is some documentation that I think supports that conclusion. https://robolectric.org/configuring/#configure-sdk-level. If you wanted to run on a specific set then you would use sdk = .

Looking through ConvertTest I agree but there are other places in packages where it does make sense to run with a minSdk or other broader android versions set. Primarily to make sure branching logic based on android api gets exercised.

Update: a spot check of all of these google maps test entries shows minimal value in multi api level tests because they do not branch.

[stuartmorgan-g]

I'll go ahead and remove them then; the fact that we only do this for these tests, and these tests don't seem like they benefit, makes me think that adding it was a result of a misunderstanding like mine.

[reidbaker]

same here.

[reidbaker]

and here. Not marking any more but if we agree on @config staying then update all instances.

[stuartmorgan-g]

Version override: updating the min version numbers in the app-facing packages is extremely low priority; it can go out in the next normally-shipped version, since delaying it arbitrarily doesn't matter (some are already years out of date).