I am trying to execute 2.2 test suite, until this point it stopped with the following error:
......
android.content.res.cts.ResourcesTest#testGetAssets...(pass)
android.content.res.cts.ResourcesTest#testGetSystem...(pass)
android.content.res.cts.ResourcesTest#testGetLayout...(pass)
android.content.res.cts.ResourcesTest#testGetBoolean...(pass)
android.content.res.cts.ResourcesTest#testgetFraction...(pass)
android.content.res.cts.ResourcesTest#testParseBundleExtras...(pass)
CTS_INFO >>> Max ADB operations
reached. Restarting ADB...
CTS_INFO >>> Restarting device ...
04:09:28 E/DeviceMonitor: Sending jdwp
tracking request failed!
Device(BABABEEFBABABEEF) disconnected
Test stopped.
I check the result testResult.xml it shows a number of tests not yet executed:
Tests Passed 652
Tests Failed 10 Tests
Timed out 64
Tests Not Executed 23114
What is the reason the test stopped half way like this?
Try setting maxTestCount to 0 in your host_config.xml, as suggested in this post.
Related
After the tap by coordinates action used by W3C, I am trying to call the driver again to find the element and that's when it throws the error.
When I use driver.getpageSource(), it gives me the below error.
GET /session/bda49419-373f-4ae8-8d8e-1537553bf008/source' cannot be proxied to UiAutomator2 server because the instrumentation process is not running (probably crashed). Check the server log and/or the logcat output for more details
When I directly call driver.findElement(), it gives me this error.
An unknown server-side error occurred while processing the command. Original error: 'POST /element' cannot be proxied to UiAutomator2 server because the instrumentation process is not running (probably crashed). Check the server log and/or the logcat output for more details
Build info: version: '4.6.0', revision: '79f1c02ae20'
I was trying to automate the app using the Appium and first step was to call the driver.findElements and then I went to tap by coordinates using w3c actions (PointerOptions),and after the above step, I had driver.findElement() and it gave me the above errors.
EDIT: Below is the original post. It was the initial issue I had ran into, but repeating my steps over and over I am getting different results. The first time I tried to run my shards after posting this, I got:
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':ProgressiveApp:packageInternalStaging'.
> invalid distance too far back
The next time:
> invalid code lengths set
And the next:
> Unexpected end of ZLIB input stream
All three appear to be zip/compression related issues. Perhaps this is my primary issue.
Original post below:
I'm using AndroidX Espresso 3.1.0 along with ANDROIDX_TEST_ORCHESTRATOR. The only issue I have is that when I run shards (to speed up test runs), it sometimes decides to fail for no good reason.
For example, I open three terminals and three emulators. I run one of these in each terminal to kick off three separate shards:
ANDROID_SERIAL=emulator-5554 ./gradlew connectedAndroidTest -Pandroid.testInstrumentationRunnerArguments.numShards=3 -Pandroid.testInstrumentationRunnerArguments.shardIndex=0
ANDROID_SERIAL=emulator-5556 ./gradlew connectedAndroidTest -Pandroid.testInstrumentationRunnerArguments.numShards=3 -Pandroid.testInstrumentationRunnerArguments.shardIndex=1
ANDROID_SERIAL=emulator-5558 ./gradlew connectedAndroidTest -Pandroid.testInstrumentationRunnerArguments.numShards=3 -Pandroid.testInstrumentationRunnerArguments.shardIndex=2
This then runs a third of my tests on each emulator. So good so far. After a long time, they're all done and I have a nice HTML report telling me zero tests failed. I haven't touched my code, I haven't touched the emulators. I go to touch each of the terminals. In each I hit the up arrow to grab the last command ran in that terminal, and then enter to rerun exactly what I just ran. Two of the emulators are fine and run through all their tests. The third does not, and gives me this error message below:
> Task :<snip>:connectedInternalStagingAndroidTest FAILED
[no message defined]
java.lang.RuntimeException: com.android.builder.testing.api.DeviceException:
com.android.ddmlib.InstallException: INSTALL_FAILED_INVALID_APK
at java.util.concurrent.ForkJoinTask$AdaptedCallable.exec(ForkJoinTask.java:1431)
at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289)
at java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1056)
at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1692)
at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:157)
Caused by: com.android.builder.testing.api.DeviceException: com.android.ddmlib.InstallException: INSTALL_FAILED_INVALID_APK
at com.android.builder.testing.ConnectedDevice.installPackage(ConnectedDevice.java:132)
at com.android.builder.internal.testing.SimpleTestCallable.call(SimpleTestCallable.java:147)
at com.android.builder.internal.testing.SimpleTestCallable.call(SimpleTestCallable.java:59)
at java.util.concurrent.ForkJoinTask$AdaptedCallable.exec(ForkJoinTask.java:1424)
... 4 more
Caused by: com.android.ddmlib.InstallException: INSTALL_FAILED_INVALID_APK
at com.android.ddmlib.Device.installRemotePackage(Device.java:1031)
at com.android.ddmlib.Device.installPackage(Device.java:902)
at com.android.ddmlib.Device.installPackage(Device.java:880)
at com.android.ddmlib.Device.installPackage(Device.java:869)
at com.android.builder.testing.ConnectedDevice.installPackage(ConnectedDevice.java:126)
... 7 more
Why? How? It doesn't make any sense. I hit up and enter again and then it happily runs through all the tests without issue.
My problem is that this random failure happens enough I can't set up my machines to use sharding, and therefore cannot speed up the test running process for my team.
When I ran "run vts -m VtsHalWifiSupplicantV1_0Target", I get 0 result from it.
vts-tf > run vts -m VtsHalWifiSupplicantV1_0Target
...
10-15 09:56:06 I/ResultReporter: Invocation finished in 48s. PASSED: 0, FAILED: 0, MODULES: 2 of 2
Do I need to write some code to run the vts test case?
I expected to get something passed or failed. How can I get results?
Thanks in advance.
There are at least two reasons why a VTS test run would have that result.
The HAL Testability Checker decided to skip the test. This could be because the HAL you want to test is not running on the target or you try to run an x86 test on an x64 platform.
vts-tradefed will call the test binary with the --gtest_list_tests option in order to get the amount of tests. If this call fails vts-tradefed will assume you have zero test cases.
In any case you can get more information by checking the host logs.
zcat $ANDROID_HOST_OUT/vts/android-vts/logs/latest/inv_*/host_log*.txt.gz | less
I've been successfully running Robolectric unit tests under the debugger in Android Studio since version 0.6.1
Now I am unable to and get the following error
ERROR: transport error 202: connect failed: Connection refused
ERROR: JDWP Transport dt_socket failed to initialize, TRANSPORT_INIT(510)
JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports initialized [../../../src/share/back/debugInit.c:750]
Could not write standard input into: Gradle Test Executor 1.
java.io.IOException: Broken pipe
I have always set the use in-process build flag unchecked in the compile settings and although I am currently using AS 0.8-14, I have gone back and tried 0.8-11, 0.8-9 and 0.6-1 and none of them work now. I'm using android build tools version 19.1.0 (and have been for some time and it does work with them).
Could it be some local security setting under Mac OS X? Any assistance would be gratefully received.
** Update **
I have discovered that the issue is caused by running an additional JavaExec task before running the unit test tasks. It seems that gradle is running the JVM for the first task and passing debug arguments to it e.g. -agentlib:jdwp=transport=dt_socket,server=n,suspend=y,address=49807 The task completes and the JVM exits. Gradle then runs the actual unit test and expects the new JVM to listen on the same port for the debugger to connect - which it doesn't and so the connection failure arises.
How can I either prevent the prior task (an ormlite database compile task) from running under the debugger or force gradle to recognise that the unit test task will run using a new JVM and so change the jvmArgs for the unit test to reflect the new debug port?
I fixed this by changing the database compilation task to be an Exec task rather than a JavaExec task. The exec task was defined as follows and so executed the database compilation as an external java process, not a gradle invoked one. This prevented the debug JVM being 'consumed' by the database compilation task.
task (taskName type: Exec) {
def mainClass = "com.some.class"
def classPath = "${buildDir}/intermediates/classes/${flavorName}/${buildType.name}" + ":" + configurations.databaseCompile.asPath
commandLine "java", "-cp", classPath, mainClass, configDirName
}
I summon the Android NDK debugging Ninjas here!
I've tried so many tutorials about debugging Android native code, so I can't remember them all.
Now I'm trying to get ARM DS-5 work. I've made it work with the Android NDK samples, where the main Activity loads the library. Laggy, but works.
But my project is a little bit complicated. My Main Activity has a button, when I tap it, SubActivity is launched, and it loads native lib. When I just try to use the DS-5 debugger, when Main Activity is loaded, I suppose debugger tries to connect to lib, but fails, saying:
Execution stopped at: 0xAFD0C52C
Connected to unknown platform
0xAFD0C52C POP {r4,r7}
file "D:\workspace\Project\bin\app_process"
WARNING(IMG53): app_process has no line debug information
add-symbol-file "D:\workspace\Project\bin\libc.so"
Loading library symbols: libc.so
WARNING(IMG53): libc.so has no line debug information
Execution stopped at: 0xAFD0C748
In thread 2 (OS thread id 7606)
In __futex_syscall3 (no debug info)
add-symbol-file "D:\workspace\Project\obj\local\armeabi\libName.so"
Execution stopped at: 0xAFD0C748
In thread 3 (OS thread id 7607)
Execution stopped at: 0xAFD0BFFC
In thread 4 (OS thread id 7608)
In __rt_sigtimedwait (no debug info)
Execution stopped at: 0xAFD0B854
In thread 5 (OS thread id 7609)
In select (no debug info)
Execution stopped at: 0xAFD0C748
In thread 6 (OS thread id 7610)
In __futex_syscall3 (no debug info)
Execution stopped at: 0xAFD0B70C
In thread 7 (OS thread id 7611)
In __ioctl (no debug info)
Execution stopped at: 0xAFD0B70C
In thread 8 (OS thread id 7612)
Execution stopped at: 0xAFD0C52C
In thread 1 (OS thread id 7605)
In epoll_wait (no debug info)
0xAFD0C52C POP {r4,r7}
WARNING(CMD454): The shared library D:\workspace\Project\obj\local\armeabi\libName.so is currently not loaded by the application so the request has been pended
cd "D:\workspace"
Working directory "D:\workspace"
directory "D:\workspace\Project"
Source directories searched: D:\workspace\Project;$cdir;$cwd;$idir
break -d -p "D:\workspace\Project\jni\Name.cpp":525
WARNING(CMD452-COR167):
! Breakpoint 1 has been pended
! No compilation unit matching "D:/workspace/Project/jni/Name.cpp" was found
condition 1
break-script 1 ""
ignore 1 0
break-stop-on-threads 1
unsilence 1
Breakpoint 1 unsilenced
I think that it tries to connect to native lib when Main Activity starts. But library is loaded later!
What I tried:
Setting Java breakpoint in SubActivity, after native lib was loaded,
then attaching DS-5 debugger. But I get various errors from Eclipse
saying about timeouts, whatever.
In the debug config settings I can't
select the activity, which should trigger debugging of native code,
there's combobox, but it's disabled:
The question itself: if my lib is not loaded by main Activity, how do I make DS-5 wait for lib to load?
Do you really need to have exact behaviour between debug and release version ?
If not, load the library in the main activity, too in debug version.