Why mScreenReceiver in NetworkPolicyManagerService not running in its HandlerThread?
已查看 42 次
跳至第一个未读帖子
sharon.hou
未读,
2012年12月2日 12:43:282012/12/2
回复作者
登录即可回复作者
转发
登录即可转发
删除
您无权在此群组中删除帖子
复制链接
举报消息
请登录以举报消息
显示原始帖子
要么此群组的电子邮件地址为匿名状态,要么您得查看成员电子邮件地址权限才能查看原始帖子
收件人 android-...@googlegroups.com
Hi,
Does anyone know why mScreenReceiver in NetworkPolicyManagerService is not running in its HandlerThread? Instead it is running in SystemServer server thread. I can see some SystemServer watchdog trigger since this receiver stuck on waiting the mRulesLock which was occasionally held by other api call.
Do you see any impact if remove the mRulesLock from below code part?
private BroadcastReceiver mScreenReceiver = new BroadcastReceiver() { @Override public void onReceive(Context context, Intent intent) { synchronized (mRulesLock) { // ANY IMPACT from REMOVED this LOCK here ?? // screen-related broadcasts are protected by system, no need // for permissions check. mHandler.obtainMessage(MSG_SCREEN_ON_CHANGED).sendToTarget(); } } };
The trace:
"android.server.ServerThread" prio=5 tid=11 MONITOR
| group="main" sCount=1 dsCount=0 obj=0x41680f00 self=0x50d3c4e8
| sysTid=20115 nice=-2 sched=0/0 cgrp=apps handle=1326678472
| schedstat=( 0 0 0 ) utm=552 stm=131 core=1
at com.android.server.net.NetworkPolicyManagerService$2.onReceive(NetworkPolicyManagerService.java:~412)
- waiting to lock <0x41a25018> (a java.lang.Object) held by tid=46 (NetworkPolicy)
at android.app.LoadedApk$ReceiverDispatcher$Args.run(LoadedApk.java:757)
at android.os.Handler.handleCallback(Handler.java:615)
at android.os.Handler.dispatchMessage(Handler.java:92)
at android.os.Looper.loop(Looper.java:137)
at com.android.server.ServerThread.run(SystemServer.java:1054)
Regards Sharon
Jeff Sharkey
未读,
2012年12月3日 15:40:562012/12/3
回复作者
登录即可回复作者
转发
登录即可转发
删除
您无权在此群组中删除帖子
复制链接
举报消息
请登录以举报消息
显示原始帖子
要么此群组的电子邮件地址为匿名状态,要么您得查看成员电子邮件地址权限才能查看原始帖子
收件人 android-...@googlegroups.com
Screen broadcasts are special since they are ordered. If
registerReceiver() pushed them directly onto mHandler, the screen
broadcasts could be held up by other mHandler messages. This is why
it's sending MSG_SCREEN_ON_CHANGED and allowing the broadcast to
finish quickly.
You're absolutely right that it doesn't need to acquire the lock just
to send the message; I'll submit a fix.