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

Commit 05e9c65a authored by Christopher Tate's avatar Christopher Tate
Browse files

Don't inappropriately kill ANRing drop recipients

If an app takes the 5-second ANR timeout before responding to a
drop, but then recovers, we were inappropriately throwing an
exception back at it for having acknowledged the drop after we'd
abandoned the operation out from under it.  Now we let such
responses slide without taking any punitive action: the app is
still okay, and the drag/drop operation was cleanly terminated
already anyway.

Bug 5045618

Change-Id: I0b7e76c61f0f8c97e41280b542a470a7d3c8d86f
parent ee00c054
Loading
Loading
Loading
Loading
+9 −1
Original line number Diff line number Diff line
@@ -306,7 +306,15 @@ final class Session extends IWindowSession.Stub
        synchronized (mService.mWindowMap) {
            long ident = Binder.clearCallingIdentity();
            try {
                if (mService.mDragState == null || mService.mDragState.mToken != token) {
                if (mService.mDragState == null) {
                    // Most likely the drop recipient ANRed and we ended the drag
                    // out from under it.  Log the issue and move on.
                    Slog.w(WindowManagerService.TAG, "Drop result given but no drag in progress");
                    return;
                }

                if (mService.mDragState.mToken != token) {
                    // We're in a drag, but the wrong window has responded.
                    Slog.w(WindowManagerService.TAG, "Invalid drop-result claim by " + window);
                    throw new IllegalStateException("reportDropResult() by non-recipient");
                }