Fixed endless scroll bug + ghost clicks bug + latency issues

[aquirozc]

Previously, when swipe gestures were performed by the accessibility service, they were all handled in the same thread, which meant that no swipes were overlapped, as each individual gesture wouldn't be executed until the previous one was completed. However, with the recent revamp of the Mouse Emulation Engine to be ADB-based, gestures are now handled on a parallel thread. This has resulted in the overlapping of swipes, as the key listener process continues to add extra swipes to the queue while a single movement is being executed, leading to an extremely large and almost endless scroll.

The overlapping of swipes was also the cause of the "ghost clicks" bug, as the operating system itself interpreted multiple swipes that are extremely close to each other as a standard tap. To address this issue, I proposed to put the main thread to sleep for the same amount of time each swipe would take to complete, before making another call to the system shell to perform a new gesture. As a result, the scroll now stops immediately after the key is released, with no extra delay or latency, no matter how long the key was pressed.

Overall experience is almost identical to the one which was achieved by using the Accessibility Service.

Note: Some now unused code lines were deleted, but I am aware that it is preferred to just comment them out rather than erase them. However, I am planning to add a "Use Legacy Engine" option, so I'd like to keep them in a separate method.

Here is a live demonstration of the improvements, just a reminder that everything shown is entirely ADB-based.

https://youtu.be/B9BbyHxBgoU

[virresh]

Oh nice!
This is awesome. I don't mind deleted code at all :), We can always retrieve it from commit logs.

Just wanted to confirm, is this on Android 12+ ?
(Some folks at Android have implemented latency improvements in the ADB input mechanism which is available for Android 12+. So it's likely the latency boost post ghost scroll fix comes from that).

I was rewriting the ADB engine with low level sendevent commands and buffering linux multi-touch protocol, but if just thread.sleep is working fine latency wise, I'll just push out the refactored version and merge this fix 😄

[aquirozc]

Yep it's over Android 12 update for Google TV devices. Im gonna try to test this out on Android 11 and prior to see If similar results are achieved.

[virresh]

That'll be great. In any case, I will prioritise a release with the thread sleep hack. Though it seems to ignore inputs sent in between scrolling, so probably can refine it a bit more with a blocking queue mechanism, but refinements can come later on :)

…

On Tue, 14 Feb, 2023, 8:28 am AlejandroQuirozC, ***@***.***> wrote: Yep it's over Android 12 update for Google TV devices. Im gonna try to test this out on Android 11 and prior to see If similar results are achieved. — Reply to this email directly, view it on GitHub <#67 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACTYGPDRRXBLQZZHOITLT7DWXLYGHANCNFSM6AAAAAAU25TFCA> . You are receiving this because you commented.Message ID: ***@***.***>

[aquirozc]

To avoid the long-term problems of the thread-sleep hack, I've implemented a brand-new queue-preventing mechanism intended to replace the existing one. This new mechanism relies on CountDownTimers, which run on their own thread and the main thread will remain available for us to keep processing tasks. When a new gesture is attached the queue is marked as busy and a timer is set to match the duration of the gesture. Before finishing up, the timer thread will alert that the queue is free again.

The results are the same that the ones achieved with the previous solution, the scroll doesn't become crazy and movement stops immediately after the key is released.