AdbSocket closing connection about madb HOT 3 OPEN

I think that what you're seeing is the adb daemon disconnecting you after the command has executed and the device has sent its response.

For what you describe, it seems that the best option would be to open an interactive shell connection to the device and then continuously send the screencap commands. We don't have support for interactive shells in SharpAdbClient yet, I'm not sure what it would take to get that added.

Alternatively, we did some work to make GetFramebuffer reasonably fast, but I'm guessing it does not work for your emulator, does it?

from madb.

I will make some researchs about interactive shell, I just used ADB for simple things.

I'm working with MEmu android emulator and I need to capture the emulator screen like 1~2 times per second for a few minutes, just to interact with a game while the battle is running, besides Bluestacks, Memu and other emulators run inside a virtual machine, so I can't capture its screen like I do on BS using Windows API, because when it is a VM it returns a black screen, so I need to use ADB to generate the screenshot so I can read the png file, I've been trying to find a better solution for this, but I don't think there is a better way to do that.

Btw, about the GetFrameBuffer speed, here are some 'statistics' about the capture screen speed for me.

Using GetFrameBufferAsync:

var image = await AdbClient.Instance.GetFrameBufferAsync(device, CancellationToken.None);

483,5614 ms
448,0569 ms
490,5623 ms
472,56 ms
443,5563 ms
477,5606 ms
444,5565 ms
554,0704 ms
430,0546 ms
513,0652 ms
477,0605 ms

Using the AdbSocket in OP:

330,542 ms
254,5324 ms
352,0447 ms
248,5316 ms
240,5305 ms
344,5437 ms
265,0337 ms
249,0316 ms
382,5486 ms
308,5392 ms

from madb.

Hello, you should mention the Resolution of your device, otherwise the benchmark results cannot be compared

from madb.