selendroid/selendroid — pull request #753 by mkonicek (2014-12-15 14:33:59+00:00)
Title: Don't call waitForIdleSync() before sending keys

`Instrumentation.waitForIdleSync` can hang forever if there is an animation running. Turns out animations on Android can keep the message queue busy, see this [issue](https://code.google.com/p/android/issues/detail?id=61111).

The [documentation](http://developer.android.com/reference/android/app/Instrumentation.html#waitForIdleSync()) says:
Schedule a callback for when the application's main thread goes idle (has no more events to process).

Indeed, I saw a case where an application had a subtle infinite animation (changing colors) as part of its login screen. Even though the UI is "idle", the message queue is not empty and `waitForIdleSync` would hang indefinitely.

It should be safe to send keys even without calling `waitForIdleSync`:

Both `sendKeyDownUpSync` and `sendSyncString` add an event to the application's message queue and block until it has been processed. It should be the responsibility of the test not to send the keys "too early" - for example, it should wait for UI elements to be visible before trying to type into them, or sending the BACK button.

Both methods are designed to be called from a non-UI thread: the both call `android.app.Instrumentation.validateNotAppThread()` ([source](http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/4.3_r1/android/app/Instrumentation.java#870)).

As a related note, we might even revisit the general usage of `waitForIdleSync` in the Selendroid codebase: rather than Selendroid waiting for the UI to become "idle" using `waitForIdleSync`, it might be better to leave the waiting for certain events up to the test code, using the standard techniques like Selenium's `Wait` and polling until certain UI elements become visible, and then continuing.
The few uses of `waitForIdleSync` are in `AndroidTouchScreen` and `InstrumentedKeySender`.