Loading
Always process state changes below TOP_THRESHOLD
Sometimes, we deliberately send a process-state TOP change before the normal oom adjuster update gets triggered for resuming activities. In this case, there may be a duplicate notification for the same process-state change with a newer procStateSeq. We need to ensure we always process these notifications and notify activity manager on completion. These are redundant notifications but should be rare and cheap enough to always process - even if they do not end up changing any of the firewall state. Also modifying the log in ActivityManager to report a wtf whenever the wait timeouts to help emphasize this discrepancy. Test: atest FrameworksServicesTests:NetworkPolicyManagerServiceTest Fixes: 327303931 Change-Id: I4884072bd6d7820acee67851d7504886564e2348