Copy all source intents to SelectableTargetInfo

The SelectableTargetInfo subtype was originally introduced to
represent results from the (now-deprecated) ChooserTargetService
system. Purely for legacy reasons, we now use instances of this type
to represent direct/shortcut targets (as well as a caller's custom
chooser targets; OTOH the original ChooserTargetService support has
been fully removed).

For direct/shortcut targets, we match the target against the
DisplayResolveInfo target that represented the corresponding component
in our earlier intent-resolution ("all-app") results. The
DisplayResolveInfo record also contains all of the resolved
alternates, so we can copy them over directly to support the
refinement flow. Previously, we copied over only the first (for
reasons that I believe now to be obsolete).

Two considerations are deliberately left out-of-scope in this CL:

1. We always use the same shortcut ID regardless of the "alternate"
   selected by refinement. The documented ShortcutInfo API may not
   really justify "migrating" this ID to some intent other than the
   one that was registered as a shortcut (especially, e.g., if we
   imagine re-querying for shortcuts based on one of the alternates;
   we may find that the app has explicitly registered a shortcut that
   *matches* the alternate, but with a different assigned ID that we
   could learn *only* by re-querying). For now it seems unlikely that
   this would have significant unintended effects, so we'll punt the
   hypothetical bug; otherwise I belivee we'd need either re-querying
   or first-order API support.

2. Refinement is still unsupported for SelectableTargetInfo targets
   that *aren't* joined against a corresponding DisplayResolveInfo
   (namely, caller custom targets; I *think* that's all?). I'm not
   confident whether it's important to support "alternates" for these
   targets, but if nothing else I imagine we'd still want to support
   refinement of the *primary* intent (in order to defer "heavy"
   computation until the "pre-fire hook"). That's presumably already
   broken in the current implementation/not impacted by this change,
   so I'll leave it for now, then follow up with a fix/new CTS test.

Bug: 262805893
Test: `atest CtsSharesheetDeviceTest`. New
`#testShortcutSelectionRefinedToAlternate` (pending in the same topic)
exercises the fix from this CL, or fails without that fix.

Change-Id: Iee4ae94c040e4c0a025068def9badb98e20f281b

1 files changed, 2 insertions, 3 deletions

diff --git a/java/src/com/android/intentresolver/chooser/SelectableTargetInfo.java b/java/src/com/android/intentresolver/chooser/SelectableTargetInfo.java
index 1fbe2da7..e8847edc 100644
--- a/java/src/com/android/intentresolver/chooser/SelectableTargetInfo.java
+++ b/java/src/com/android/intentresolver/chooser/SelectableTargetInfo.java
@@ -398,10 +398,9 @@ public final class SelectableTargetInfo extends ChooserTargetInfo {
     private static List<Intent> getAllSourceIntents(@Nullable DisplayResolveInfo sourceInfo) {
         final List<Intent> results = new ArrayList<>();
         if (sourceInfo != null) {
-            // We only queried the service for the first one in our sourceinfo.
-            results.add(sourceInfo.getAllSourceIntents().get(0));
+            results.addAll(sourceInfo.getAllSourceIntents());
         }
-        return results;
+        return results;  // TODO: just use our own intent if there's no sourceInfo?
     }
 
     private static ComponentName getResolvedComponentName(