Fix input text speed on Android

[tokou]

Proposed changes

• Group key codes from input text by state of modifiers
• Call UiDevice#pressKeyCodes with bunches of keyCodes instead of UiDevice#pressKeyCode with a single keyCode at a time
• Remove the Thread.sleep(75)

The speedup is amazing 🤩

Testing

• Went from 54s to 17s to input 445 chars of Lorem Ipsum

Before	After

• Used this flow to compare on an API 34 and an API 25 emulator

appId: com.google.android.apps.messaging
name: Input text
env:
  INPUT: "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum."
---
- launchApp:
    clearState: true

- tapOn:
    id: "com.google.android.apps.messaging:id/secondary_action_button"
    optional: true
- tapOn:
    id: "com.google.android.apps.messaging:id/(start_chat_fab|start_new_conversation_button)"
- inputText: "911"
- tapOn:
    id: "com.google.android.apps.messaging:id/(contact_name|recipient_text_view)"
- tapOn:
    id: "com.google.android.apps.messaging:id/compose_message_text"

- startRecording: input_text
    optional: true
- inputText: ${INPUT}
- extendedWaitUntil:
    visible: ${INPUT}
    timeout: 60_000
- stopRecording
    optional: true

• I had to change the timeout here to 60s as it took longer than that to input all the text
  

  maestro/maestro-client/src/main/java/maestro/drivers/AndroidDriver.kt

  Line 72 in 6ac16c2

  private val blockingStubWithTimeout get() = blockingStub.withDeadlineAfter(40, TimeUnit.SECONDS)

Issues fixed

Fixes #2005

[bartekpacia]

Hey @tokou! Thanks a ton for taking a stab and fixing this very annoying problem.

The speedup is amazing indeed, but I'm not sure if we want it, given that we want Maestro to behave like a normal user. Anyway, we could make this new behavior the default, and add a configuration option for inputText (for command and workspace level) in the future if someone requests the old way of how inputText worked (i.e. entering text character-by-character).

I like all the changes you made in this PR, but I'm curious whether you know what's the change that actually fixed the problem? Was it the removal of that Thread.sleep(75)?

[bartekpacia]

Let's add a comment explaining what this code does and/or simplify it.

[bartekpacia]

I like the test that inputs the whole "Lorem ipsum...". If that test also used assertVisible at the end, that'd be a pretty solid test that inputText works well and is stable.

I'd like us to have this test in our demo_app workspace.

I'll add such a screen to our demo app.

[bartekpacia]

Oh, and let's also add an entry to CHANGELOG.md

[Leland-Takamine]

Nice work on this! Some context on the delays added in the original implementation: We were seeing some issues where sometimes characters would be skipped. This was difficult to reproduce consistently, but we should ensure that this does not regress before making this the default behavior.

[tokou]

@bartekpacia I added the comment. Hope it clears things up.
I also redid testing with the 3 cases : old, just removing the sleep and sending bunched up key presses

Old (00:54)	No sleep (00:24)	Bunch keys (00:17)

@Leland-Takamine

We were seeing some issues where sometimes characters would be skipped.

I think this is due to the rate of commands sent to UiDevice. That's why the bunching up of commands through pressKeyCodes could be better than just blasting n calls to pressKeyCode

The only potential issue is that the documentation of pressKeyCodes states that it's more intended for multiple key presses at the same time instead of consecutive key presses 🤔

pressKeyCodes
Presses one or more keys. For example, you can simulate taking a screenshot on the device by pressing both the power and volume down keys.

— https://developer.android.com/reference/androidx/test/uiautomator/UiDevice#pressKeyCodes(int[],int)

In practice, it seems to be working fine though.

[tokou]

@bartekpacia Unfortunately, after adding the test on the demo app, I got some random failures when running it on my emulator. I think it's in part because of the demo app being a Flutter app that makes the issue happen more often.

[amanjeetsingh150]

Hey @tokou is this PR ready for review? I see that you observed some random failures, let me know if you need help on this.