Avoid obsolete uid-state change evaluations in NPMS
In some cases, where a uid undergoes quick consecutive state changes and the handler message has not completed execution, we can return early if we know a following handler message to evaluate the same rules is pending. We peek at UidStateCallbackInfos to infer this state as these are populated directly in the UidObserver callbacks before posting to the handler. The code avoids removing messages from the Handler as - it is a linear operation that may be slower. - the check on UidStateCallback happens later and returns from redundant handler message-processing without incurring much additional work. Also taking out some code out of the mUidRulesFirstLock lock. Test: atest CtsHostsideNetworkTests Test: FrameworksServicesTests:NetworkPolicyManagerServiceTest Bug: 327058756 (cherry picked from https://googleplex-android-review.googlesource.com/q/commit:a0703d6dd4e906b9a38a1a4b497ff0c628d1411d) Merged-In: I764f714d3ce09699a0ab82b77c8b6a577cd9f9ab Change-Id: I764f714d3ce09699a0ab82b77c8b6a577cd9f9ab
Loading
Please register or sign in to comment