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

0 files changed, 0 insertions, 0 deletions