Connection Refused on simple example

TomOke commented 7 years ago

I have been experiencing the Connection Refused, with the simple two-line example of: JadbConnection jadb = new JadbConnection(); List devices = jadb.getDevices();

This is on a Raspberry Pi3 in which if have installed the adb tools through apt-get and can access the android device through adb and get a shell
I built jadb through the maven POM and included it's jar output as an external jar to an Eclipse project.
I also get a connection refused with a "telnet localhost 5037" command
using Oracle Java 8

This suggests that I might have some form of permissions incorrect, by default, but I don't know what that might be.

Any suggestions?

Thanks in advance - Tom

vidstige commented 7 years ago

Hmm, interesting. Perhaps adb is not connecting to localhost at all. Or the adb-server is not running.

First make sure server is running by adb start-server. If it does help, please paste the output of the following

adb version
cat /etc/hosts
ifconfig

Also what version of jadb are you using?

ohtejera commented 7 years ago

@TomOke

I think that the official adb compiled for ARM uses Unix Socket instead of TCP/IP Socket.

You can try with this version of adb that use TCP Socket on ARM. You can get the adb binary here.

Regards. Henry

TomOke commented 7 years ago

That was the winner. It was using Unix sockets. I saw that netstat gave me a reference of /tmp/../5037, but did not know that that meant Unix sockets til I did more searching.

The supplied adb binary started a server that then worked perfectly for what I wanted. I am using jadb to access the device from a Java application.

Thanks very much.

vidstige commented 7 years ago

@ohtejera thanks for resolving this

@TomOke glad you got it working! :-) Is there anything we can put in the README or elsewhere to make this easier to avoid for other people?

TomOke commented 7 years ago

I would suspect that the best that could be said to those getting the "Connection Refused" is that it is possible that your adb is using Unix Sockets, rather than TCP/IP sockets.

A check could be:

does an ls of /tmp show: /tmp/5037 (or the port you get when you do adb start-server)
If you do not have adb running (like "adb shell") do you see: "netstat | grep 5037" returning anything.
If you have adb running (like "adb shell") do you see a line like: $ netstat | grep 5037 unix 3 [ ] STREAM CONNECTED 99513 /tmp/5037 If so your implementation of adb is using Unix Sockets. At that point a reference could be made to @ohtejera's adb source/binary. But that would get out-of-date fairly quickly.

I tried using the "connect localhost:5037", which the ADB usage indicates is supposed to to TCP/IP, but it also gave me a UNIX /tmp/5037 file.

A similar comment/question can be found at: https://lists.linaro.org/pipermail/linaro-android/2015-February/002677.html

I have not tried something like: https://github.com/kohlschutter/junixsocket which is supposed to be a Unix Sockets implementation for Java which extends the Java Socket implementations and might just slice in there through reflection.

Certainly pointing me at the Unix/TCP variation and the Unix adb implementation was great and I am grateful. It might be interesting to find how frequently an ADB might be Unix or be TCP/IP.

vidstige commented 7 years ago

I think the fix will be two fold.

Just update readme with relevant parts as supplied by you. (Could I ask you to make a pr? Just reuse your writeup above? You have great pedagogical skill.)
Use junixsocket or similar library. It would then require jini or some way of calling native. Therefore it would be great if transport layer could be injected so that you do not need external jini libs on platforms that does not need it, and cannot run them such as windows.

vidstige commented 7 years ago

After further looking into this, I don't think adding support for the JUDS library would be too time consuming.

TomOke commented 7 years ago

That would certainly add to the flexibility of the utility and make it accessible to all. With the README update for people to recognize that they needed the JUDS jar if they see the connect error, and the possibility that jadb could recognize that it is in the UNIX sockets environment it would cover just about anything.

