summaryrefslogtreecommitdiff
path: root/tools/aapt2/java/JavaClassGenerator_test.cpp
diff options
context:
space:
mode:
authorDianne Hackborn <hackbod@google.com>2017-04-14 17:57:33 -0700
committerDianne Hackborn <hackbod@google.com>2017-04-17 13:57:16 -0700
commite4d1a2e0daf8a3a6fa6b0f327523ebc381386cde (patch)
tree0bad226a838abbc5f47fb92befd865e4f294fcf5 /tools/aapt2/java/JavaClassGenerator_test.cpp
parentd8837b6fca23847fcd4dd295ccbb33ef9d4edcec (diff)
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
Diffstat (limited to 'tools/aapt2/java/JavaClassGenerator_test.cpp')
0 files changed, 0 insertions, 0 deletions