uiautomator icon indicating copy to clipboard operation
uiautomator copied to clipboard

"RPC server not started" persistant issue with only certain devices

Open aristeia opened this issue 7 years ago • 24 comments

Hi, I've reviewed some of the other issues surrounding the "RPC server not started" error, but none seem to get at the issue I'm encountering. My issue is that a small number of device models will always return the "RPC server not started" error. Despite successfully using UIAutomator with 20+ device models on Ubuntu 16.04 running python3, I've found that my two ZTE Z981 devices won't connect with UIAutomator. Reinstalling the APKs and jars on the phones didnt help. I'll look more into whatever logs they have, and post them on here.

aristeia avatar Apr 05 '17 17:04 aristeia

I have similar issues with Samsung devices from variety of range. A5, S6 (edge, edge+), S7 etc, basically new ones. UiAutomator starts running test cases but somehow it freezes totally and only way is to unplug device from the USB and/or re-enable USB debugging from the dev options.

As a reference; S5 Neo works like a charm and also top tier Samsung Tablets.

Also seems that there are issues with ADB since 'adb devices' shows device as 'offline'.

soppag avatar Apr 06 '17 15:04 soppag

Hey @soppag, I'm not sure if this is the same issue. My S6 edges and edge+s, as well as S7s have never frozen during a test case. Try looking into your connection to those devices, the cables, ports, etc, since it sounds like something is disconnecting them during the tests.

aristeia avatar Apr 06 '17 22:04 aristeia

@soppag Update adb. That may resolve the issue

siva-kranthi avatar Apr 07 '17 11:04 siva-kranthi

I's error while installing the test apk, and I check the code, in the method "install"(init.py): "self.adb.cmd("install", "-r -t", os.path.join(base_dir, apk)).wait()" I think it should be "self.adb.cmd("install", "-r", "-t", os.path.join(base_dir, apk)).wait()"

And it is OK after I modify this code.

snakeli avatar Apr 10 '17 03:04 snakeli

After changing as  @snakeli suggested (Cheers mate!), i've been able to run automation with S7 edge+

This should be fixed in repo asap.

soppag avatar Apr 10 '17 07:04 soppag

