Make scrcpy work with adb over tcpip about scrcpy HOT 57 CLOSED

I implemented what I explained in my comment, please checkout the forward branch and tell me whether it works for you.

1. connect your device to the same wifi as your computer
2. get the IP of your device (available in Settings → About phone → Status, or adb shell netcfg, or adb shell ip a)
3. adb tcpip 5555
4. adb connect DEVICE_IP:5555 (replace DEVICE_IP by your device address)
5. Unplug your device
6. scrcpy -b 4M (default is 8Mbps, it may be too high for your wifi connection)

To switch back your device to USB mode: adb usb.

Note that while it now works over tcpip, this is not an optimal solution for streaming a video wirelessly, since the raw stream is still sent over TCP, where a packet loss is very bad for latency, due to head-of-line blocking.

As expected, it is better when the device is plugged. 🙂

If everything is ok, I'll probably publish a new release soon 😉

from scrcpy.

• connect the device through usb
• adb kill-server
• adb tcpip portNumber example: adb tcpip 5555
• adb connect ipOfDevice example adb connect 192.168.0.5 or adb connect 192.168.0.5:5555
• unplug the device from usb
• adb devices
• scrcpy -s deviceID or scrcpy -s deviceIP

this will allow scrcpy to work wirelessly

from scrcpy.

It's quite laggy but I guess that was expected.

Depending on the use case, I think that reducing the bitrate and resolution may be a good compromise:

scrcpy --bit-rate 2M --max-size 800

from scrcpy.

Yes, I planned to work on this.

Here are the technical details: https://news.ycombinator.com/item?id=16546276

Actually, it won't work with the current version because of an adb bug ("adb reverse" does not work over "adb connect"): https://issuetracker.google.com/issues/37066218

The solution would be to change the direction of the connection, and use "adb forward", but then scrcpy would try to connect before the server is started, so it would need to retry until connected (and the error would not be noticed on connect, but on first read, due to the tunnel).

from scrcpy.

IIRC, not all devices support adb exec-out,

Looks like it was added around Lollipop (API level 20), which is earlier than your minimum supporter version: https://android.googlesource.com/platform/system/core/+/lollipop-release/adb/services.c#426

adb shell output is corrupted depending on the platform and the version (it sometimes replaces \n by \r\n or \r\r\n),

Yeah, this is caused by the device-side adb daemon allocating a TTY instead of a pipe for stdout. exec-in/exec-out solve that by creating a pipe, but they're unidirectional [1] because the adb protocol didn't specify a way to half close a socket, so you'd end up hanging forever. There's a new shell protocol that was added in N that fixes that by adding another protocol on top that allows each side to tell the other that their stdin is closed.

If you're willing to limit yourself to N+, adb shell should Just Work. Alternatively, if you're willing to use JNI, or upload a separate binary, you should be able to set your PTY to raw mode (via cfmakeraw), which will keep the kernel from munging your binary output.

