Allow refinement of any matching source intent.
We believe it's merely a bug that the legacy implementation always
merged the "refinement" into the "primary match" (among those that
matched the selected target -- so it's sort of arbitrary that this
didn't even necessarily have to be the "primary intent" of the chooser
request). Thus we believe the loosened restrictions keep with the
spirit of the original guardrails on refinement -- but this seems to
be a necessary "fix" before the refinement flow could fit its billing
as a mechanism to let users select among alternate formats.
I believe this won't currently work for `SelectableTargetInfo` (i.e.
app share/shortcut targets) which for some reason doesn't seem to keep
track of its "alternates" -- I'll look into that outside of the scope
of this current CL.
Patchset #5 changes:
* Make sure that component name is set for DisplayResolveInfo after a
refinement intent is provided;
* Update MultiDisplayResolveInfo intent refinement logic -- it is now
delegated to a selected target.
Bug: 262805893
Test: `atest IntentResolverUnitTests`
Change-Id: Ie56b14b9a7beaa6bde8fe476d1ff140280abc51a
8 files changed