[many] More v1 embedding deletion that was missed in https://github.com/flutter/packages/pull/6494

[gmackall]

There were some additional v1 Android embedding references missed by #6494.

This PR aims to remove those missed references.

I built the android example app of each plugin affected here on the deletion branch to be completely sure:

• video_player
• google_sign_in (builds, but only with the fixes to espresso applied).
• espresso
• in_app_purchase
• image_picker (builds, but only with the fixes to both espresso and video_player applied)

Final testing, I tested that the all_packages app builds on the v1 embedding deletion branch:

$ ./.ci/scripts/create_all_packages_app.sh && cd all_packages
...
$ flutter build apk --debug --local-engine-src-path=/Users/mackall/development/engine/src --local-engine=android_debug_arm64 --local-engine-host=host_debug

Running Gradle task 'assembleDebug'...                              4.8s
✓ Built build/app/outputs/flutter-apk/app-debug.apk

🎉

Linux repo checks are failing

The following packages had errors:
  packages/google_maps_flutter/google_maps_flutter:
    Missing CHANGELOG change
  packages/palette_generator:
    Missing CHANGELOG change
  packages/quick_actions/quick_actions:
    Missing CHANGELOG change
  packages/webview_flutter/webview_flutter:
    Missing CHANGELOG change

The only changes to these packages are xml changes to example apps which won't cause build failures even when the v1 embedding is deleted (they will just be unused). So I believe these changes should be version exempt.

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.

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

[gmackall]

cc @stuartmorgan for a versioning question (no rush) - In a PR like this, where a fix to google_sign_in depends on a fix to espresso, will I need to land the fix to the latter first, and then put up a follow up PR to fix the former?

[gmackall]

• If google_sign_in's tests now actually require a higher version of espresso to successfully run, then that should be expressed in pubspec.yaml, which will require the espresso change to be published first.

It will require a newer espresso version to run when flutter/engine#52022 lands, but does not at this time

[gmackall]

• If google_sign_in's tests now actually require a higher version of espresso to successfully run, then that should be expressed in pubspec.yaml, which will require the espresso change to be published first.

It will require a newer espresso version to run when flutter/engine#52022 lands, but does not at this time

I believe this means it should be safe to land in the same PR

Also, separately from the versioning question would also appreciate your review, when you have a chance @stuartmorgan (not a rush just a clarification that the review request wasn't only for versioning question 🙂 )

[stuartmorgan]

I believe this means it should be safe to land in the same PR

Agreed, I don't expect any issue given that. And if it weren't safe, I would expect presubmits to fail, since the native tests in CI are not using path-based deps.

[stuartmorgan]

LGTM modulo making format happy.

[stuartmorgan]

Overriding CHANGELOG check: the manifest XML changes are not interesting to clients, so don't need to be mentioned.