Chooser fragments shouldn't save instance state.
1. I can't think of any way we could possibly trigger the fragment's
load-from-saved-state flow since Sharesheet isn't in history.
2. If this flow was ever triggered for the "stacked app" fragment
we would crash. Our first step in restoring from a `Bundle` is
to make an unsafe downcast to `MultiDisplayResolveInfo` and
invoke one of its subclass methods, but `MultiDisplayResolveInfo`
doesn't actually implement `Parcelable` correctly; it inherits
the relationship via `DisplayResolveInfo`, including its
`Creator`, so any attempt to restore the parceled target would
get a concrete `DisplayResolveInfo`, slicing off any data
specific to its old multi-target type (and, of course, leaving
an object that can't use any of the subclass methods).
3. Support for this flow seems to be the only reason that
`DisplayResolveInfo` implements `Parcelable` at all, so as part
of go/chooser-targetinfo-cleanup we should prune this (broken and
dead) code and then go on to remove all of that complexity from
the `TargetInfo` API.
Test: manual & presubmit
Bug: 202167050
Change-Id: Ida3b74edf975e3c1353e757b37e4cfadf716d5c3
4 files changed