System Back in non-focusable TouchpadActivity causes input-timeout ANR

[The-unknown-Shadowman]

Correction / updated diagnosis

The original report conflated two different failures. A fresh capture with full logcat and the generated ANR trace now shows that the reproducible Back-button failure in the phone-side touchpad is an input-dispatch ANR in MagicDesk, not a blocked MagicDesk main thread and not the previously captured SystemUI crash.

The earlier com.android.systemui / wmshell.main StackOverflowError is retained below as a separate observation. A causal relationship between the two failures is not established.

Primary issue: Back from MagicDeskTouchpadActivity causes a no-focused-window ANR

Environment

• Device: REDMAGIC 11 Pro (NX809J), Android 16
• Build fingerprint: REDMAGIC/NX809J-EEA/NX809J:16/BQ2A.250705.001-BP2A.250605.031.A3/20260625.010111:user/release-keys
• Installed package verified with dumpsys package:
  • versionName=1.5.1
  • versionCode=151
• Captured activity: io.github.mekhontsev.magicdesk/.MagicDeskTouchpadActivity

Steps to reproduce

1. Start a MagicDesk desktop session.
2. Open the phone-side MagicDesk touchpad.
3. Press the Android system Back button.
4. The Back action does not close the touchpad. After the input timeout, Android shows the application-not-responding dialog for MagicDesk.
5. Per reporter observation, the desktop remains visible until Close app is selected; terminating the MagicDesk process then also removes the desktop.

This capture proves the behavior for MagicDeskTouchpadActivity. It should not be assumed to prove the same mechanism for other MagicDesk screens without a separate capture.

Exact logcat timeline

11:33:04.221  wm_on_create_called: MagicDeskTouchpadActivity
11:33:04.238  viewroot_draw_event: MagicDeskTouchpadActivity reportDrawFinished
11:33:04.238  wm_on_top_resumed_gained_called: MagicDeskTouchpadActivity
11:33:06.408  input_focus: Requesting to set focus to null window, reason=UpdateInputWindows

11:33:08.256  KeyButtonView: Back button event: ACTION_DOWN
11:33:08.258  InputDispatcher: Waiting because no window has focus but
              MagicDeskTouchpadActivity may eventually add a window when it
              finishes starting up. Will wait for 8000ms

11:33:16.259  InputDispatcher: Dropping KEY event because there is no focused window
11:33:16.264  WindowManager: ANR in MagicDeskTouchpadActivity
              Reason: Input dispatching timed out
              (Application does not have a focused window)
11:33:16.275  am_anr: io.github.mekhontsev.magicdesk
11:33:16.309  ActivityManager: ANR in io.github.mekhontsev.magicdesk
              PID: 2767
              Parent: io.github.mekhontsev.magicdesk/.MagicDeskTouchpadActivity

The observed interval between ACTION_DOWN and the dropped key event is approximately 8.003 seconds; InputDispatcher explicitly announced an 8000 ms wait.

ANR trace: the MagicDesk main thread is idle

The generated Android bugreport contains /data/anr/trace_23 for PID 2767 at 11:33:16.309. Its main thread is waiting normally in the message loop:

----- pid 2767 at 2026-08-09 11:33:16.309480823+0200 -----
Cmd line: io.github.mekhontsev.magicdesk

"main" prio=5 tid=1 Native
  native: #00  __epoll_pwait
  native: #01  android::Looper::pollInner
  native: #02  android::Looper::pollOnce
  at android.os.MessageQueue.nativePollOnce(Native method)
  at android.os.MessageQueue.nextLegacy(MessageQueue.java:904)
  at android.os.MessageQueue.next(MessageQueue.java:1016)
  at android.os.Looper.loopOnce(Looper.java:203)
  at android.os.Looper.loop(Looper.java:397)
  at android.app.ActivityThread.main(ActivityThread.java:10238)

There is no blocked MagicDesk lifecycle method, Binder call, deadlock, or busy loop on the main thread in this trace. Android reports the ANR because the key event cannot be delivered to a focused window.

Corresponding app-source path

