第15章 USB热插拔检测与处理

课程目录第15章 USB热插拔检测与处理

15、USB热插拔检测与处理：UEvent机制与USB设备插拔监听、USB设备状态机（连接、配置、断开）、热插拔时的资源释放与重连、实战：动态加载/卸载USB驱动

各位同学，今天我们来聊一个非常“接地气”的话题——USB热插拔。说实话，我刚开始做Android系统开发那会儿，觉得热插拔不就是插上去就能用、拔下来就完事吗？后来被现实狠狠教育了一顿。有一次我调试一个外接UVC摄像头，插拔几次后系统直接卡死，log里全是野指针崩溃。从那以后，我老老实实把热插拔的整个链路啃了一遍。

说白了，USB热插拔的难点不在于“检测到插拔”这件事本身，而在于插拔瞬间系统要做的资源分配、状态切换、驱动加载/卸载这一整套流程。任何一个环节没处理好，轻则设备不识别，重则系统挂掉。今天我们就从UEvent机制讲起，一步步把热插拔的里里外外都拆开看看。

15.1 UEvent机制：系统怎么知道USB设备插进来了？

Android系统底层基于Linux内核，USB设备插拔时，内核会通过UEvent（用户空间事件）把消息往上抛。你可以把UEvent理解成内核发给用户空间的一个“小纸条”，上面写着：“嘿，有个USB设备插进来了，这是它的厂商ID、产品ID、设备路径……”

UEvent本质上是一个netlink socket消息。内核在检测到USB设备状态变化时，会调用kobject_uevent()函数，把事件广播出去。用户空间的守护进程（比如ueventd）收到后，再根据规则去做后续处理。

我个人习惯在调试时直接看UEvent日志，命令很简单：

# 监听所有UEvent
adb shell su -c "ueventd &"
# 或者用更直接的方式
adb shell su -c "cat /sys/kernel/uevent_helper"

不过更实用的方法是写一个小程序来监听：

// 监听UEvent的C代码片段
#include <sys/socket.h>
#include <linux/netlink.h>

#define UEVENT_BUFFER_SIZE 2048

int main() {
    struct sockaddr_nl addr;
    int sock = socket(AF_NETLINK, SOCK_RAW, NETLINK_KOBJECT_UEVENT);
    
    memset(&addr, 0, sizeof(addr));
    addr.nl_family = AF_NETLINK;
    addr.nl_pid = getpid();
    addr.nl_groups = 1;  // 监听所有UEvent
    
    bind(sock, (struct sockaddr *)&addr, sizeof(addr));
    
    char buf[UEVENT_BUFFER_SIZE];
    while (1) {
        recv(sock, &buf, sizeof(buf), 0);
        // 解析buf中的事件信息
        printf("收到UEvent: %s\n", buf);
    }
    return 0;
}

你想想看，这个机制其实很优雅——内核不直接调用用户空间的代码，而是通过消息传递的方式解耦。这样即使上层服务挂了，内核该上报还是上报，互不影响。

15.2 USB设备插拔监听：在Java层怎么接住这些事件？

在Android应用层，我们不需要直接操作netlink socket。系统已经封装好了UsbManager和广播接收器。我建议你这样做：

// 注册USB设备插拔广播
IntentFilter filter = new IntentFilter();
filter.addAction(UsbManager.ACTION_USB_DEVICE_ATTACHED);
filter.addAction(UsbManager.ACTION_USB_DEVICE_DETACHED);
registerReceiver(usbReceiver, filter);

// 广播接收器
private final BroadcastReceiver usbReceiver = new BroadcastReceiver() {
    @Override
    public void onReceive(Context context, Intent intent) {
        String action = intent.getAction();
        UsbDevice device = intent.getParcelableExtra(UsbManager.EXTRA_DEVICE);
        
        if (UsbManager.ACTION_USB_DEVICE_ATTACHED.equals(action)) {
            Log.d("USB", "设备插入: " + device.getDeviceName());
            // 这里可以开始请求权限、打开设备
        } else if (UsbManager.ACTION_USB_DEVICE_DETACHED.equals(action)) {
            Log.d("USB", "设备拔出: " + device.getDeviceName());
            // 这里必须释放资源！
        }
    }
};

注意：我曾经在项目中踩过一个坑——在onReceive里直接做耗时操作。广播接收器默认运行在主线程，如果你在插入事件里做设备枚举、权限申请，界面会卡住。正确的做法是：收到事件后，通过Handler或AsyncTask转到工作线程处理。

