Error: Unknown command: tap

[ghazel]

Running on the Nexus Q

16:53:40 [INFO ] [AbstractApplicationContext] - Refreshing org.springframework.context.annotation.AnnotationConfigApplicationContext@28ba21f3: startup date [Thu Jan 19 16:53:40 PST 2017]; root of context hierarchy
16:53:46 [WARN ] [AutowiredAnnotationBeanPostProcessor] - Inconsistent constructor declaration on bean with name 'androidDeviceImpl': single autowire-marked constructor flagged as optional - this constructor is effectively required since there is no default constructor to fall back to: public com.github.xsavikx.androidscreencast.api.AndroidDeviceImpl(com.android.ddmlib.IDevice)
Error: Unknown command: tap
usage: input [text|keyevent]
input text <string>
input keyevent <event_code>

[xSAVIKx]

Hi. Your device don't support tap command with adb. Not sure if anything could be done

…

On Fri, Jan 20, 2017, 02:54 Greg Hazel ***@***.***> wrote: Running on the Nexus Q 16:53:40 [INFO ] [AbstractApplicationContext] - Refreshing ***@***.***: startup date [Thu Jan 19 16:53:40 PST 2017]; root of context hierarchy 16:53:46 [WARN ] [AutowiredAnnotationBeanPostProcessor] - Inconsistent constructor declaration on bean with name 'androidDeviceImpl': single autowire-marked constructor flagged as optional - this constructor is effectively required since there is no default constructor to fall back to: public com.github.xsavikx.androidscreencast.api.AndroidDeviceImpl(com.android.ddmlib.IDevice) Error: Unknown command: tap usage: input [text|keyevent] input text <string> input keyevent <event_code> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#35>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFaaqbabAGYve04Q_IPi47z_qNYSQ29Sks5rUAXdgaJpZM4Loy5S> .

[ghazel]

Using monkeyrunner to emit a touch event works:

>>> from com.android.monkeyrunner import MonkeyRunner, MonkeyDevice
>>> device = MonkeyRunner.waitForConnection()
>>> device.touch(512, 1800, MonkeyDevice.DOWN_AND_UP)     

[xSAVIKx]

@ghazel probably it emits 2 keyevent commands and that's why it's possible to send tap event.

I'd appreciate a PR with such fallback functionality when direct ADB tap command is not available.

[ghazel]

I don't see it using keyevent commands. It's using the monkey tcp interface (https://github.com/aosp-mirror/platform_development/blob/master/cmds/monkey/README.NETWORK.txt) and sending:
tap x y

[xSAVIKx]

@ghazel try to run adb shell input tap 512 1800 within the terminal. Also, what adb instance do you use?

[ghazel]

input on the device does not have a tap command. The adb is the one that comes with platform-tools.

[xSAVIKx]

@ghazel OK. So, tap ins't supported by your input implementation.

Monkey uses its own implementation of the tap command:

tap x y
The tap command is a shortcut for the touch command.  It will
automatically send both the up and the down event.

And the tap is just a shortcut to the touch:

touch [down|up|move] x y

This command injects a MotionEvent into the input system that
simulates a user touching the touchscreen (or a pointer event).  x and
y specify coordinates on the display (0 0 being the upper left) for
the touch event to happen.  Just like key events, touch events at a
single location require both a down and an up.  To simulate dragging,
send a "touch down", then a series of "touch move" events (to simulate
the drag), followed by a "touch up" at the final location.

Anyway, Monkey uses their own implementation of events, that rely on android.hardware.input.InputManager. That means, that we do need some client on the device side, while AndroidScreencast doesn't required any client side app.

For now, I don't know how to help you. The only possible way here I see — implement some fallback with input keyevent when tap isn't available.

[ghazel]

AndroidScreencast does require the input command on the client side, same as monkey. It's just that in my case monkey works better than input. They both seem to be present on all devices.

[Hattshire]

given we use adb to do this, it would be better for a broader compatibility to push an executable(i.e. modified input ) with adb to a temp folder and execute that instead of the native device executable.

[xSAVIKx]

@Hattshire I do appreciate a PR with such modifications :-)