diff options
| author | 2022-11-14 12:11:00 -0500 | |
|---|---|---|
| committer | 2022-11-29 14:13:18 +0000 | |
| commit | e366d8cd25624e35bb0eeb5e1d46cbfdf12a4ae5 (patch) | |
| tree | ff5b02fa1df315e2ff5ae5171059cc26bc04bace /java/tests/src | |
| parent | 78d4f9a56a004a1031502c33b523f9b495d031a9 (diff) | |
Fail startup via ResolverActivity.super_onCreate()
`ResolverActivity` provides this mechanism so that we can bail out
of activity creation if we determine that the request is invalid.
That elides a lot of the internal (~"template method") calls that
the base class dispatches down to `ChooserActivity` during setup,
where we've had to deal with annoying null-check/lazy-initialization
requirements even when we intended to fail out.
This generally should not affect our behavior for valid requests.
Interestingly, there's a test changed in this CL because it appears
to have been set up incorrectly, and in the original version of that
test we can see that certain Chooser Intents that `ChooserActivity`
attempts to reject as invalid, that nevertheless would end up getting
handled by the base `ResolverActivity` during the failure flow.
Because `ChooserActivity` immediately calls `finish()` as part of this
flow, that behavior should only be observable for autolaunch, and
otherwise the intent will be rejected as-planned; I conclude that this
probably isn't intended as a mechanism to support autolaunch, and so
it's OK to "regress" as long as the test is fixed. [EDIT: since this
CL was originally uploaded, an intervening change by ayepin@ already
fixed this same test.]
The CL also cleans up one case I know we had null-checking
specifically for this reason; there are probably others left to clean
up later.
Test: atest IntentResolverUnitTests
Bug: 202167050
Change-Id: I28c7b1eff50e516d6bf0043aa141d13f1afce076
Diffstat (limited to 'java/tests/src')
0 files changed, 0 insertions, 0 deletions