Read binary stdout data from adb shell?

Unlike adb shell the adb exec-out command doesn't use pty which mangles the binary output. So you can do

adb exec-out screencap -p > test.png

https://android.googlesource.com/platform/system/core/+/5d9d434efadf1c535c7fea634d5306e18c68ef1f

Note that if you are using this technique for a command that produces output on STDERR, you should redirect it to /dev/null, otherwise adb will include STDERR in its STDOUT corrupting your output. For example, if you are trying to backup and compress a directory:

adb exec-out "tar -zcf - /system 2>/dev/null" > system.tar.gz

Sorry to be posting an answer to an old question, but I just came across this problem myself and wanted to do it only through the shell. This worked well for me:

adb shell screencap -p | sed 's/^M$//' > screenshot.png

That ^M is a char I got by pressing ctrl+v -> ctrl+m, just noticed it doesn't work when copy-pasting.

adb shell screencap -p | sed 's/\r$//' > screenshot.png

did the trick for me as well.

As noted, "adb shell" is performing a linefeed (0x0a) to carriage-return + linefeed (0x0d 0x0a) conversion. This is being performed by the pseudo-tty line discipline. As there is no "stty" command available to the shell, there is no easy way to mess with the terminal settings.

It's possible to do what you want with ddmlib. You'd need to write code that executed commands on the device, captured the output, and sent it over the wire. This is more or less what DDMS does for certain features. This may be more trouble than its worth.

The repair() solution -- converting all CRLF to LF -- feels shaky but is actually reliable since the "corrupting" LF-to-CRLF conversion is deterministic. I used to do the same thing to repair inadvertent ASCII-mode FTP transfers.

It's worth noting that the PNG file format is explicitly designed to catch exactly this (and related) problems. The magic number begins with 0x89 to catch anything that strips high bits, followed by "PNG" so you can easily tell what's in the file, followed by CR LF to catch various ASCII line converters, then 0x1a to trap old MS-DOS programs that used Ctrl-Z as a special end-of-file marker, and then a lone LF. By looking at the first few bytes of the file you can tell exactly what was done to it.

...which means that your repair() function can accept both "corrupted" and "pure" input, and reliably determine if it needs to do anything.

Edit: one additional note: it's possible for the device-side binary to configure the tty to avoid the conversion, using cfmakeraw(). See the prepareRawOutput() function in the screenrecord command in Android 5.0, which can send raw video from the live screen capture across the ADB shell connection.