(Or if you're willing to do dirty hacks, you could do something terrible like base64 encoding your output)

if the server starts, it prints its output on stdout, breaking the whole stream (we can minimize the probability by calling adb start-server just before)…

A sufficiently new version of the adb client shouldn't be subject to this (patch that fixed this is https://android.googlesource.com/platform/system/core/+/1fc8f6e0cfdfd5c9dbbd82116fba2ebec82b4659)

But in both direction, how do you do that? adb is not pipe-friendly like ssh. Did I miss something?

Isn't it? There's problems with detecting when your local stdin closes, but AFAIK, this should work even on ancient devices. I dug up the oldest device I could find roughly available, and it seems to be working as expected (i.e. broken, because the terminal isn't raw mode, so it's mirroring the input and then repeating it via cat).

[1] There's no inherent limitation to keep you from using exec bidirectionally, the command line client just does it to keep people from doing things that will just hang. I'm not suggesting that you do it, but you could connect to the adb server yourself and exec: yourself, and clean up after yourself by doing something like printing your pid at the start, and then doing a separate shell invocation to kill that pid at the end.

from scrcpy.

The adb reverse bug seems to be fixed in AOSP:
https://android-review.googlesource.com/c/platform/system/core/+/664644
https://android.googlesource.com/platform/system/core/+/44899eeb53eb6260c20891723709ab38ed246349

👏

from scrcpy.

@rom1v Yes I did.

That's the problem: you need the changes for the server too.

I found that adb reverse requires to set the IP and the port in the Developer menu

No, it seems that's in their own app.

from scrcpy.

Increasing connection attempts worked. Thank you very much.

from scrcpy.

I increased the number of connection attempts to 50 on master.

from scrcpy.

Hey, it's working for me now as well \o/

Thanks @las2mile for reporting that and @rom1v for this awesome project!

from scrcpy.

first, i'm stunned by how impressive scrcpy is, how impressively it works, especially after clunking around with the premium version of vysor for the last year or so... anyway, usb works fine for me but i can't get wifi to work, nothing seems to happen when i try to launch scycpy.exe after the adb wifi steps.. i'm able to get into the shell after connecting tho (adb shell > return: shell@gvwifiue:/ $), not sure where to go from there....

could it be that my android build is too old? i'm using a rather dated galaxy view 18.4 which doesn't seem to be upgradable... the debug bridge version is 1.0.32....

EDIT -

googled the issue and came across:

Confirm that your host computer is connected to the target device:
$ adb devices
List of devices attached
device_ip_address:5555 device

https://developer.android.com/studio/command-line/adb

so i tried and got this:

1|shell@gvwifiue:/ $ adb devices

• daemon not running. starting it now on port 5038 *
• daemon started successfully *
  List of devices attached
  emulator-5554 offline

shell@gvwifiue:/ $

where do i go from here?

from scrcpy.

Thanks for the heads up on the adb reverse bug @rom1v

I went ahead and confirmed that it does indeed solve this issue with scrcpy!

https://gerrit.dirtyunicorns.com/#/q/status:open+branch:o8x+topic:scrcpy-fix

from scrcpy.

I just used it with adb connect. It worked fine.

from scrcpy.

@Yeradon Hmm… It does not work for me:

$ adb devices
List of devices attached
192.168.0.42:5555	device
$ scrcpy
/usr/local/share/scrcpy/scrcpy-server.jar: 1 file pushed. 0.5 MB/s (19062 bytes in 0.037s)
error: more than one device/emulator
ERROR: "adb reverse" returned with value 1

from scrcpy.

I was using wireless hotspot from my phone to setup the network. Maybe that makes a difference?

from scrcpy.

@Yeradon Created a hotspot with phone and connected computer to it. Then adb connected and run scrcpy, still same error as above.

from scrcpy.

Oops, sorry, that bug languished partly because it was assigned to the wrong person.
Your analysis in comment 6 seems correct, so a fix won't be helpful to your users for a while...

However, you might be able to sidestep that by communicating with your device-side process directly via stdin/stdout, instead of having it connect to a forwarded port. It should have identical throughput and start up faster, too.

from scrcpy.

Thank you for your investigations ;-)

Your analysis in comment 6 seems correct, so a fix won't be helpful to your users for a while...

😞

you might be able to sidestep that by communicating with your device-side process directly via stdin/stdout, instead of having it connect to a forwarded port.

In my first PoC, I used stdout to stream the video.

However:

• IIRC, not all devices support adb exec-out,
• adb shell output is corrupted depending on the platform and the version (it sometimes replaces \n by \r\n or \r\r\n),
• if the server starts, it prints its output on stdout, breaking the whole stream (we can minimize the probability by calling adb start-server just before)…

This is for the device-to-computer communication.

But in both direction, how do you do that? adb is not pipe-friendly like ssh. Did I miss something?

from scrcpy.

Wow, thank you for all this relevant information 👍

I'm not suggesting that you do it, but you could connect to the adb server yourself and exec: yourself

IIUC, in that case, if the device is unplugged while running, the server keeps running?

from scrcpy.

@rom1v awesome! it works for me. It's quite laggy but I guess that was expected.

from scrcpy.

IIUC, in that case, if the device is unplugged while running, the server keeps running?

I believe this should work (but haven't verified it on an old device). Unplugging the device/ctrl-c should close everything; the problem stems from not being able to report EOF of your write end, and continue waiting for output from the other side. (e.g. the exec moral equivalent of echo foo | adb shell "cat; sleep 1; echo foo" will have cat hang forever, because its stdin won't get EOF).

from scrcpy.

forward working perfectly here: MI 5s with Lineage 15 and Samsung Note8 with stock rom.

from scrcpy.

@rom1v I get the same error as you:

