| Thread Previous • Date Previous • Date Next • Thread Next |
Hola Rishabh,This is a great analysis (please add to the bug report), although not very encouraging. If as you mention, the keyEvent is designed to not be spoofed by 3rd-party applications (which is kind of what we are trying to do), then we may be out of luck.
The device id sounds important, maybe it is being used as part of the anti-spoofing checks? also, maybe the onKeyDown, onKeyUp must be a few miliseconds appart (say at least 100). We could try this by using a postDelayed() and linking to the call from a runnable.
Now you mention trying to replicate the keyEvent for onKeyDown/Up(), I remember trying something similar with the same results before. Somehow the device still knows the event has not been triggered by the hardware.
The last thing I would try is to copy the events directly from the overridden onkeyUp() and onKeyDown() calls (two separate copies) and then use them to call the same events programatically (you may have to offset the down/up time). Let's hope that works. Have you had a chance to upload your branch yet?
cheers! Jorge On 11-04-18 09:58 AM, Rishabh Garg wrote:
# So I filled the event down/Up time as current time using System clock and filled device id as 0. # After constructing this key-event, I passed it to first the onKeyDown function and then to onKeyUp function along with the key-code to test if we could open the menu using this by emulating the menu key event. # I printed the key event recieved by both those functions sent by me, and their value in log was exact same as generated by a hardware key, but menu did not opened. I tried various other combinations of fields, but even though both my and the hardware key event showed the same key-event value on the Log, my version was not able to trigger the menu.
| Thread Previous • Date Previous • Date Next • Thread Next |
