从一次USB驱动“抢人”事件说起：手把手教你为Android设备定制开机Shell守护进程

从USB驱动冲突到系统守护Android设备定制化启动管理的深度实践那天产线突然打来紧急电话——三十台刚出货的工控平板全部无法连接外接扫码枪。现场工程师的反馈很诡异设备重启后前几分钟扫码枪工作正常但运行一段时间后就会报设备未就绪。当我连上adb查看内核日志时一行熟悉的错误引起了注意[ 142.517640] cdc_acm 1-1.4:1.0: failed to set dtr/rts原来又是CDC-ACM驱动在抢我们的CH343串口设备这种驱动冲突在嵌入式开发中并不罕见但要在系统层面彻底解决就需要构建一个健壮的守护进程体系。下面我就分享从这次事故中总结出的完整解决方案。1. 问题本质与架构设计1.1 驱动冲突的底层原理当Android设备接入USB转串口设备时内核会根据设备ID自动加载匹配的驱动。问题出在CDC-ACM作为通用驱动会优先抢占特定厂商设备。通过分析/sys/bus/usb/drivers目录结构可以清晰看到这种竞争关系/sys/bus/usb/drivers/ ├── cdc_acm │ ├── 1-1.4:1.0 - ../../../../devices/platform/soc/1a400000.usb/1-1.4/1-1.4:1.0 │ └── bind └── usb_ch343 ├── 1-1.4:1.0 - ../../../../devices/platform/soc/1a400000.usb/1-1.4/1-1.4:1.0 └── bind1.2 守护进程的四个核心能力一个工业级解决方案需要具备实时监控通过inotify监控sysfs文件变化精准识别验证设备厂商ID和产品ID错误恢复处理驱动绑定失败等异常情况资源管控避免CPU和内存泄漏2. 从脚本到守护进程的进化2.1 基础监控脚本实现以下是改进后的设备监控脚本框架#!/system/bin/sh # 常量定义 VENDOR_ID1a86 DRIVER_MATCHcdc_acm TARGET_DRIVERusb_ch343 SYSFS_USB_PATH/sys/bus/usb/devices MONITOR_INTERVAL1 # 日志记录函数 log_to_kmsg() { echo [CH343Daemon] $1 /dev/kmsg } # 驱动切换核心逻辑 bind_to_target_driver() { local device_node$1 if [ ! -d ${SYSFS_USB_PATH}/${device_node} ]; then log_to_kmsg Device ${device_node} not found return 1 fi # 解绑当前驱动 echo $device_node /sys/bus/usb/drivers/${DRIVER_MATCH}/unbind 2/dev/null if [ $? -ne 0 ]; then log_to_kmsg Unbind failed for ${device_node} return 2 fi # 绑定目标驱动 echo $device_node /sys/bus/usb/drivers/${TARGET_DRIVER}/bind if [ $? -ne 0 ]; then log_to_kmsg Bind failed for ${device_node} return 3 fi log_to_kmsg Successfully bound ${device_node} to ${TARGET_DRIVER} return 0 }2.2 系统服务化改造在init.rc中配置为守护服务service ch343_daemon /vendor/bin/ch343_daemon.sh class main user root group root oneshot disabled # 在boot完成阶段启动服务 on property:sys.boot_completed1 start ch343_daemon关键改进点使用oneshot防止服务异常重启在boot完成后启动避免竞争禁用服务自重启机制3. 系统集成与权限管理3.1 SELinux策略配置创建自定义策略文件vendor_ch343_daemon.tetype vendor_ch343_daemon_exec, exec_type, vendor_file_type, file_type; # 允许访问USB设备信息 allow vendor_ch343_daemon sysfs:file r_file_perms; allow vendor_ch343_daemon sysfs:file write; # 允许操作驱动绑定 allow vendor_ch343_daemon usbdevice:dir search; allow vendor_ch343_daemon usbdevice:file { open read write };3.2 构建系统集成在Android.bp中添加cc_binary { name: ch343_daemon, srcs: [ch343_daemon.sh], init_rc: [ch343_daemon.rc], vendor: true, compile_multilib: first, sepolicy: { sepolicy_include_dirs: [vendor/extra/sepolicy], }, }4. 高级监控与优化技巧4.1 使用inotify替代轮询通过引入inotify监控机制可以大幅降低CPU占用# 初始化inotify监控 init_inotify() { inotifyd /vendor/bin/ch343_monitor.sh ${SYSFS_USB_PATH}/:n } # 监控脚本示例 #!/bin/sh while read EVENT; do if [[ $EVENT ~ CREATE ]] [[ $EVENT ~ usb ]]; then check_new_device fi done4.2 资源限制配置在init.rc中添加资源限制service ch343_daemon /vendor/bin/ch343_daemon.sh ... limit cpu 10 10 limit memory 50MB 50MB limit nofile 100 1004.3 心跳检测机制实现守护进程自检# 在脚本中添加健康检查 HEARTBEAT_FILE/data/vendor/ch343_heartbeat last_heartbeat$(date %s) while true; do current_time$(date %s) if [ $((current_time - last_heartbeat)) -gt 60 ]; then log_to_kmsg Daemon heartbeat timeout exit 1 fi echo $current_time $HEARTBEAT_FILE sleep 30 done5. 调试与问题排查5.1 关键调试命令命令用途示例输出ls -Z /sys/bus/usb/drivers查看SELinux上下文u:object_r:sysfs:s0 cdc_acmps -Z -A | grep ch343查看进程安全上下文u:r:vendor_ch343_daemon:s0dmesg | grep -i usb查看内核USB事件usb 1-1.4: new full-speed USB device5.2 常见问题解决方案驱动绑定失败检查/sys/bus/usb/drivers目录权限验证SELinux策略是否允许写操作服务无法启动# 手动测试服务 adb shell setenforce 0 adb shell /vendor/bin/ch343_daemon.sh资源泄漏检测watch -n 1 cat /proc/pgrep ch343_daemon/status | grep -E VmRSS|Threads那次产线事故最终让我们建立了一套完整的设备驱动管理方案。现在每台设备出厂前都会经过严格的驱动兼容性测试而守护进程的版本也迭代到了3.0。最让我欣慰的是这个方案后来被用在了公司多个产品线上成为嵌入式Android设备开发的标配组件之一。