Appium hangs while finding element in a video player.

[ajeeshvl]

The problem

I'm trying to to automate play back controls in a video player. When touch on the player container, an overlay appears. When Appium tries to find element on overlay, it hangs.
I tried following, nothing worked

1. Pause video first and tried to find element
2. Set waitForIdleTimeout to 0 in Appium settings. To tell appium, not to wait for action to perform.
3. Tried with different location strategies such as id, xpath, etc

Environment

*Appium version (or git revision) that exhibits the issue: 1.6.5
Desktop OS/version used to run Appium: Mac OS (Sierra) 10.12.4
Node.js version (unless using Appium.app|exe): v7.3.0
Mobile platform/version under test: Android 7.0.1 / 6.0.1
Real device or emulator/simulator: Real device
Appium CLI or Appium.app|exe: Appium CLI

Link to Appium logs

https://gist.github.com/ajeeshvl/96c00c60cab8099095105a347a1e6647

[mykola-mokhnach]

1. Try UIAutomator2 as the backend.
2. It might be the application under test has some background animations and the driver waits until the app is idle before locating any element. Disabling background animations can help to improve the situation.

[ajeeshvl]

@mykola-mokhnach I'm already using uiautomator2. I verified and there are no background animations. However, some other api calls are being made even after the content is paused. Is there anyway, we can force driver to find element even if app isn't idle?

[mykola-mokhnach]

I don't know any way to change this behaviour from the outside

[JaniJegoroff]

Have you tried latest Appium beta with newer uiautomator2 driver version?
How does view hierarchy look like with uiautomatorviewer and Appium? Is everything as expected in both cases?

[ajeeshvl]

Yes, I tried with latest beta versions, still doesn't work. hierarchy looks good in everywhere. Server doesn't return anything as its waiting for app to become idle.

[ajeeshvl]

@mykola-mokhnach @jlipps @sravanmedarapu I tried to set waitForIdleTimeout to 0 in appium settings
session/:session/appium/settings
As per doc, Once the idle state is detected or the timeout elapses (whichever occurs first), the object will start to wait for the selector to find a match. Even this doesn't work for me. Am I doing this right?

[mykola-mokhnach]

Can you try to update to the most recent beta and set the disableWindowAnimation capability to true ?

[ajeeshvl]