From: "notifications" notifications@github.com To: "vidstige/jadb" jadb@noreply.github.com Cc: "Tom Oke" oket@shaw.ca, "State change" state_change@noreply.github.com Sent: Monday, December 19, 2016 12:26:42 PM Subject: Re: [vidstige/jadb] Connection Refused on simple example (#45)

After further looking into this, I don't think adding support for the JUDS library would be too time consuming.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub , or mute the thread .

TomOke commented 7 years ago

Just found: http://stackoverflow.com/questions/17638919/adb-not-running/37603398#37603398

This seems to have a resolution that would only require you to install socat and then run the command: socat TCP-LISTEN:5037,reuseaddr,fork UNIX-CONNECT:/tmp/5037

This seemed to do the trick for me so that it would handle both the Unix and the TCP/IP sockets and no code changes.

vidstige commented 7 years ago

Perfect, thanks. I've updated the readme. See 0cb9550

SKART1 commented 7 years ago

Why do not start adb server with TCP socket as transport layer instead of using socat?

TomOke commented 7 years ago

I had tried to start the Adb that I installed into the Raspberry Pi in TCP/IP mode (at least the help doc indicated it should start in TCP/IP) and I got a Unix socket. The adb provided by @ohtejera resolved the starting on the Raspberry but we were looking for a more universal mechanism so that different platforms could be addressed. I am not sure which platforms you might get a Unix Socket on, which you might get a TCP/IP, and which, like the raspberry might suggest that you could get TCP/IP, but you get Unix.

vidstige commented 7 years ago

@SKART1 sounds like a great workaround. How do you start adb server in TCP mode?

SKART1 commented 7 years ago

What distro have you used on Pi? Was adb preinstalled?

There is -P - Port of adb server (default: 5037) flag which allows to specify on which TCP port actually to start I am really surprised that adb is rewritten to use unix sockets instead of tcp...

TomOke commented 7 years ago

I believe that the distro was a NOOBS install, with a 4.4.34-v7+ kernel. The adb was installed through: sudo apt-get install android-tools-adb

With this adb the following sequence results in a UNIX socket rather than the expected TCPIP socket.

pi@raspberrypi:~ $ adb kill-server pi@raspberrypi:~ $ rm /tmp/5037 pi@raspberrypi:~ $ adb tcpip 5037

daemon not running. starting it now on port 5037 *
daemon started successfully * pi@raspberrypi:~ $ netstat | grep 5037 pi@raspberrypi:~ $ netstat | grep 5037 unix 3 [ ] STREAM CONNECTED 145222 /tmp/5037

The second netstat, returning the unix 3 response is after starting an adb shell in another terminal.

The command: $ adb -P 5037 shell

daemon not running. starting it now on port 5037 *
daemon started successfully * shell@manta:/ $

Resulted in a netstat of:$ netstat | grep 5037 unix 3 [ ] STREAM CONNECTED 147921 /tmp/5037

So I haven't been able to get it to do a TCP/IP socket for me.

SKART1 commented 7 years ago

sudo apt-get install android-tools-adb - is not best place to get android sdk, because they are commonly extremely old (as all soft in repositories), better to download them directly from android website. You may take some ideas from this Dockerfile - just remove docker specific command after #android-sdk

Returning to your case: adb tcpip 5037 - is not what you are searching for - it restarts adbd (which runs on android device) rather than restarting android server as for adb -P 5037 shell - I get this:

lsof -i | grep 5037
adb      6561  art    6u  IPv4 186702      0t0  TCP localhost:5037 (LISTEN)

SKART1 commented 7 years ago

I have one idea - may be you are running adb daemon, adb server and adb client on same host? May be unix socket is socket occupied by adb daemon as a resut of adb tcpip 5037?

Could you please lsof -i | grep 5037?

TomOke commented 7 years ago

I am using 4.4.32-v7+ (probably from a NOOBS card) and installed the adb through apt-get. The command line that installed was: sudo apt-get install android-tools-adb android-tools-fastboot

When I run this installed verson (renamed adb-unix) with the option to start a tcpip port, I end up getting a Unix port. The file /tmp/5037 was deleted prior to running this command and netstat indicates:

$ adb-unix tcpip 5037

daemon not running. starting it now on port 5037 *
daemon started successfully * error: device not found pi@raspberrypi:/usr/bin $ ls /tmp/5037 /tmp/5037

TomOke commented 7 years ago

I get: $ lsof | grep 5037 adb-unix 7248 pi 5u unix 0xb8873300 0t0 22312 /tmp/5037 adb-unix 7248 pi 11u unix 0xadadd200 0t0 25974 /tmp/5037 adb-unix 7248 7249 pi 5u unix 0xb8873300 0t0 22312 /tmp/5037 adb-unix 7248 7249 pi 11u unix 0xadadd200 0t0 25974 /tmp/5037 adb-unix 7248 7251 pi 5u unix 0xb8873300 0t0 22312 /tmp/5037 adb-unix 7248 7251 pi 11u unix 0xadadd200 0t0 25974 /tmp/5037 adb-unix 7248 7252 pi 5u unix 0xb8873300 0t0 22312 /tmp/5037 adb-unix 7248 7252 pi 11u unix 0xadadd200 0t0 25974 /tmp/5037

With an "adb shell" running.

After a kill-server, lsof shows no 5037 ports.

Then an "adb -P 5037 shell" gives me a shell with the following lsof.

$ lsof | grep 5037 adb-unix 7304 pi 7u unix 0xb93e6a00 0t0 47727 /tmp/5037 adb-unix 7304 pi 11u unix 0xb934cf00 0t0 47733 /tmp/5037 adb-unix 7304 7305 pi 7u unix 0xb93e6a00 0t0 47727 /tmp/5037 adb-unix 7304 7305 pi 11u unix 0xb934cf00 0t0 47733 /tmp/5037 adb-unix 7304 7307 pi 7u unix 0xb93e6a00 0t0 47727 /tmp/5037 adb-unix 7304 7307 pi 11u unix 0xb934cf00 0t0 47733 /tmp/5037 adb-unix 7304 7308 pi 7u unix 0xb93e6a00 0t0 47727 /tmp/5037 adb-unix 7304 7308 pi 11u unix 0xb934cf00 0t0 47733 /tmp/5037

So I don't think I am going to get a TCP/IP port without changing the adb that installed by default. I will give a shot at the suggested install from the Android site, and see what I get.

vidstige commented 7 years ago

Thanks for looking into this, if you got a few minutes over, please try out a later version of adb. It would be sweet to close this issue. :+1:

SKART1 commented 7 years ago

adb-unix tcpip 5037 - actually starts adb daemon, not server!

Nevertheless it looks true that adb from ditro repositories starts adb server on unix sockets...

@vidstige you would like to put unix-socket implementation in this project? Be very attentive, cause I personally do not know good modern library for java....

TomOke commented 7 years ago

I extracted the essentials to build the android sdk from the docker file, but it stumbled with ANDROID_SWT, which it expected to have as:

SWT folder '/opt/android-sdk-linux/tools/lib/arm' does not exist. Please export ANDROID_SWT to point to the folder containing swt.jar for your platform.

And the downloaded hierarchy does not have such folder in tools/lib. Seems to be for an x86. I'll take a look at seeing about building for raspberry. I'll go through the stuff in the article: http://forum.xda-developers.com/showpost.php?p=32632468&postcount=41

SKART1 commented 7 years ago

@TomOke I hopy you are not building adb on raspberry? Cause it will take ages...

As @ohtejera proposed - use binary

You can try with this version of adb that use TCP Socket on ARM. You can get the adb binary here.

If you want to build it by hand - do it on PC, it is real, but not trivial (I accidentally doing same now)

TomOke commented 7 years ago

As noted above @ohtejera's adb binary had already worked for me. I was thinking of trying the other article's reference which seemed directed to the Raspberry.

Somethings it is actually fun to see how hard you can push a Raspberry Pi3, with its quad cores. The linux distro is about an hour or so to build. I figure I could do the Android AOSP within a couple of days if it compares to the PCs I have already done it on.

Now I strongly suspect I would need to change my 64GB SD-Card and get a 128GB or 256GB one, and I don't think I could do multiple cores without running out of ram, but that is the fun of it, to see what you can get with this small, but suprisingly powerful machine. I also have it heat-sunk on a FLIRC case so I can run all 4 cores at 100% and not overheat.

SKART1 commented 7 years ago

@TomOke you may try to download adb executable from android site

It is not obligattory to build source code for some system on the same system! =) It is sometimes easier, but not obligatory

