Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit b3c30218 authored by Prabir Pradhan's avatar Prabir Pradhan
Browse files

InputManagerService: Do not remove input channel when disposing monitor 

To get around a race in InputDispatcher between the removal of the input
channel throught nativeRemoveInputChannel and the InputChannel#dispose
call, we remove the former call from InputManagerService.

This means it is now the responsibiity of the client to properly close
the input monitor by disposing of the InputChannel and all of its
duplicates.

Bug: 189135695
Test: manually try to reproduce the flaky conditions through a shell
script

Change-Id: Iba9f7c2428229ff6e2a7450a39828aed61160a3d
parent da685b23

services/core/java/com/android/server/input/InputManagerService.java

+13 −2
Original line number Diff line number Diff line
@@ -3230,7 +3230,7 @@ public class InputManagerService extends IInputManager.Stub 
     * Interface for the system to handle request from InputMonitors.

     */

    private final class InputMonitorHost extends IInputMonitorHost.Stub {

        private final IBinder mToken;

        private IBinder mToken;



        InputMonitorHost(IBinder token) {

            mToken = token;
@@ -3238,12 +3238,23 @@ public class InputManagerService extends IInputManager.Stub 


        @Override

        public void pilferPointers() {

            if (mToken == null) {

                throw new IllegalStateException(

                        "Illegal call to pilferPointers after InputMonitorHost is disposed.");

            }

            nativePilferPointers(mPtr, mToken);

        }



        @Override

        public void dispose() {

            nativeRemoveInputChannel(mPtr, mToken);

            // We do not remove the input monitor here by calling nativeRemoveInputChannel because

            // it causes a race in InputDispatcher between the removal of the InputChannel through

            // that call and the InputChannel#dispose call (which causes an FD hangup) from the

            // client (b/189135695).

            //

            // NOTE: This means the client is responsible for properly closing the InputMonitor by

            // disposing the InputChannel and all its duplicates.

            mToken = null;

        }

    }