Fix Android touch input after session recovery - #753
Conversation
|
Bugbot is not enabled for your account, so this pull request was not reviewed. Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs. |
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Fixes the Android cursor/controller failure reported by <@700873802065641482> (mezo0077).
What changed
Diagnostic evidence
The supplied build 84 log reaches healthy streaming with both input channels open, then records signaling EOF, reliable and partially reliable channels closing, ICE disconnecting, 503/404 reconnect attempts, and input drops while no channel exists. CloudMatch subsequently returns zero active sessions and recovery stops with
The running session could not be found anymore. The older retained run shows mouse press/release events being consumed locally while neither channel exists. No log event shows a touch gesture causing the transport failure.Verification
./gradlew testDebugUnitTest --tests com.opencloudgaming.opennow.NativeTouchTest --tests com.opencloudgaming.opennow.InputDiagnosticsTest --tests com.opencloudgaming.opennow.VirtualCursorTest --tests com.opencloudgaming.opennow.StreamResolutionTest./gradlew assembleDebug./gradlew lintDebugwas also run; it reaches the repository's existing baseline of 40 unrelated errors, beginning atAndroidAppDataReset.kt:45(Context#getDataDirrequires API 24 while minSdk is 23). Changed files add no lint errors.Visual proof
No screenshot is attached because this fix has no new or changed visual surface: it changes input ownership, teardown, and cloud-session recovery behavior behind the existing stream UI. Reproducing the affected experience requires a real NVIDIA/GFN account, an active cloud stream, and the reporter's intermittent signaling/session failure; this environment has no account credentials, so a screenshot could not honestly demonstrate the behavioral result.