@mykola-mokhnach thanks for the suggestion. unfortunately, disableWindowAnimation that doesn't seem working for me. Tried in the latest beta.
Still it hangs on
[debug] [JSONWP Proxy] Proxying [POST /element] to [POST http://localhost:49000/wd/hub/session/65e931e3-3f71-4fb0-8fcf-ad3a9991416a/element] with body: {"strategy":"id","selector":"btn_flip_tray_label","context":"","multiple":false}

More detailed logs here
https://gist.github.com/ajeeshvl/697eac5c5f471aba3454bb7bc75ba5cf

[jlipps]

@ajeeshvl next thing I'd try is see if building a similar test in UiAutomator2 directly is possible

[ajeeshvl]

@jlipps thanks for the suggestion. You meant creating test using android.support.test.uiautomator libraries or by sending commands directly to UiAutomator2 server?

[SaneBow]

@ajeeshvl The reason that setting waitForIdleTimeout in appium does not take effect is due to a bug in Android UiAutomator. The setting only applied to UiDevice.waitForIdle() but UiAutomatorBridge.waitForIdle() always use hardcoded value 10s. I am trying to submit a patch to google: https://android-review.googlesource.com/c/platform/frameworks/uiautomator/+/587048

There is also a minor bug in appium-uiautomator2-server related to this. But the major cause is UiAutomator's bug.

My temporary solution is to build android.support.test.uiautomator and use that to build appium-uiautomator2-server. I have verified that this will solve the background hanging issue.

You can try with the binaries I built here. Just install those two apk files before running appium. Make sure version of those apks are the same as that specified in appium-uiautomator2-driver/installer.js, otherwise you need to hack that JS to bypass version checking or hack the apk to change it's versionName.

[Mcfli]

@SaneBow I tried your solution with the binaries you built. I'm still having issues with appium hanging on trying to find an element. I made sure that the installer.js file had the right name/version to match the new files in the uiautomator2 folder. I have set waitForIdleTimeout to 10 in my capabilities and changed the Device.waitForIdle(); to not use timeoutMillis. I still can't get it to not hang on finding an element for a very long time during an animation.

Not sure what else to try here as this issue has been plaguing us for a long time here as well:
appium/issues/8929.

[SaneBow]

@Mcfli Could you post your adb logcat -s UiAutomatorBridge result as well asappium log? Also, did you modify installer.js?

[Mcfli]

@SaneBow Thanks for responding!
Here is the my result from adb logcat -s UiAutomatorBridge.
Here is my Appium Log.

I did not modify installer.js as it looked to me like it already had the right version.
Here is my Installer.js file.

For sanity's sake here is my XPathFinder.java file as well.

[SaneBow]

@MCFil It seems like you didn't set the waitForIdleTimeout correctly. It should be set through Settings API instead of in capabilities. For example, if you are using python client, you can set it as follows:

self.driver = webdriver.Remote('http://localhost:4723/wd/hub', desired_caps)
self.driver.update_settings({
        "waitForIdleTimeout": 3000,  # 3 seconds
})

When you set it correctly, you will see something like this in adb logcat

W UiAutomatorBridge: java.util.concurrent.TimeoutException: No idle state with idle timeout: 500 within global timeout: 3000

[Mcfli]

@SaneBow I appreciate the help. That was my problem with getting it initially set. Although now it looks like that setting is not persisting past the first search attempt.

I set the waitForIdleTimeout setting in the Ruby client using $driver.update_settings(waitForIdleTimeout: 2000). It seems like its using that timeout for the initial attempt on an element search, but then defaults back to 10000. Is there something else I need to change to make it stick with the setting I updated?

All of these log files were after sending one search command button('Finish Game')

Attaching logs here:
adb logcat -s UiAutomatorBridge: here
Appium Log
Full adb locgcat file: here

[ajeeshvl]

@Mcfli Its woking fine for me in java_client
driver.setSetting(Setting.WAIT_FOR_IDLE_TIMEOUT, 0);

I would also suggest you to cleanup uiautomator2 apks from your device and try running test again.

[SaneBow]

@Mcfli It seems to me that you haven't successfully replaced default appium-uiautomator2-server apks with the patched ones. You need to do as follows to install those two apks I provided:

1. Uninstall original uiautomator2

adb uninstall io.appium.uiautomator2.server
adb uninstall io.appium.uiautomator2.server.test

2. Install patched uiautomator2

adb install appium-uiautomator2-server-v0.3.0.apk
adb install appium-uiautomator2-server-debug-androidTest.apk

Once you install them correctly, you should see lines like UiAutomatorBridge.waitForIdle(2000) in the adb logcat.

[ajeeshvl]

@SaneBow Android UIAutomator has an option to set the idle timeout. See the implementation for this in UiAutomator2. https://github.com/appium/appium-uiautomator2-server/blob/cad845dac019af3b71684bd5f21f2c1e87d1880a/app/src/main/java/io/appium/uiautomator2/model/settings/WaitForIdleTimeout.java

[SaneBow]

@ajeeshvl Yes, I am aware of that. The problem is that the setting won't be applied sometimes. This is a bug in google's UiAutomator library. See https://android-review.googlesource.com/c/platform/frameworks/uiautomator/+/587048

[Mcfli]

@SaneBow That definitely did the trick! Thanks for all your help.

[mykola-mokhnach]

There is also disableWindowAnimation capability for UIA2, which might be sometimes quite useful if the application under test has long background animations.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.