1. 问题描述

1.1 现象

OpenHarmony5.1.0，用户点击开启蓝牙开关按钮，出现按钮反复自动开关的现象，无法正常使用蓝牙功能。

1.2 概率

这种现象概率极低，如果特意去复现，是很难复现的，只是在使用过程，偶然的就出现了。

2. 分析过程

从应用侧观察，蓝牙上报的当前状态为异常值：`access.getState()` 返回 **4**（正常应为 0-关闭或 2-开启）。同时，`access.on('stateChange')` 监听回调不断触发，状态码序列为 1 → 6 → 0 → 4 → 3 → 0，对应的蓝牙状态反复在“开、关、关、开、关、关”之间跳变，直接导致了开关的自动循环现象。

检查系统启动日志，发现关键错误：

`err=2` 对应 `ENOENT`（No such file or directory），说明在执行 `chmod 777 /dev/ztopbt_dev` 时，该设备节点尚不存在。

通过与模组厂家一起分析，系统初始化流程中，通过 `insmod ztop_bt_usb.ko` 加载蓝牙驱动。驱动向内核 USB 子系统注册后，正常情况下内核应立即调用驱动的 `probe` 入口函数来创建 `/dev/ztopbt_dev` 节点。但在此异常场景下，`probe` 并未被及时调用，导致节点创建滞后约400ms。此时，init 脚本中的 `chmod 777 /dev/ztopbt_dev` 已经执行完毕并失败，节点权限未被正确设置。

约 400ms 后，内核才调用驱动的 `probe` 函数，`/dev/ztopbt_dev` 节点得以创建，但此时已经没有后续操作去执行`chmod 777 /dev/ztopbt_dev` ，节点保留了默认权限。蓝牙服务在 `open` 该节点时，由于权限不足，进而向上层返回异常状态值，引发了状态循环。

3. 解决方案

针对上述“节点生成滞后于权限设置”的问题，修改系统初始化脚本，在 `chmod` 前显式等待设备节点就绪。

修改文件：

`device/board/goke/tv/customize/gk6780v100/etc/vendor/init.taishan.cfg`

修改内容：

在原有的 `"chmod 777 /dev/ztopbt_dev"` 命令之前，增加一条 `"wait /dev/ztopbt_dev"` 命令。即等待节点创建成功。如下：