Use IMMS' worker thread for IMMS.MyPackageMonitor
This CL attempts to mitigate performance regressions that could have
been caused by my previous CLs [1][2], which might have increased
tasks executed on a shared background thread in system_server.
By default
com.android.internal.content.PackageMonitor
runs on
com.android.internal.os.BackgroundThread
unless a looper is specified explicitly. What I suspect is that with
my previous CLs IMMS.MyPackageMonitor started taking more time on that
shared background thread, which results in slowing down other
components in the system_server process.
To mitigate the above scenarios, let's use IMMS' own worker thread
to handle IMMS.MyPackageMonitor callbacks.x
[1]: I07e32739f486d960c9dd22476120fa35bf1899e4
0c5feb229eb54fca1b886fcf2adde148dd50b2c4
[2]: I10aa547f0de607ef3c0ba26764dac0585c40c843
2501e749abb30ce745f22ae33869cfb11200f37d
Bug: 327861441
Test: presubmit
Change-Id: I1ed05d753ca72326aeb5eaf7b402f0d280ed5dc8
diff --git a/services/core/java/com/android/server/inputmethod/InputMethodManagerService.java b/services/core/java/com/android/server/inputmethod/InputMethodManagerService.java
index 2205986..6688f53 100644
--- a/services/core/java/com/android/server/inputmethod/InputMethodManagerService.java
+++ b/services/core/java/com/android/server/inputmethod/InputMethodManagerService.java
@@ -1897,7 +1897,7 @@
}
}, "Lazily initialize IMMS#mImeDrawsImeNavBarRes");
- mMyPackageMonitor.register(mContext, null, UserHandle.ALL, true);
+ mMyPackageMonitor.register(mContext, mHandler.getLooper(), UserHandle.ALL, true);
mSettingsObserver.registerContentObserverLocked(currentUserId);
final IntentFilter broadcastFilterForAllUsers = new IntentFilter();