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什么的。首先总结原因是两个:
-
Android那边首先做了LF->CR+LF的转换。具体的在ASOP代码里有,adbd用了pty这东西来做输入输出。很古老的东西,没什么兴趣说,google最近改掉了。
-
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,否则就错误。
然后从这个连接里能够读到原始的输出。