Folder with source enough to build adb was 51 Gb on my machine (may be not minimum - I just downloaded practically all) and adb alone was builded in 5 minutes But ask builded 5 hours and even not succeede - so good luck in your tries!

vidstige commented 7 years ago

Gentlemen I want to close this. Where did we end up? Do we need code and/or documentation changes? Or are we currently good? Note, for special cases this issue will be searchable by google.

SKART1 commented 7 years ago

I think we may add some remark showing how to check if your adb server is running in UNIX socket mode - may be in FAQ or troubleshooting section of README.md

vidstige commented 7 years ago

@SKART1 I read through the thread, but still unsure on how to detect this? First start a shell and then do lsof seems like the best way to go, am I right?

SKART1 commented 7 years ago

@vidstige - yes you are right

I confirm that raspbian installed via noobs raspberry pi utility has in its repositories package android-tools-adb. This package has android debug bridge command which behaves differently than standard one from develope.android.com - it uses Unix Domain Sockets instead of TCP sockets. It ignores flag -a when it starts. And it seems for me - that it is a bug

As for @ohtejera suggestion - his adb binary start adb server which use tcp socket - and all is ok, except that this version do not support -a flag which allows to connect to adb server from others hosts than localhost

In conclusion: I think we should not integrate any solutions for Unix Domain Sockets - because there are no good enough, up-to-date realization for them in Java, and also no realization available via distribution management systems. I think workaround from main page is good enough for purposes of using adb server from raspberry and other pi systems And finally if anybody know where is the android-tools-adb package maintainer page - we may write him and ask about purposes of Unix Sockets instead of TCP

SKART1 commented 7 years ago

Here is our package

vidstige commented 7 years ago

@SKART1 thanks for clarifying this. I'll try to get a hold of this guy. As for this issue, I'm closing it.

vidstige / jadb

Connection Refused on simple example #45