At repository commit 3d2221137836c451e69b6fb8462f54f1d0676344, MagicDeskTouchpadActivity.onCreate() does the following:

updateTargetDisplay(getIntent());
setTextInputFocusEnabled(false);
setContentView(createContent());
mBackCallback = this::handleBack;
getOnBackInvokedDispatcher().registerOnBackInvokedCallback(
        OnBackInvokedDispatcher.PRIORITY_DEFAULT,
        mBackCallback);

setTextInputFocusEnabled(false) adds both flags:

getWindow().addFlags(
        WindowManager.LayoutParams.FLAG_NOT_FOCUSABLE
                | WindowManager.LayoutParams.FLAG_ALT_FOCUSABLE_IM);

The registered callback would call:

handleBack() -> dismissFromUser()

However, in the captured run the Back key remains in InputDispatcher because the resumed activity has no focused window, and the registered callback is not reached. This creates a mismatch: the activity registers a system-Back callback while its normal touchpad window is deliberately FLAG_NOT_FOCUSABLE.

The touchpad header's in-app close button directly calls dismissFromUser() from its click listener, so that path does not depend on delivery of the system Back key.

Suggested investigation direction

Please consider changing the touchpad/window lifecycle so that a top-resumed MagicDeskTouchpadActivity cannot remain the current application with no focusable window when system Back is pressed. The exact implementation needs testing because FLAG_NOT_FOCUSABLE is also used by the text-input/IME flow; merely registering OnBackInvokedCallback does not solve the captured no-focus state.

Separate earlier observation: SystemUI WM Shell stack overflow

A separate retained crash-buffer entry from 2026-08-08 22:51:57.974 shows:

FATAL EXCEPTION: wmshell.main
Process: com.android.systemui, PID: 5864
java.lang.StackOverflowError: stack size 4109KB
    at com.android.wm.shell.windowdecor.DesktopModeWindowDecoration.relayout(...)
    at com.android.wm.shell.windowdecor.WindowDecoration.relayout(...)
    at com.android.wm.shell.windowdecor.WindowDecoration.inflateIfNeeded(...)
    at com.android.wm.shell.windowdecor.WindowDecoration.obtainDisplayOrRegisterListener(...)
    at com.android.wm.shell.common.DisplayController.addDisplayWindowListener(...)
    at com.android.wm.shell.windowdecor.WindowDecoration$1.onDisplayAdded(...)
    at com.android.wm.shell.windowdecor.DesktopModeWindowDecoration.relayout(...)
    ... repeating until stack exhaustion

The same incident's retained timeline contains:

22:51:54.478  TO_BACK transition for the desktop and anchor tasks on display 3
22:51:57.776  Duplicate finish request for FreeformLaunchAnchorActivity
22:51:57.974  FATAL EXCEPTION: wmshell.main / StackOverflowError

Facts established by that capture:

• the crashing process was com.android.systemui;
• the overflowing thread was wmshell.main;
• the recursion was in WM Shell window-decoration relayout/display-listener handling;
• the duplicate finish request occurred 198 ms before the overflow;
• the overflow occurred about 3.5 seconds after the logged TO_BACK transition.

The logs do not establish that the duplicate finish caused the overflow, nor that this SystemUI failure and the touchpad no-focus ANR share one root cause. They should be investigated as separate failure modes unless further evidence links them.

Workaround

Use MagicDesk's in-app touchpad close control and the in-app Close desktop / Exit MagicDesk action rather than Android system Back while the desktop session is active.

[mekhontsev]

Thanks for the detailed report. The primary Back-button ANR was fixed in bd30e17 by removing the non-focusable window state from MagicDeskTouchpadActivity, so Android can deliver Back normally. This fix has been tested and is included in v1.6.0.

The launch anchor mentioned in the separate SystemUI observation was later removed entirely in f94a8b3 as part of the new v1.6 launch path. This does not prove that it caused the earlier SystemUI stack overflow, but that old path no longer exists.

I’m closing this as fixed. If Back still causes an ANR in v1.6, please attach a fresh Diagnostics report and ANR trace.