tree 0bad226a838abbc5f47fb92befd865e4f294fcf5
parent d8837b6fca23847fcd4dd295ccbb33ef9d4edcec
author Dianne Hackborn <hackbod@google.com> 1492217853 -0700
committer Dianne Hackborn <hackbod@google.com> 1492462636 -0700

Fix issue #36858643: Runtime restart on OPR1.170323.002

We had a layering problem between alarm manager, device idle
controller, and activity manager.  The layering should be, from
bottom to top:

activity manager
alarm manager
device idle controller.

However in the path of activity manager's PendingIntent.send(),
it would do a direct call to device idle controller.  It was
careful to do this without its lock held, but that isn't enough.
In this case, alarm manager is doing send() with its lock held,
expecting that to be safe, but it ends up causing it to call up
in to device idle controller via the activity manager (in order
to update the temporary whitelist).

To fix this, activity manager now has an internal data structure
representing pending temp whitelist requests, and all it does is
add to that during the call in, scheduling a message to later
dispatch those to device idle controller.  But to make things
correct, we need to use this data stucture to act like the uid
is already on the temp whitelist even before we actually dispatch
that message.  (So we don't have races with things calling
startService() for example.)  So all the existing stuff looking
at the temp whitelist that is handed down by device idle controller
will also consult with this data structure of pending changes.

Test: bit CtsAppTestCases:ActivityManagerProcessStateTest

Change-Id: Id444b7ad3e694dc977c7f4fa236fbad855ce4066