Use case

Plugins may have different requirements depending on which version of the embedding they're registered with. See flutter/plugins#2196 for an example. When used with V2 of the Android embedding, the plugin absolutely needs a (relatively recent) bugfix within that embedding to work correctly. However when used with the V1 Android embedding, the plugin's Flutter SDK requirement is much lower since it doesn't need that bugfix.

Right now we don't have a way to programmatically check for and try and assert the higher requirement with the V2 embedding without artificially raising it for all users, because there's no way to know if the user is registering the plugin with the old or new embedding from the pub side where the Flutter version is being checked and no way (that I know of) to get the Flutter version from the Java side where we know which embedding is being used.

Proposal

I have two three rough ideas.

Split the embeddings into separate packages outside of flutter/engine

@dnfield has written up a proposal for this before, at https://flutter.dev/go/android-embedding-move. My (extremely rough) ask here on top of what's in that doc already is to also split V1 and V2 out into separate packages so that plugins could specify which version of each they depend on in their pubspec.yaml, similar to how the Flutter SDK is required as a whole.

I think this is the better solution.

Automatically generate some versioning information in the Java code that's built today

It's technically possible to generate some Java class as part of the build process that has versioning information. It wouldn't be able to save Flutter versioning, since that's defined upstream, but it could generate something with the latest engine hash.

Actually using this in a plugin would be difficult, however. It would mean doing a runtime check on the class and then logging or throwing. The plugin would also need to somehow maintain Flutter and the Engine's Git history in order to know if a particular hash was before or after the "right" Flutter version.

Manually add in some constant and start semantically versioning the v2 embedding where it is today

This is a lot like the above suggestion, where it relies on sketchy runtime checks on the part of the plugin developer. However instead of needing a plugin to know all of Flutter and the Engine's git history and using some generated class, we could start deliberately manually versioning the v2 embedding. I expect this would be prone to catastrophic failures often because it would be extremely hard to realize as an Engine developer that you'd need to increment this random constant if you touched this files. We could maybe add a presubmit check that would error if certain directories were touched and the constant wasn't altered.

Edited to add a third idea

/cc @matthew-carroll @dnfield @blasten @amirh