UiAutomator died while responding to command


Recently while working on one of the Appium automation framework, we noticed this error:

"org.openqa.selenium.WebDriverException:  UiAutomator died while responding to command, 
please check appium logs! (WARNING: The server did not provide any stacktrace information)

Let me explain the framework we have. The framework is using Cucumber + Appium + Gradle. So the
test are written in feature file in plain english and in turn talk to step implementation which calls the page
class for any action. We also have some utils written which basically captures the screenshot of the device
on the step of failure and captures the adb log of the device. But in this case of error there was no snapshot
 taken. Also we are running the tests in parallel and are not using Selenium grid, we have our own custom
solution to take care of it.

Couple of guess what we made:
  • We suspected the issue to be session related and we tried the override session flag while starting appium server, but this didn’t fix it.
  • We switched from Genymotion emulator to run the test on actual device and even that didn’t fix it.
  • We changed the ADB from Genymotion to explicit machine installed one and even that didn’t solve it.
Lastly while seeing the execution carefully on both the device and almost after 3-4 runs, we found that when the network toggle test used to run the other device lost the connection or became un-reachable. I could see the device awake and the cursor blinking on the text box but device was in a state of wait till the new command time out happens and then it used to throw the error "UiAutomator died”.

So the actual culprit is the network toggle test running in parallel which caused it. 

Build info: version: '2.48.2', revision: '41bccdd10cf2c0560f637404c2d96164b67d9d67', time: '2015-10-09 13:08:06'
System info: host: 'xxxx-Mac-mini.local', ip: 'x.x.x.x', os.name: 'Mac OS X', os.arch: 'x86_64', os.version: '10.11.2', java.version: '1.8.0_74'
Driver info: io.appium.java_client.android.AndroidDriver
Capabilities [{app=/private/var/lib/jenkins/workspace/AndroidConsumerApp/x-x/SmokeTestSuite/app/app-staging-release.apk, appPackage=com.x.x.x, networkConnectionEnabled=true, noSign=true, warnings={}, databaseEnabled=false, deviceName=x, launchTimeout=50000, platform=LINUX, appActivity=com.x.x.x.x, stopAppOnReset=false, desired={app=/private/var/lib/jenkins/workspace/AndroidConsumerApp/x/SmokeTestSuite/app/app-staging-release.apk, appPackage=com.x.app.staging, appActivity=com.x.app.Splash, stopAppOnReset=false, noSign=true, newCommandTimeout=30, platformVersion=null, platformName=Android, udid=x, deviceName=Android, launchTimeout=50000, autoAcceptAlerts=true}, newCommandTimeout=30, platformVersion=4.4.2, webStorageEnabled=false, locationContextEnabled=false, browserName=Android, takesScreenshot=true, javascriptEnabled=true, platformName=Android, udid=x, autoAcceptAlerts=true}]
Session ID: 4ce65c07-1f16-4f6c-aedd-7357e081c4a1
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at org.openqa.selenium.remote.ErrorHandler.createThrowable(ErrorHandler.java:206)
at org.openqa.selenium.remote.ErrorHandler.throwIfResponseFailed(ErrorHandler.java:158)
at org.openqa.selenium.remote.RemoteWebDriver.execute(RemoteWebDriver.java:647)
at io.appium.java_client.DefaultGenericMobileDriver.execute(DefaultGenericMobileDriver.java:42)
at io.appium.java_client.AppiumDriver.execute(AppiumDriver.java:1)
at io.appium.java_client.android.AndroidDriver.execute(AndroidDriver.java:1)
at org.openqa.selenium.remote.RemoteWebElement.execute(RemoteWebElement.java:326)
at io.appium.java_client.DefaultGenericMobileElement.execute(DefaultGenericMobileElement.java:44)
at io.appium.java_client.MobileElement.execute(MobileElement.java:1)
at io.appium.java_client.android.AndroidElement.execute(AndroidElement.java:1)
at org.openqa.selenium.remote.RemoteWebElement.sendKeys(RemoteWebElement.java:121)
at sun.reflect.GeneratedMethodAccessor15.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.openqa.selenium.support.pagefactory.internal.LocatingElementHandler.invoke(LocatingElementHandler.java:51)
at com.sun.proxy.$Proxy15.sendKeys(Unknown Source)
at pages.BasePage.sendKeys(BasePage.java:121)
at pages.HelpPage.enterHelpText(HelpPage.java:51)
at steps.HelpPageSteps.onHelpPageIAskForHelpText(HelpPageSteps.java:30)
at ✽.When On Help Page I ask for help My bank card is not working and I tried reaching customer care(X.feature:20)

Popular posts from this blog

Defect Tracking System – Wastage of Money & Time ???

Image
As a QA I have been logging bugs since 5 years. But what do we do with that ? A typical flow: If this is the only thing we need to do then why taking so much of pain to have a defect tracking system . To log a standard bug (Standard Bug= Broken Functionality), we need to write steps to reproduce, pre-requisites (if any), expected result, actual result, priority, severity, snapshot (if any), Test environment details and finally save it. This takes around roughly 3-5 minutes to log a bug. To say truth, I have never seen any report coming out of defect tracking system which is of use in analyzing the pattern of bug or finding out any trend in them. All I have seen apart from tracking usage, is the summary of bugs with count based on Priority and Severity. Is that the only purpose of Defect Tracking System? If that is the case then why not use a Google spreadsheet rather then investing money of the company and time of QA in a bug logging system. I am sure if we mine the data which i
Read More »

The 3 qualities that will always help you become better at almost anything…

Image
Have we ever noticed how excited we are when we start anything? But it’s a sad fact that 70% of people abandon what they have started with so much energy and love. It could be as small as building a hobby or starting a pet project or even an activity or a side learning we started. “ Well begun is half done .” Aristotle did say this but we are judged for how we have finished something. You separate yourself fro m  the masses when you choose to give that task a finish.  The first quality is finishing off what you started and it helps develop mental stamina or willpower.   It builds confidence and inculcates as a habit in a long run. You don’t need to sign up for the mammoth activity to build this habit, even finishing mundane day-to-day routine tasks will help. Diligence — the quality of working carefully and with a lot of effort Diligence is a quality that almost never will get unnoticed. It’s one of the underlying traits of great works or success. The key to mediocrity on the o
Read More »

Test Case Paths : Happy, Sad & Bad

Image
I came back from the background of writing test cases which were categorized in either Positive or Negative test cases. Positive test cases were business flows which may or may not give any result but they will certainly not give any exception or error. Negative test cases are those test cases which were bound to result into some exception or better expressed as error causing scenarios.  Then those positive test cases were prioritized as High/Medium/Low . Finally it used to result in quite a comprehensive test case document. Then it will go through the process of review and few more updates or change of priority etc. Certainly it is a tedious process. Here in ThoughtWorks I got introduced to different way of categorizing test cases called “ Happy/Sad/Bad ”. A test case which results you in a positive result is a Happy path , for e.g. entering proper username and password on login page. A test case which yields no result like entering invalid username and invalid password on a logi
Read More »