/usr/share/scrcpy/scrcpy-server.jar: 1 file pushed. 0.7 MB/s (19038 bytes in 0.025s)
error: more than one device/emulator
ERROR: "adb reverse" returned with value 1
WARN: 'adb reverse' failed, fallback to 'adb forward'
ERROR: Exception on thread Thread[main,5,main]
java.io.IOException: Connection refused
	at android.net.LocalSocketImpl.connectLocal(Native Method)
	at android.net.LocalSocketImpl.connect(LocalSocketImpl.java:292)
	at android.net.LocalSocket.connect(LocalSocket.java:131)
	at com.genymobile.scrcpy.DesktopConnection.connect(DesktopConnection.java:32)
	at com.genymobile.scrcpy.DesktopConnection.open(DesktopConnection.java:37)
	at com.genymobile.scrcpy.Server.scrcpy(Server.java:13)
	at com.genymobile.scrcpy.Server.main(Server.java:70)
	at com.android.internal.os.RuntimeInit.nativeFinishInit(Native Method)
	at com.android.internal.os.RuntimeInit.main(RuntimeInit.java:316)

I don't know what's causing this issue because I followed your instructions: #5 (comment)

from scrcpy.

@unixfox, Did you compile the forward branch using the prebuilt server from v1.0?

from scrcpy.

@rom1v Yes I did.
I made some research about this issue and I found that adb reverse requires to set the IP and the port in the Developer menu: microsoft/vscode-react-native#324 (comment). But unfortunately I don't have this option on my Samsung galaxy S7.

from scrcpy.

We just released v1.1 including this fix: Scrcpy now works wirelessly.

from scrcpy.

Not working for me. No issue when used with USB.

a@a-HP-EliteBook:~ adb tcpip 5555

• daemon not running; starting now at tcp:5037
• daemon started successfully
  error: no devices/emulators found
  a@a-HP-EliteBook:~ adb connect 192.168.43.5:5555
  connected to 192.168.43.5:5555
  a@a-HP-EliteBook:~ adb devices
  List of devices attached
  192.168.43.5:5555 device

a@a-HP-EliteBook:~ scrcpy -b2M -m800
/usr/local/share/scrcpy/scrcpy-server....shed. 0.1 MB/s (19334 bytes in 0.128s)
error: more than one device/emulator
ERROR: "adb reverse" returned with value 1
WARN: 'adb reverse' failed, fallback to 'adb forward'
a@a-HP-EliteBook:~

Logcat

03-16 11:38:53.080 10728 10728 D AndroidRuntime: >>>>>> START com.android.internal.os.RuntimeInit uid 2000 <<<<<<
03-16 11:38:53.086 10728 10728 D AndroidRuntime: CheckJNI is OFF

from scrcpy.

Can you adb shell once connected via adb connect?

from scrcpy.

Using lineage 14.1.
Tried on 3 devices using lineage OS. Same result
a@a-HP-EliteBook:~ adb shell
tomato:/ $

from scrcpy.

OK. Could you try in debug mode, to get more logs, please?

Just:

meson builddir # without additional parameters
ninja -C builddir
./run builddir

from scrcpy.

After entering ninja -C builddir, there was no progress. I had to interrupt it . I encountered it even when I first built with parameters and so I used build commands with prebuilt server and then build was ok.

