Add a null check for a rare error case.

This just addresses the immediate NPE and doesn't explain the root
cause of the null value. I expect we *shouldn't* be seeing nulls, but
in the context of the other legacy code it seems to make sense to
take appropriate precautions against them anyways. This could've been
a regression from the legacy code, since an older version used an
`instanceof` check that would've correctly skipped over nulls. I've
chosen the narrowest fix to reproduce that logic, because it's
difficult to reason about other more-"elegant" potential improvements
(as briefly noted in b/285565219).

There's no obvious way to reproduce the null condition, so this isn't
tested to "fix"/"work in" the underlying error case overall (although
it should be clear from the code that this would prevent the specific
NPE we have at hand). Instead the test runs for this CL just validate
that the new null-check condition doesn't add regressions to our
currently-tested cases (where the result is non-null).

Bug: 285565219
Test: UnbundledChooserActivityTest, CtsSharesheetDeviceTest
Change-Id: I3b367206b4eefad579dbf613dfd38f485720cf65

0 files changed, 0 insertions, 0 deletions