google改动内容在这儿，没有测试过，看起来没问题。

到目前位置，市面上所有的Android设备，都存在这个这个小问题：

在Linux/Mac上执行adb命令输出什么东西时，就算是二进制输出，那么LF(0x0a)字符会被转换成CR(0x0d) + LF。Windows上更可笑，会变成CR+CR+LF。

这个很好验证:

从Android上抓一个文件下来，例如/default.prop, 看看里面应该只有LF(0x0a)，而没有CR(0x0d)的。

adb pull /default.prop     local_output_file1

然后在通过adb shell cat命令输出到本地，看看文件里是不是多了好多CR(0x0d)了。

adb shell cat /default.prop > local_output_file2

这个不是简单的因为Windows OS的缘故，Linux也出毛病。

解决方法一大堆，例如上述的pull，或者通过socket输出到PC。

其实还有方法可以完全不需要转换，也不需要pull,socket什么的。首先总结原因是两个：

  1. Android那边首先做了LF->CR+LF的转换。具体的在ASOP代码里有，adbd用了pty这东西来做输入输出。很古老的东西，没什么兴趣说，google最近改掉了。
  2. Windows OS这边的adb工具更额外做了一层LF->CR+LF的转换。这个到是Windows的默认风格。

解决方法有两个步骤(Linux/Mac只要第一个步骤就行了)

1. 在android那边设定stty -onlcr来禁止发自android那边的转换。

这个也有两个方法，一个是借助于外部工具stty(从busybox里来的)，那么

预先把busybox工具放到android里：

adb push busybox /data/local/tmp/
adb shell chmod 755 /data/local/tmp/busybox

然后，那就是在执行自己的命令之前执行busybox stt -onlcr。例如

adb shell '/data/local/tmp/busybox stty -onlcr; cat /default.prop' > local_output_file2

还有一种方法就是自己的C代码里，执行这一段：

#include <termios.h>
if (isatty(STDOUT_FILENO)) {
    struct termios term;
    tcgetattr(STDOUT_FILENO, &term);
    cfmakeraw(&term);
    tcsetattr(STDOUT_FILENO, TCSANOW, &term);
}

2. Windows这边才需要这个步骤。那就是不直接使用adb工具了，而是直接和adb工具所服务的5037端口打交道，发送命令，取得结果，这个具体的说起来有点啰嗦，如果是nodejs，那么用adbkit好了，其他的我没多看，大致就是

1. 向localhost:5037 发送host:transport:设备序列号
    得到回答，如果是OKAY四个字那就到step2，否则就错误。 
2. 继续向上述port发送shell:命令内容
    得到回答，如果是OKAY四个字那就到step2，否则就错误。 
然后从这个连接里能够读到原始的输出。