getprop的坑

起因

上一篇记录提到，我所在的公司在研发一款5G设备，由于合作公司提供的5G模块存在一些问题（系统BUG），我们决定自己做一个服务管理程序，来控制系统中展讯原生的服务如modem_ctrl，模块厂的服务和我们自己的sdk，以及系统需要的开源服务如dnsmasq，thttpd等。上文也提到了开发人员就三个，主力编程人员两个，所以这个任务落到了我的头上

我花了一个星期完成了这项工作，把设备上要启动的服务都加到了管理服务的配置文件中，删除了/etc/rc5.d文件夹中对应服务的启动链接文件，第一次测试就成功通过了。于是写了bat脚本进行稳定性测试(检查设备如果驻网成功就重启)，两个小时后，我发现脚本卡住了，一看原来电脑上都不显示设备了！！！

分析错误原因

还好之前板子出过问题，已经在芯片上把串口接出来了，连上串口，登陆系统发现一切正常，造成没有adb的原因是USB模式变成了默认的36（我们的设备39才有ADB），查看串口日志发现：

wait for usb ready, idVendor open fail, loop = 3
starting FG650 usbmode config
wait for usb ready, idVendor open fail, loop = 4
property service is not ready !
property service is not ready !
property service is not ready !
39
usb default = 36
persist.sys.usbmode = default

明明打印了39说明读到了，为什么又走到了default呢，我找到了usb的脚本,其中获取usb模式的方式如下：

usb_mode_num=36
usb_mode_profile="persist.sys.usbmode"

echo "starting FG650 usbmode config"

usb_mode_num=$(getprop $usb_mode_profile)

echo "$usb_mode_num"

我怀疑39的后面可能有不显示的特殊字符，导致脚本继续向下运行判断模式的时候匹配不到，于是我加了打印，打印一下usb_mode_num的十六进制：

wait for usb ready, idVendor open fail, loop = 4
property service is not ready !
property service is not ready !
property service is not ready !
39
00000000  70 72 6f 70 65 72 74 79  20 73 65 72 76 69 63 65  |property service|
00000010  20 69 73 20 6e 6f 74 20  72 65 61 64 79 20 21 20  | is not ready ! |
00000020  0a 70 72 6f 70 65 72 74  79 20 73 65 72 76 69 63  |.property servic|
00000030  65 20 69 73 20 6e 6f 74  20 72 65 61 64 79 20 21  |e is not ready !|
00000040  20 0a 70 72 6f 70 65 72  74 79 20 73 65 72 76 69  | .property servi|
00000050  63 65 20 69 73 20 6e 6f  74 20 72 65 61 64 79 20  |ce is not ready |
00000060  21 20 0a 33 39                                    |! .39|

原来不是后面多了，上面的提示都被赋给了usb_mode_num，由此可以看出getprop在执行时是被阻塞的，直到执行成功，并得到所有的输出

解决方法

知道getprop会阻塞后，解决就很简单了，执行两次getprop就好了，第一个成功后说明文件已经准备好了，这时第二个就一定可以拿到正确的结果：

usb_mode_num=36
usb_mode_profile="persist.sys.usbmode"

echo "starting FG650 usbmode config"

usb_mode_num=$(getprop $usb_mode_profile)
usb_mode_num=$(getprop $usb_mode_profile)

echo "$usb_mode_num"