15.3 USB设备状态机：连接、配置、断开

USB设备从插入到正常使用，再到拔出，经历了一个完整的状态机。我画了一张图帮你理解：

这张图里有个关键点我想强调一下：从“连接”到“配置”这一步不是自动完成的。内核检测到设备后，会去匹配驱动。如果找不到合适的驱动，设备会一直停留在“连接”状态，不会进入“配置”。

我在项目中遇到过一种情况：一个自定义的HID设备插上后，dmesg显示设备被识别了，但应用层就是打不开。后来发现是内核没有对应的HID驱动，设备一直卡在“连接”状态，没有进入“配置”。所以排查问题时，先看看设备到底在哪个状态。

15.4 热插拔时的资源释放与重连

这是最容易出问题的地方。我见过太多开发者在设备拔出时只做了“关闭文件描述符”这一件事，结果导致内存泄漏、内核崩溃。正确的做法应该是一个完整的资源清理流程：

关闭所有打开的文件描述符——包括/dev/bus/usb/xxx下的设备节点
释放USB请求块（URB）——如果你用了libusb或直接操作URB，必须调用usb_free_urb()
取消未完成的异步传输——否则回调函数可能访问已经释放的内存
通知上层应用——通过回调或广播告诉UI层设备已断开
清理缓存数据——比如设备描述符、字符串描述符等

核心原则：设备拔出时，所有与该设备相关的资源必须全部释放。不要依赖垃圾回收，C/C++代码尤其要注意手动管理。

重连的逻辑相对简单一些。设备再次插入时，系统会重新走一遍状态机。但有一个细节要注意：重连后的设备可能被分配了不同的设备节点。比如第一次插入是/dev/bus/usb/001/002，第二次可能变成/dev/bus/usb/001/003。所以不要硬编码设备路径，要通过UsbDevice.getDeviceName()动态获取。

15.5 实战：动态加载/卸载USB驱动

最后我们来看一个实战场景。假设你有一个USB串口设备，需要动态加载它的驱动。在Android系统里，驱动通常以内核模块（.ko文件）的形式存在。我们可以通过insmod和rmmod来动态管理。

我写了一个简单的脚本，用于在设备插入时自动加载驱动：

#!/system/bin/sh
# 动态加载USB驱动示例

DRIVER_PATH="/vendor/lib/modules/usb_serial.ko"
DEVICE_VID="1A86"  # 举例：某USB转串口芯片的VID
DEVICE_PID="7523"

# 监听UEvent，当设备插入时加载驱动
while read line; do
    case "$line" in
        *"add"*"$DEVICE_VID"*)
            echo "检测到USB设备插入，加载驱动..."
            insmod $DRIVER_PATH
            if [ $? -eq 0 ]; then
                echo "驱动加载成功"
            else
                echo "驱动加载失败，可能已加载"
            fi
            ;;
        *"remove"*"$DEVICE_VID"*)
            echo "检测到USB设备拔出，卸载驱动..."
            rmmod usb_serial
            if [ $? -eq 0 ]; then
                echo "驱动卸载成功"
            else
                echo "驱动卸载失败，可能有其他设备在使用"
            fi
            ;;
    esac
done

小技巧：在实际产品中，不建议在UEvent触发时直接insmod。更好的做法是让ueventd根据ueventd.rc配置文件中的规则自动加载驱动。脚本方式更适合开发和调试阶段。

另外，驱动卸载时有一个坑：如果还有进程在使用该驱动提供的设备节点，rmmod会失败。我曾经调试一个USB摄像头驱动，卸载时总是报“Device or resource busy”。查了半天发现是相机预览线程没有关闭。所以卸载驱动前，一定要确保所有用户空间的引用都已经释放。

嗯，关于USB热插拔的内容就讲到这里。从UEvent机制到状态机，再到资源管理和驱动加载，每一步都有它的设计逻辑。你只要把这条链路理清楚，以后遇到USB相关的诡异问题，心里就有底了。

📚 课程目录

15、USB热插拔检测与处理：UEvent机制与USB设备插拔监听、USB设备状态机（连接、配置、断开）、热插拔时的资源释放与重连、实战：动态加载/卸载USB驱动

15.1 UEvent机制：系统怎么知道USB设备插进来了？

15.2 USB设备插拔监听：在Java层怎么接住这些事件？

15.3 USB设备状态机：连接、配置、断开

15.4 热插拔时的资源释放与重连

15.5 实战：动态加载/卸载USB驱动