[thewhoareyou]

Summary

Opening the in-stream overlay menu while a Bluetooth/USB mouse is captured leaves the mouse dead: the menu is a view in the same window, so pointer capture stays held — the cursor stays hidden and clicks go to the host, not the sheet. Releasing capture fixes the click but, on Samsung's Android 10 input stack, re-acquiring it afterwards leaves the window registered as the capture owner while no motion events ever reach it again.

This keeps pointer capture held and gives the menu its own cursor instead:

• OverlayMenuView.show() fires a new onMenuOpened() listener callback; Game uses open/close to enter and leave a software-cursor mode.
• While the menu is up, captured relative deltas move a drawn cursor (the device's own pointer_arrow asset) and button transitions become touch events dispatched at its position — tiles get normal click handling, scroll views drag, and a press off the sheet dismisses the menu.
• handleMotionEvent consumes pointer/touch events while the menu is up so nothing leaks to the host; hover passes through so the system keeps tracking a free pointer when capture is off.
• OverlayMenuView no longer steals view focus: requestFocus() is removed from show() and the sheet and tiles are no longer focusable in touch mode. On Samsung's stack, captured-pointer events only reach the view holding both capture and focus — a menu tile taking focus for its nav highlight was silently cutting off all mouse motion. Game also puts focus back on the stream view whenever it strays while capture is held.
• Samsung reports captured motion as source 0x20004 — SOURCE_MOUSE_RELATIVE's device bits over a trackball class byte rather than AOSP's pointer class. AndroidNativePointerCaptureProvider now classifies on the device bits, so those events are recognised as relative mouse motion.
• Related hardening: the deferred re-capture in onWindowFocusChanged and the device-added path no longer re-capture while the cursor was deliberately freed (isCursorVisible).

Test plan

Verified on a Galaxy Tab S9+ (Android 15 / One UI 7, Samsung input stack) with a Logitech MX Anywhere 3 over Bluetooth, streaming from Vibepollo:

• Remote mouse works while streaming
• Open menu → cursor appears and tracks the mouse
• Mouse clicks activate menu tiles; scroll wheel works on the sheet
• Press outside the sheet dismisses the menu; remote mouse works immediately after close
• Repeated open/close cycles keep working
• testNonRootDebugUnitTest — new regression tests pass (menuShouldUseSoftwareCursor decision matrix, isRelativeMouseSource classification); lintNonRootDebug clean

Note: on this Samsung stack the release → re-acquire path was shown unreliable by logcat (kernel keeps emitting REL_X/Y, the dispatcher reports the app as capture owner, yet no motion reaches it). The software-cursor approach avoids that transition entirely.

Generated with Devin