Fix a deadlock between WindowManagerGlobal and WindowManagerService
When a new display added, would first lock WMS then create a new
DisplayContent, that would also create the corresponding
SystemGesturesPointerEventListener, GestureDetector, ViewConfiguration,
and WindowManagerImpl, and it would also temporarily lock
WindowManagerGlobal in WindowManagerImpl's constructor.
This patch would post creating GestureDetector to avoid the deadlock
caused by other thread also lock WMS/WindowMaagerGlobal at same time.
Bug: 132746553
Test: create a app with splash screen and connect to new display at same
time.
Change-Id: I246e596dff387923356bbc579f785b634d3d2468
This commit is contained in:
@@ -113,7 +113,12 @@ class SystemGesturesPointerEventListener implements PointerEventListener {
|
||||
// statistics because it passes every touch event though a GestureDetector. By creating an
|
||||
// anonymous subclass of GestureDetector, these statistics will be recorded with a unique
|
||||
// source name that can be filtered.
|
||||
mGestureDetector = new GestureDetector(mContext, new FlingGestureDetector(), mHandler) {};
|
||||
|
||||
// GestureDetector would get a ViewConfiguration instance by context, that may also
|
||||
// create a new WindowManagerImpl for the new display, and lock WindowManagerGlobal
|
||||
// temporarily in the constructor that would make a deadlock.
|
||||
mHandler.post(() -> mGestureDetector =
|
||||
new GestureDetector(mContext, new FlingGestureDetector(), mHandler) {});
|
||||
}
|
||||
|
||||
@Override
|
||||
|
||||
Reference in New Issue
Block a user