tree 2c9b75aef075f74676b2481c1286f0c7630d1511
parent 0764d9e8f3a4efca9465a1a4044e2478c7396497
author Jeff Sharkey <jsharkey@android.com> 1593191660 -0600
committer Jeff Sharkey <jsharkey@google.com> 1593192517 +0000

Nuanced Uri handling related to WM/AM locking.

As part of detangling WM/AM locks, we added a Slog.wtf() to identify
and lurking cases where we tried resolveActivity() with the WM lock
held.  This helped us uncover startActivityFromRecents(), but the
logic there is unfortunately too risky to refactor.

Instead, this change narrows our locking detection to only consider
cases where we'd actually risk a deadlock; that is, when the thread
is holding the WM lock and we're just about to acquire the AM lock.

This change now avoids deadlock completely by assuming that we can't
check Uri permissions in these cases where we know a deadlock is
imminent; we instead use a safe-default that the Uri permission is
denied, and Slog.wtf() to identify which paths are triggering it.

The only path we've identified so far that triggers this logic is
startActivityFromRecents() which can be reproduced by re-launching
a recent task after a device reboot, which when combined with Uris
that require "forceUriPermissions" is a very rare situation.

Bug: 159937485, 115619667
Test: manual
Change-Id: I4ed1c402703e0772c0164ac0acc64f3a754512f3