From 08003bb380f37a87fe22bea7bb4674e7c1f0bc30 Mon Sep 17 00:00:00 2001 From: Joshua Trask Date: Tue, 7 Mar 2023 19:08:47 +0000 Subject: 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 --- .../src/com/android/intentresolver/chooser/SelectableTargetInfo.java | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) (limited to 'java/src') 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 getAllSourceIntents(@Nullable DisplayResolveInfo sourceInfo) { final List 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( -- cgit v1.2.3-59-g8ed1b