a@a-HP-EliteBook:~/scrcpy-master$ ninja -C builddir
ninja: Entering directory `builddir'
[30/30] Linking target app/scrcpy.^C
ninja: build stopped: interrupted by user.

I put the prebuilt server in builddir/server folder and proceeded with ./run buildir

a@a-HP-EliteBook:~ /scrcpy-master ./run builddir
builddir/server/scrcpy-server.jar: 1 file pushed. 0.5 MB/s (19334 bytes in 0.035s)
error: more than one device/emulator
ERROR: "adb reverse" returned with value 1
WARN: 'adb reverse' failed, fallback to 'adb forward'
DEBUG: Remaining connection attempts: 10
DEBUG: Remaining connection attempts: 9
DEBUG: Remaining connection attempts: 8
DEBUG: Remaining connection attempts: 7
DEBUG: Remaining connection attempts: 6
DEBUG: Remaining connection attempts: 5
DEBUG: Remaining connection attempts: 4
DEBUG: Remaining connection attempts: 3
DEBUG: Remaining connection attempts: 2
DEBUG: Remaining connection attempts: 1
DEBUG: Server terminated
a@a-HP-EliteBook:~ /scrcpy-master

from scrcpy.

Just to be sure: is it server v1.1?

from scrcpy.

Yes

from scrcpy.

It would surprise me, but maybe the server takes too much time to start.

Could you check with more connection attempts, please:

--- a/app/src/server.c
+++ b/app/src/server.c
@@ -199,7 +199,7 @@ socket_t server_connect_to(struct server *server, Uint32 timeout_ms) {
     if (!server->tunnel_forward) {
         server->device_socket = net_accept(server->server_socket);
     } else {
-        Uint32 attempts = 10;
+        Uint32 attempts = 100;
         Uint32 delay = 100; // ms
         server->device_socket = connect_to_server(server->local_port, attempts, delay);
     }

from scrcpy.

I put the prebuilt server in builddir/server

You should not put it there manually.

Instead, configure with:

meson x … -Dprebuilt_server=/some/external/path/to/scrcpy-server-v1.1.jar

Otherwise, it will be overridden by the call to ninja. (it's ok if you do this just before ./run though)

from scrcpy.

Increasing connection attempts worked.

Could you tell me how many attempts it required to work, please?

from scrcpy.

a@a-HP-EliteBook: ~/scrcpy-master$ ./run builddir
builddir/server/scrcpy-server.jar: 1 file pushed. 0.5 MB/s (19334 bytes in 0.037s)
error: more than one device/emulator
ERROR: "adb reverse" returned with value 1
WARN: 'adb reverse' failed, fallback to 'adb forward'
DEBUG: Remaining connection attempts: 100
DEBUG: Remaining connection attempts: 99
DEBUG: Remaining connection attempts: 98
DEBUG: Remaining connection attempts: 97
DEBUG: Remaining connection attempts: 96
DEBUG: Remaining connection attempts: 95
DEBUG: Remaining connection attempts: 94
DEBUG: Remaining connection attempts: 93
DEBUG: Remaining connection attempts: 92
DEBUG: Remaining connection attempts: 91
DEBUG: Remaining connection attempts: 90
DEBUG: Remaining connection attempts: 89
DEBUG: Remaining connection attempts: 88
DEBUG: Remaining connection attempts: 87
DEBUG: Remaining connection attempts: 86
DEBUG: Remaining connection attempts: 85
DEBUG: Remaining connection attempts: 84
DEBUG: Remaining connection attempts: 83
DEBUG: Remaining connection attempts: 82
DEBUG: Remaining connection attempts: 81
DEBUG: Remaining connection attempts: 80
DEBUG: Remaining connection attempts: 79
DEBUG: Remaining connection attempts: 78
DEBUG: Remaining connection attempts: 77
DEBUG: Remaining connection attempts: 76
DEBUG: Remaining connection attempts: 75
DEBUG: Remaining connection attempts: 74
DEBUG: Remaining connection attempts: 73
DEBUG: Remaining connection attempts: 72
DEBUG: Remaining connection attempts: 71
DEBUG: Starting decoder thread
DEBUG: Starting controller thread
INFO: OpenGL shaders: ENABLED
INFO: Created renderer: opengl
INFO: Initial texture: 720x1280

from scrcpy.

Wow, so it takes almost 3 seconds for the server socket to listen, that's very slow!

from scrcpy.

I'm having what seems to be a similar issue to las2mile, but on Windows; the adb connection is working in scrcpy version 1.1, yet nothing comes up when I run scrcpy.exe . Any ideas on what I should try updating?

from scrcpy.

@Tijimonster Compile from the current master branch, it fixes the adb connection over wifi when it takes too long time to connect.

from scrcpy.

Sorry to bother you again, but I'm having issues with the MSYS compiler and can't get the master branch to compile. Is there anywhere I could get a precompiled master that I could run?

Thanks!

from scrcpy.

I'm running 1.2 and still get the error:

$ scrcpy 
/usr/local/Cellar/scrcpy/1.2_1/share/scrcpy/scrcpy-server.jar: 1 file pushed. 3.0 MB/s (19342 bytes in 0.006s)
error: more than one device/emulator
2018-07-09 12:54:38.157 scrcpy[25723:235278] ERROR: "adb reverse" returned with value 1
2018-07-09 12:54:38.157 scrcpy[25723:235278] WARN: 'adb reverse' failed, fallback to 'adb forward'
$ 

from scrcpy.

@mike-pt Could you compile in debug mode to get more details, please?

from scrcpy.

Doesn't work for me. The tcpip step returns "invalid port". The IP address is correct. Android device and laptop are connected to the same computer.

from scrcpy.

The tcpip step returns "invalid port".

Which command exactly?

from scrcpy.

Thanks for the quick response. The command is:

adb tcpip 192.168.0.109

where "192.168.0.109" is my device's IP address.

from scrcpy.

OK, the command is:

adb tcpip <port>

It switches the adb mode from USB to TCP on a specific port.

Then you can connect with:

adb connect 192.168.0.109:5555

(assuming port is 5555)

https://www.genymotion.com/blog/open-source-project-scrcpy-now-works-wirelessly/

from scrcpy.

Thanks! Progress but still a snag.

Burritos-MacBook:~ burrito$ adb tcpip 5555
restarting in TCP mode port: 5555
Burritos-MacBook:~ burrito$ adb connect 192.168.0.109:5555
connected to 192.168.0.109:5555
Burritos-MacBook:~ burrito$ scrcpy -b 4M
adb: error: failed to get feature set: more than one device/emulator
2018-10-12 11:37:14.149 scrcpy[87631:30959773] ERROR: "adb push" returned with value 1
Burritos-MacBook:~ burrito$ scrcpy -b 4M
/usr/local/Cellar/scrcpy/1.3/share/scr...shed. 0.0 MB/s (18570 bytes in 0.376s)
error: closed
2018-10-12 11:37:30.380 scrcpy[87639:30961410] ERROR: "adb reverse" returned with value 1
2018-10-12 11:37:30.380 scrcpy[87639:30961410] WARN: 'adb reverse' failed, fallback to 'adb forward'
Aborted

I had forgotten at first to unplug the device but it failed even after trying after unplugging.

from scrcpy.

Does it work correctly over usb?

from scrcpy.

Nope, the direction on the main page did not work, I received:

Burritos-MacBook:~ burrito$ scrcpy -b 2M
/usr/local/Cellar/scrcpy/1.3/share/scr...shed. 1.4 MB/s (18570 bytes in 0.013s)
error: closed
2018-10-12 11:43:50.619 scrcpy[87839:31014847] ERROR: "adb reverse" returned with value 1
2018-10-12 11:43:50.619 scrcpy[87839:31014847] WARN: 'adb reverse' failed, fallback to 'adb forward'
Aborted

This is what brought me to this discussion, to find a solution.

from scrcpy.

@moderatoburrito Is your Android >= 5? #277

from scrcpy.

No, 4.4.2 unfortunately. A bit ancient. Was trying to find a way to root it and upgrade Android unofficially but was proving very time-consuming.

from scrcpy.

Thanks anyway! I see that there's a fundamental compatibility issue.

from scrcpy.

Will the issue be fixes in the near future?
I'm currently having a similar problem while trying to use scrcpy via adb usb on a tolino tablet running android 4.4.4
scrcpy aborts after

error: closed
ERROR: "adb reverse" returned with value 1
WARNING: 'adb reverse' failed, fallback to 'adb forward'

from scrcpy.

Question: Do we have to every time first connect via usb and then switch wireless or its just first time?

from scrcpy.

Help me... i have error:
Phone: Xiaomi Redmi K40 / Poco F3

[server] ERROR: Could not invoke method
java.lang.reflect.InvocationTargetException
at java.lang.reflect.Method.invoke(Native Method)
at com.genymobile.scrcpy.wrappers.InputManager.injectInputEvent(InputManager.java:37)
at com.genymobile.scrcpy.Device.injectEvent(Device.java:192)
at com.genymobile.scrcpy.Device.injectEvent(Device.java:196)
at com.genymobile.scrcpy.Controller.injectTouch(Controller.java:320)
at com.genymobile.scrcpy.Controller.handleEvent(Controller.java:134)
at com.genymobile.scrcpy.Controller.control(Controller.java:83)
at com.genymobile.scrcpy.Controller.lambda$start$0$com-genymobile-scrcpy-Controller(Controller.java:90)
at com.genymobile.scrcpy.Controller$$ExternalSyntheticLambda0.run(Unknown Source:2)
at java.lang.Thread.run(Thread.java:1012)
Caused by: java.lang.SecurityException: Injecting input events requires the caller (or the source of the instrumentation, if any) to have the INJECT_EVENTS permission.
at android.os.Parcel.createExceptionOrNull(Parcel.java:3011)
at android.os.Parcel.createException(Parcel.java:2995)
at android.os.Parcel.readException(Parcel.java:2978)
at android.os.Parcel.readException(Parcel.java:2920)
at android.hardware.input.IInputManager$Stub$Proxy.injectInputEventToTarget(IInputManager.java:1294)
at android.hardware.input.InputManager.injectInputEvent(InputManager.java:1153)
at android.hardware.input.InputManager.injectInputEvent(InputManager.java:1182)
... 10 more

from scrcpy.

@AdmoMontes https://github.com/Genymobile/scrcpy/blob/master/FAQ.md#mouse-and-keyboard-do-not-work (but this is not the right place to ask, this issue is about adb over tcpip)

from scrcpy.