Add empty io.flutter.app.FlutterApplication to give deprecation notice, and un-break projects that have not migrated

[gmackall]

The removal of the v1 embedding missed that this class was not marked as deprecated, and did not provide a notice in the breaking changes section. V1 apps that needed the functionality of the old FlutterApplication were all broken in the previous release, but some V2 apps have been referencing the v1 FlutterApplication.

For these apps, this is the same as extending the base android.app.Application. So we can provide an "empty extension" of that base class, to provide these v2 apps a deprecation notice, and avoid breaking them without warning (in 3.29.1).

Arbitrarily chose the spell_checker integration test to reference this empty application, let me know if you think I should bring up an entirely new devicelab test instead.

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene wiki page, which explains my responsibilities.
• I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
• I signed the CLA.
• I listed at least one issue that this PR fixes in the description above.
• 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.
• I followed the breaking change policy and added Data Driven Fixes where supported.
• All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

[gmackall]

cc @reidbaker, as well as @loic-sharma and @stuartmorgan for thoughts as you were involved in the discord discussion. Does this seem like a reasonable thing to land and then cherry-pick? It won't help 3.29.0, but could help those that have waited for the next patch to upgrade.

[reidbaker]

cc @reidbaker, as well as @loic-sharma and @stuartmorgan for thoughts as you were involved in the discord discussion. Does this seem like a reasonable thing to land and then cherry-pick? It won't help 3.29.0, but could help those that have waited for the next patch to upgrade.

Why not cherry pick it into 3.29?
https://github.com/flutter/flutter/blob/stable/bin/internal/release-candidate-branch.version

[stuartmorgan-g]

Does this seem like a reasonable thing to land and then cherry-pick?

Seems like a good way to compensate for us having missed the deprecation warning on this.

[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.

[gmackall]

@matanlurey does your approval also count as an exemption re: the bot comment? The comment is wrong (it is tested) but we generally still don't land without exemption

[matanlurey]

@gmackall: Test-exempt, this itself is a test.