Unfortunately, that fix didnt solve my original issue :(

The APK is probably installing correctly for me, but the issue is in the APK starting and communicating with ADB over this "RPC server".

I've checked ADB's logs, and found that all the same relevant UIAutomator stuff runs on the non-working phone as a working phone. The last line in common they both run is:

TestRunner: started: testUIAutomatorStub(com.github.uiautomator.stub.Stub)

After this line, a working phone will then print some JSON objects relevant to the RPC requests like ping(), but the nonworking phone will never print any more relevant stuff.

aristeia avatar Apr 10 '17 17:04 aristeia

Also did some other platform debugging, and replicated the error with Python2.7 and on macOS, so it's definitely an issue isolated to the ADB-UIAutomator stack

aristeia avatar Apr 10 '17 17:04 aristeia

Hi @aristeia , Maybe below link's infomation can help you. http://p.codekk.com/detail/Android/xiaocong/uiautomator

After install the APKs,

  1. adb shell am instrument -w com.github.uiautomator.test/android.support.test.runner.AndroidJUnitRunner
  2. adb shell curl -d '{"jsonrpc":"2.0","method":"deviceInfo","id":1}' localhost:9008/jsonrpc/0 By this , you can check whether the server is alive.

There's only one place where will raise "RPC server not started" error in this code: def start(self, timeout=5): ... if not self.alive: raise IOError("RPC server not started!") If you install the APKs correctly, maybe that's because your DUT kill the server, check your adb log.

snakeli avatar Apr 11 '17 11:04 snakeli

Thanks for the suggestion. I've ran into some problems with adb's curl command where it doesnt parse the command line option for data properly:

$ adb shell curl -d '{"jsonrpc":"2.0","method":"deviceInfo","id":1}' -v localhost:9008/jsonrpc/0

  • Rebuilt URL to: method:deviceInfo/
  • getaddrinfo(3) failed for method:80
  • Couldn't resolve host 'method'
  • Closing connection 0 curl: (6) Couldn't resolve host 'method'
  • Rebuilt URL to: id:1/
  • getaddrinfo(3) failed for id:1
  • Couldn't resolve host 'id'
  • Closing connection 1 curl: (6) Couldn't resolve host 'id'
  • Trying 127.0.0.1...
  • Connected to localhost (127.0.0.1) port 9008 (#2)

POST /jsonrpc/0 HTTP/1.1 Host: localhost:9008 User-Agent: curl/7.50.1-DEV Accept: / Content-Length: 11 Content-Type: application/x-www-form-urlencoded

  • upload completely sent off: 11 out of 11 bytes` < HTTP/1.1 200 OK < Content-Type: application/json < Date: Tue, 11 Apr 2017 19:27:03 GMT < Connection: keep-alive < Content-Length: 81 <
  • Connection #2 to host localhost left intact {"jsonrpc":"jsonrpc","id":"null","error":{"code":-32700,"message":"Parse error"}}

I tried it with the --header option too, and it parsed the header the same way, interpreting it as a host. I even tried replacing all the quotes with double quotes, then escaping them in the JSON, but even then curl misinterpreted the data option.

Anyway, from what I said before, I've looked over ADB's logs, and it doesnt appear that the server is being killed. If I can get this curl command working, I could probably debug this a bit more deeply :)

aristeia avatar Apr 11 '17 19:04 aristeia

Got it working! I enclosed all the arguments in a big single-quotes quote, and it works fine. The non-working phone returns a response just as quickly as a working phone:

$ adb shell curl '-d "{\"jsonrpc\":\"2.0\",\"method\":\"ping\",\"id\":1}" -v --header "ContentType: application.json"' localhost:9008/jsonrpc/0

  • Trying 127.0.0.1...
  • Connected to localhost (127.0.0.1) port 9008 (#0)

POST /jsonrpc/0 HTTP/1.1 Host: localhost:9008 User-Agent: curl/7.43.0-DEV Accept: / ContentType: application.json Content-Length: 40 Content-Type: application/x-www-form-urlencoded

  • upload completely sent off: 40 out of 40 bytes < HTTP/1.1 200 OK < Content-Type: application/json < Date: Tue, 11 Apr 2017 19:36:31 GMT < Connection: keep-alive < Content-Length: 40 <
  • Connection #0 to host localhost left intact {"jsonrpc":"2.0","id":1,"result":"pong"}

I'll do a bit more debugging around why in the python code we don't get a response, despite the server being online and serving responses to curl. Thanks again @snakeli

aristeia avatar Apr 11 '17 19:04 aristeia

I've found that, when running an instance of uiautomator, I get the following results when trying to ping() ports:

working phone:

pinging the local port pinging the device port
through the command line with curl Failed to connect to localhost port 9009: Connection refused Works
letting python/uiautomator do it Works [Errno 111] Connection refused

non-working phone:

pinging the local port pinging the device port
through the command line with curl Failed to connect to localhost port 9009: Connection refused Works
letting python/uiautomator do it [Errno 111] Connection refused [Errno 104] Connection reset by peer

For reference, the local port is the port though which UIAutomator sends post requests to the device. When we ping this port, I think it should work regardless of if we're using python/uiautomator or the command line.

aristeia avatar Apr 12 '17 01:04 aristeia

Seems that the install method workaround wasn't the solution - seems that if you just leave the device attached to USB for longer period like overnight. Next morning none of the adb commands work. you basically have to restart adb server.

After restarting adb server - 'adb devices' shows my device as offline.

Only solution to get it back online is to unplug USB and put it back on.

soppag avatar Apr 12 '17 03:04 soppag

Seems that ADB really gets stuck if you just have device attached to USB and instrument(s) running AndroidJUnitRunner with S6 edge+

ADB version: Android Debug Bridge version 1.0.39 Revision 5943271ace17-android

UIAutomator version (0.2.7) + patched self.install

soppag avatar Apr 13 '17 11:04 soppag

upgrade UIAutomator. Latest version is 0.3.2

siva-kranthi avatar Apr 13 '17 13:04 siva-kranthi

We also observed same issue with some of the devices which has initially rlsed android binaries like N. Not sure exactly what was the issue. But seems to work after few days with new binaries

siva-kranthi avatar Apr 13 '17 13:04 siva-kranthi

Seems that 0.3.2 version is much more slower when executing test case. Ui clicks etc. are very slow compared to 0.2.7. Any idea?

soppag avatar Apr 19 '17 05:04 soppag

I meet same problem , and resolved it . I find "def stop()" in init.py do not worked, maybe beacause of my phone is not rooted, so i change it as : def stop(self): package_names = ["com.github.uiautomator","com.github.uiautomator.test"] for pkg in package_names: self.adb.cmd("uninstall", pkg).wait() when meet rpc service stoped, will uninstall apks, than reinstall. so , rpc service can be restarted.

yanglikai0806 avatar Apr 24 '17 02:04 yanglikai0806

@yanglikai0806 Unfortunately I've already tried this. From another thread about the RPC server not starting, they mention some ADB commands to manually uninstall and reinstall the uiautomator apk and other apks, but that didnt help my problem :(

aristeia avatar Apr 26 '17 00:04 aristeia

@snakeli that code change worked like a charm, you're a wizard.

craftpip avatar Jan 12 '18 08:01 craftpip

I also meet offline problem. uiautomator version is 0.3.2 .

willysys avatar Apr 04 '18 07:04 willysys

Hello,

I have the same problem with different products (Huawei P20, Xiaomi Redmi 5, Huawei Y6 2018...). ADB version : Android Debug Bridge version 1.0.40 Version 4986621 uiauomator version: 0.3.2

error: raise IOError("RPC server not started!") OSError: RPC server not started!

lmario35 avatar Oct 09 '18 11:10 lmario35

I have the same issue and I observed the issue for all Android Pie devices. The issue was not reproducible on Android Nougat. Not Sure why..

AgasthyaT avatar Sep 09 '20 11:09 AgasthyaT

Who can help me ? I see the same situation

whyslience avatar Nov 17 '23 11:11 whyslience

  1. It seems it is a floating issue and it is related to device initialization via adb
  2. It can be bypassed by adding additional "adb connect" call from cli. In this case workaround looks like:
from uiautomator import Device
import os

device = "192.168.88.238"

result = os.popen(f'adb connect {device}').read()
d = Device(f'{device}:5555')
print(d.dump())

pmb-itz avatar Nov 24 '23 13:11 pmb-itz