00TL;DR

一句话：这台机器能认出蓝牙适配器、能发单条 HCI 命令、能让手机搜到自己，但任何持续的 USB 蓝牙数据流量都会把整机锁死；雪上加霜的是，我们自己写的开机自启脚本让原生 BlueZ 和旁路程序同时抢同一个 dongle，制造了「开机一两分钟必死」的假象。

这台 TP-LINK TPmini 大眼睛是一台 TV 盒子 + 路由器二合一设备，官方 ROM 把蓝牙功能整体裁掉了。我想给它外接一个 USB 蓝牙 dongle，最终目的是给这台机器上的怀旧游戏模拟器接一个蓝牙手柄。八天里我们依次走了三条技术路线，也依次撞上三堵墙。

01主角档案：硬件与软件情况

机器本体

外接的蓝牙适配器

软件层次：为什么一开始就得自己造轮子

这台机器最别扭的地方在于 framework 与系统栈是两套互不相通的蓝牙体系：Android 的 Java BluetoothAdapter 走 Bluedroid，而机器上唯一能跑起来的是 BlueZ 4.93；同时系统没有 libdbus 的 Java 绑定、没有 bluetoothctl、没有可用的 APK 可以直接调用。所以想操作蓝牙，只有两条路：写 C 程序直接说 D-Bus，或者干脆绕过整个用户态协议栈。

工具链与环境约束

PC 侧用 Android NDK r30 的 armv7a-linux-androideabi21-clang.cmd 交叉编译，产物推到 /data/local/tmp/。给 API 17 编译有三个必须避开的坑：

设备侧的工具集也被裁得很干净：没有 pkill killall pidof pgrep setsid nohup tail head tr wc strings file chattr awk，只有 ps / grep / kill / ls / cat / sh / sleep / getprop / mount / su 和一个原生 spawn。清进程只能遍历 /proc/<pid>/comm —— 这个限制后面坑了我们一次。

02最初的目标

表层目标是「让官方砍掉蓝牙的 TPmini 能通过外接 USB 适配器扫描、配对、连接蓝牙设备」；真正的目的是给这台已经跑起 RetroArch 的怀旧游戏盒子接一个蓝牙游戏手柄。

所以验收标准其实很朴素：打开设置面板 → 点「开始扫描」→ 列表里出现手柄 → 点「配对」→ 连接成功 → 按键能进游戏。整个链条按层次拆开是这样：

[ Web UI 点击扫描 ]
   → BlueZ / D-Bus StartDiscovery
   → HCI_Inquiry（持续广播 + 中断 IN 事件流）
   → 收到 Inquiry Result，列出周边设备
   → Create_Connection + 认证 / SSP 配对
   → ACL 链路 → L2CAP → SDP → HIDP
   → /dev/input/eventX → Android InputReader → 游戏

事后看，这条链路在三个不同的层次上各断了一次：用户态守护进程不存在（可补）、内核 btusb 发送路径有缺陷（可绕过）、USB 主机控制器扛不住持续流量（绕不过）。我们对前两层都找到了干净的解法，第三层是硬件/内核级的硬限制，也是整件事最终收口的原因。

另一个前置判断值得记下来：一开始先花时间确认了「板载蓝牙到底有没有」。原厂 init.rk30board.rc 里确实有 brcm_patchram_plus 服务和 /dev/ttyS0 的 bluetooth 权限，看起来像有 UART 蓝牙；但实测四种波特率零响应、hcd 固件全删、SDIO 上只有一块纯 WiFi 的 RTL8189ES，才判定本批次硬件未实装板载蓝牙芯片，USB dongle 是唯一通路。这个结论避免了在错误的方向上继续投入。

03路线一：把 BlueZ 4.93 用户态补齐

3.1 找齐缺的二进制

设备自带 libbluetoothd.so 是 4.93，所以必须找同版本的 bluetoothd 与插件，不能随便拿一个 BlueZ 5 的来用；同时 vanilla BlueZ 4.101 需要 epoll_create1 / signalfd / timerfd_create / ppoll，这台机器的 bionic 全都没有，交叉编译链接期就会失败。可行的来源是 CyanogenMod 10.1（Android 4.2.2）里已经为 bionic 打过补丁的 BlueZ 构建。

把 bluetoothd 推到 /system/bin、插件推到 /system/lib/bluez-plugin/、配置推到 /system/etc/bluetooth/ 之后，进程能启动并正确解析 main.conf，但卡在 D-Bus 连接上。

3.2 三道 D-Bus / root 关卡

对应地写了三个小工具，都是 NDK 编译的 ARM 原生程序：

/* bt_launcher.c —— 冒充 init，给 dbus-daemon 造一个 android socket */
fd = socket(AF_UNIX, SOCK_STREAM, 0);
bind(fd, "/dev/socket/dbus"); listen(fd, ...);
fd = dup(fd);  /* 提到 ≥10，防止被 stdio 覆盖 */
setenv("ANDROID_SOCKET_dbus", fd_string, 1);
execve("dbus-daemon", ["--system", "--nofork", ...]);
        /* --nofork 必需：否则 daemonize 会关掉 fd≥3，把监听 fd 丢掉 */

/* bt_bluez.c —— 还要额外造 /dev/socket/bluetooth（SDP server 需要） */
setenv("ANDROID_SOCKET_bluetooth", fd2_string, 1);
setenv("LD_PRELOAD", "/data/local/tmp/nosetuid.so", 1);
        /* nosetuid.so 把 setuid/setgid/setresuid/setgroups 全变空操作，保持 root */

/* spawn.c —— 通用「脱离器」，让 adb 立即返回 */
fork(); setsid() /* su 已把子进程设为进程组长，直接 setsid 会 EPERM，需要再 fork 一次 */
pipe()  /* 父子同步：父进程必须等子进程确认「已 setsid」才 _exit，否则 su 会按进程组清理 */
for (i = 3; i < 1024; i++) close(i);  /* 关掉所有继承来的 pty fd */

跑通之后的证据非常干净：

$ cat /data/local/tmp/bt.log
Starting SDP server
Got Unix socket fd '12' from environment
Adding device id record for 000a:0000
  plugins loaded: hciops input audio network health
Entering main loop
  init_known_adapters()

$ dbus_client request_name org.bluez
ret=2 (IN_QUEUE)   # org.bluez 已被 bluetoothd 占据，说明守护进程真的活着

$ btsock_probe
AF_BLUETOOTH / L2CAP  OK
AF_BLUETOOTH / HCI    OK
AF_BLUETOOTH / SCO    OK

3.3 btctl：一个 70KB 的自给自足 Web 面板

既然 Java 层调不到 BlueZ，也没有可用蓝牙命令行工具，干脆写一个 纯 C 守护进程：自己实现 D-Bus 报文层（约 500 行）、自己封装 BlueZ 4.93 的 Adapter / Device / Agent 调用、内置单线程 HTTP 服务监听 0.0.0.0:8787、把单页 HTML 直接编进二进制（ui.html → gen_ui.py → ui_data.h）。整个程序是一个静态 ARM 二进制，无运行时依赖，用设备自带浏览器打开 http://127.0.0.1:8787/ 就能点。

手写 D-Bus 报文的过程也留下几条反直觉的经验：SIGNATURE 字段的 variant 签名是 g 不是 s；字符串数组每元素前要 4 字节对齐；ListNames 前会插一条 NameAcquired 信号，必须按 reply_serial 循环匹配而不能读一条就当回复。另外 BlueZ 4.93 的方法是 ListDevices 而不是 GetDevices。

3.4 开机自启、桌面图标与持久化

为了让「插上 dongle 就能用」，我们把自启挂在 /init.rc:532 的 service flash_recovery /system/etc/install-recovery.sh 上（class main / oneshot / root，设备没有 SELinux 强制）。这个文件被 KingRoot 加了 IMMUTABLE + APPEND_ONLY 标志，普通 root 也写不动，于是又自写了一个 chattr_tool 用 FS_IOC_SETFLAGS 解标志 —— 32 位 ARM 上这个 ioctl 是 0x80046601，写成 64 位版的 0x80086601 会得到 ENOTTY。文件末尾追加了 TPMINI_BT_HOOK 块，调用 /data/local/tmp/bt_boot.sh。

顺带把桌面快捷方式和浏览器书签也做了。Android 4.2 的 Launcher2 有两个坑：Intent URI 不能用 data= 键、必须写 intent:<URL>#Intent;action=...;component=...;end；图标用 iconResource 永远是绿色机器人，必须把 PNG 二进制写进 favorites.icon BLOB 并把 iconType 设为 0。adb reboot 后进程自启、图标书签存活、/api/state 返回 present=1 powered=1，这一阶段看起来是成功的。

04第一次转向：扫描永远 0 台，根因不在 BlueZ

点「开始扫描」后 D-Bus 返回 ok、面板显示「正在扫描附近设备…」、状态位 discovering=1，但设备列表始终为空。这是整个项目里最有价值的一次「假成功」。

4.1 证据链：命令发出去了，事件一条也没回来

# ① 命令与事件计数不平衡，且差值恒定
$ hcidbg info
cmd_tx = 52    evt_rx = 41        ← 冷启动后
cmd_tx = 46    evt_rx = 41        ← 我发 5 条命令后
cmd_tx = 41    evt_rx = 41        ← HCIDEVUP 刚完成时（41 条全成功）
evt_rx 永远停在 41。发多少条命令，evt_rx 一动不动。

# ② 内核日志直接指出失败点
$ dmesg | grep Bluetooth
Bluetooth: hci0 urb dd45ba00 submission failed
Bluetooth: hci0 command tx timeout
Bluetooth: hci0 urb dd45b980 submission failed
Bluetooth: hci0 command tx timeout
（每秒一对，形成死循环；冷启动后 63 秒＝蓝牙栈拉起时刻开始，稳定复现）

# ③ URB 根本没提交到主机控制器
复位前 urbnum = 141
发一条命令后 urbnum = 141      ← 完全没变
urbnum++ 在 usb_hcd_submit_urb() 内部、设备状态与端点检查之后才发生；
它不涨 ⇒ usb core 的前置检查阶段就 early return 了。

而对照面非常干净：HCIDEVUP 触发的整串初始化命令（内核约 28 条 + BlueZ device_devup_setup 约 13 条 = 41 条）零失败，配置里的 Name = TPmini 也确实写进了控制器。USB 设备从开机 2 秒枚举后从未断开，rfkill 全 1 未屏蔽，inquiry_cache / uuids / blacklist 全空。

4.2 逐个排除，直到只剩一个解释

为了把「初始化窗口」这个假说测死，写了 hcidbg（绕过 BlueZ 直接和控制器对话，子命令 info / up / down / cycle / name / scan / cod / eir / inq / fast / win）。win 只做一次 HCIDEVUP，然后按时间步长连发 Read_Local_Version，打印每次的 t 与 status。结果是窗口长度为 0：只有内核在 HCIDEVUP 内部发的命令能过，任何用户态 HCI 命令一律被拒。

顺带修了一个真 bug：/etc/bluetooth/main.conf 里写的是 Name = %m，而 %m 是 BlueZ 5.x 才支持的模板变量，4.93 不认识、展开成空串。改成字面量 Name = TPmini 后日志出现 hciops_set_name() hci0, name TPmini。也顺带用对照实验确认了 libbluetoothd.so 里虽然能看到 Discoverable / Pairable 字符串，但 4.93 的 parse_config 根本不读这两个键 —— 没法靠配置文件让设备开机即可被发现。

推论也改变了硬件策略：换 dongle 的胜率很低，因为任何 dongle 都走同一份 btusb 代码。于是路线二转向：干脆不用这个驱动。

05路线二：用 usbfs 绕过 btusb

既然内核驱动发不出命令，那就从用户态直接对 USB 设备说话：打开 /dev/bus/usb/<bus>/<dev>，用 USBDEVFS_CONTROL 发 HCI 命令，用 USBDEVFS_BULK 从中断端点 0x81 读 HCI 事件。

5.1 HCI over USB 的协议要点

static int uf_hci_cmd(unsigned int op, const unsigned char *param, int plen)
{
    struct usbdevfs_ctrltransfer ct;
    unsigned char buf[300];
    buf[0] = op & 0xff;
    buf[1] = (op >> 8) & 0xff;
    buf[2] = (unsigned char)plen;
    if (plen > 0 && param) memcpy(buf + 3, param, plen);
    memset(&ct, 0, sizeof(ct));
    ct.bRequestType = 0x20;
    ct.bRequest     = 0x00;
    ct.wLength      = 3 + plen;
    ct.timeout      = 2000;
    ct.data         = buf;
    return ioctl(g_ufd, USBDEVFS_CONTROL, &ct);
}

static int uf_read_evt(int timeout_ms, unsigned char *buf, int cap)
{
    struct usbdevfs_bulktransfer bt;
    memset(&bt, 0, sizeof(bt));
    bt.ep      = 0x81;          /* 中断 IN，bulk ioctl 同样适用 */
    bt.len     = cap;
    bt.timeout = timeout_ms;
    bt.data    = buf;
    return ioctl(g_ufd, USBDEVFS_BULK, &bt);
}

用独立的诊断工具 usbhci（子命令 ver / loop / scan / name / inq / raw）验证，结果非常振奋：

$ usbhci ver
Read_Local_Version → HCI 4.0 / 厂商 0x000A(CSR) / LMP 6

$ usbhci loop 20
连发 20 条命令，18 条成功   # 通道稳定，不是偶发

$ usbhci raw 0c13 54 50 6d 69 6e 69 ...
Write_Local_Name("TPmini") → status=0

$ usbhci raw 0c1a 03
Write_Scan_Enable=3 → status=0   # 设备进入可发现 + 可连接

5.2 怎么把 dongle 从 btusb 手里「摘」干净

usbfs 要 CLAIMINTERFACE 成功，前提是没有别的驱动占着这个接口。这段路踩了一串内核级的坑：

/* 找 CSR dongle：sysfs 的 idVendor 是十六进制字符串 "0a12"，
   atoi() 会解析成 0，strtol base 0 遇到 "0a12" 按八进制也只取前导 0，
   必须显式 base 16 —— 这个 bug 让第一版 usbscan 死活找不到设备。 */
if (n > 0) v = (int)strtol(buf, NULL, 16);
...
snprintf(g_unode, sizeof(g_unode), "/dev/bus/usb/%03d/%03d", bus, dev);

/* 只摘含 ep_81 的 HCI 接口，SCO 接口保持不动 */
if (access(ep81, F_OK) == 0) {
    snprintf(ub, sizeof(ub), "/sys/bus/usb/drivers/btusb/unbind");
    sysfs_write(ub, se->d_name);
}
usleep(300000);
g_ufd = open(g_unode, O_RDWR);
int iface = 0;
ioctl(g_ufd, USBDEVFS_CLAIMINTERFACE, &iface);  /* 注意是 int* */

工程侧还修了两个不起眼但致命的问题：设备上没有 nohup / setsid，( & ) 起的子 shell 会在 su 会话结束时被杀，改用原生 spawn 常驻；PC 侧在 MSYS_NO_PATHCONV=1 下，adb push 的本地路径必须写 D:/... 而不是 /d/...，否则 adb.exe 收到字面路径直接 cannot stat。

06第二次转向：主动 Inquiry 会把整机锁死

控制面全部打通后，自然要把 HCI_Inquiry 集成进面板「开始扫描」。结果是这八天里最硬的一堵墙，而且复现了两次、与实现细节无关。

6.1 先确认「无害命令」真的无害

在冒险触发扫描前，先用 usbhci 单独发一轮安全探针（杀掉占用 claim 的 btctl → 干净 claim → 只发单条命令）：

$ usbhci raw 1009 00                       # Read_BD_ADDR
status=0   BD_ADDR = 00:1A:7D:DA:71:13
$ usbhci ver                                # Read_Local_Version
成功
$ usbhci raw 0c13 ...                      # Write_Local_Name
成功
$ （仅 Read_Local_Name 因管道残留 stale 事件被误判超时，非 dongle 问题）
全程 PING / HTTP / adb 稳定，设备没有楔死

这同时纠正了另一个误判：之前 /api/state 里 addr 偶尔为空，并不是 dongle 不响应，而是 btctl 在杀掉 bluetoothd 后启动太快、dongle 尚未 settle 的时序问题；干净重启后地址稳定返回。

6.2 一触发 Inquiry 就整机失联

第一版 usbscan_do() 是 HCI_Reset → drain → HCI_Inquiry(0x0401) → 解析 Inquiry Result(0x02)。怀疑是 Reset 让 CSR 重载固件、在破裂的 USB 路径上产生卡死 URB，于是又编了一版去掉 HCI_Reset 的保守实现（78884 B）。两版结果完全一样：

$ curl -X POST http://192.168.1.15:8787/api/discover -d '{"on":1}'
（35 秒内无任何响应，curl rc=28 超时）

$ ping 192.168.1.15
丢包 66% ~ 100%

$ curl http://192.168.1.15:8787/api/state
超时
$ adb devices
List of devices attached   （空）

→ 唯一的恢复方式是硬断电重启（软 reboot 命令已经发不出去了）

到这里必须做方向决策。可选路径有三条：回到内核原生 btusb 路线、让 TPmini 做被动可发现目标、或者换硬件。我们选了第二条：既然 dongle 固件可以自己应答 Inquiry / Page，那就不需要主机持续收包，让别的设备来搜我们。

07路线三：被动可发现 + 自动接受连接

7.1 让 dongle 固件替我们干活

Write_Scan_Enable(3) 是一条单命令：设好后由 CSR 固件自己做 Inquiry Scan 和 Page Scan，主机不需要持续读 0x81。因此它落在「控制面」这一侧，实测完全安全：

$ curl http://192.168.1.15:8787/api/state
{
  "adapter": { "present": 1, "powered": 1,
               "addr": "00:1A:7D:DA:71:13", "discoverable": 1 },
  "hciEvents": "#1 Write_Scan_Enable=3\n#2 cmd complete op=0x0c1a st=0x00 成功"
}
$ PING 0% 丢包、HTTP 200 全程稳定 —— 未楔死

为了让「被动」也能有点交互能力，主循环从 500ms 改成 100ms，每轮做一次非阻塞事件泵，自动应答入站连接与配对事件。下面是修正后的真实源码片段：

case 0x04:  /* Connection Request: [04,len,bdaddr(6),cod(3),linktype(1)] */
    memcpy(q, &ev[2], 6);
    q[6] = 0x01;              /* Role=Slave：让发起方（手机/手柄）当 master */
    uf_hci_cmd(0x0409, q, 7); /* Accept_Connection_Request，参数必须 7 字节 */
    g_conn_attempts++;
    evlog("CONN REQ %s (link=0x%02x) -> accept(role=slave)", bd, ltype);
    break;

case 0x16:  /* PIN Code Request：BD_ADDR(6)+PIN_Len(1)+PIN(16) = 23 字节 */
    uf_hci_cmd(0x040D, q, 23);
    evlog("PIN REQ %s -> reply 0000", bd);
    break;

case 0x31:  /* IO Capability Request（SSP 第一步） -> NoInputNoOutput */
    uf_hci_cmd(0x042B, q, 9);
    break;

case 0x0f:  /* Command Status: [0f,len,status,num,op_lo,op_hi] */
    evlog("cmd status op=0x%02x%02x st=0x%02x %s",
           ev[5], ev[4], ev[2], hci_err_text(ev[2]));
    break;

7.2 手机实测：搜到了，但连不上

把手机蓝牙打开，确实搜到一台 CSR8510 A10，尝试配对。TPmini 侧的 hciEvents 把整个过程完整记了下来：

#3 CONN REQ 34:15:00:5D:2B:A4 (link=0x01) -> accept(role=slave)
#4 cmd status op=0x0409 st=0x00 成功
#5 CONN COMPLETE st=0x10 Connection Accept Timeout（对端未响应/链路建立超时）
（同样的 accept → st=0x10 连续 5 次）

结论清晰：入站连接请求确实到达、btctl 每次都自动 Accept 了，但 LMP / ACL 链路建立超时。根因是 ROM 阉割了 BlueZ 服务，而 usbfs 只有 HCI 控制面，没有 L2CAP / SDP / HIDP 主机栈去接住握手。好消息是这次没有楔死 USB 栈 —— 失败的链路不产生持续流量，反过来印证了图 3 的分界线。

7.3 顺手挖出的一批「一直在骗我们」的 bug

分析日志时发现的这些问题，本身就很值得单独记一笔：

四个配对应答的 OGF 段全被写成了 0x0Cxx（Host Controller & Baseband），实际应属于 Link Control 0x04xx —— 也就是说，之前连配对应答都发成了无关命令。对照 Linux include/net/bluetooth/hci.h 逐个改正后，HCI 层的握手才谈得上规范。但主机协议栈的缺口依然在，这是「代码正确也无法跨越」的那一层。

08第三次转向：把目标收缩成「适配器控制面板」

在确认「ROM 的蓝牙被整体阉割」「主动扫描不可能」「连接建不起来」之后，目标被主动收缩：不再追求发现别的设备，而是让 CSR8510 在 Web 面板里提供尽可能多的可控功能 —— 展示 MAC、开关蓝牙、设为可被发现（接受可能连不上）、改名，以及把连接尝试变成可见日志。

这个收缩不是放弃，而是把「能做到且不会损坏设备」的部分做扎实，同时把会楔死硬件的入口彻底封死，避免以后误触。

8.1 功能与 API

if (strcmp(path, "/api/enable") == 0) {
    /* 不再跑 bt_restart.sh：它复位 USB 层，在 3.0.36/dwc 上有楔死风险 */
    rc = act_power(1, err, sizeof(err));
} else if (strcmp(path, "/api/power") == 0) {
    rc = act_power(json_get_int(body, "on", 1), err, sizeof(err));
} else if (strcmp(path, "/api/name") == 0) {
    ...
} else if (strcmp(path, "/api/discover") == 0) {
    /* 硬限制：实测 HCI_Inquiry 的持续中断 IN 流量会锁死 dwc 主机控制器，
       整机只能硬断电重启。这里直接拒绝，绝不落到 usbscan_do()。 */
    snprintf(err, sizeof(err),
             "主动扫描已禁用：该硬件的 HCI_Inquiry 会锁死 USB 子系统（需硬断电重启）。请改用手机/手柄主动搜索本机。");
    rc = -1;
}

8.2 最终版面板长什么样

8.3 构建与验证链

# 面板源码 → 内嵌 C 数组 → 单文件 ARM 二进制
$ cd D:/tpmini_bt/release/btctl-kit
$ python src/gen_ui.py                     # ui.html → ui_data.h
$ armv7a-linux-androideabi21-clang.cmd -O2 -o bin/btctl_new src/btctl.c
rc=0   bin/btctl_new = 86308 B

# 离线校验（adb 很脆，白屏排查成本高，先在本地把 UI 验干净）
$ python -c "restore ui_data.h and compare with ui.html"
chunks=19  restored=18924  orig=18924  identical=True
$ node --check _btui_check.js
JS syntax OK

# 部署（本地路径必须 D:/ 风格；设备端以 root 执行）
$ adb push D:/.../bin/btctl_new /data/local/tmp/btctl_new
$ adb shell "su -c 'sh /data/local/tmp/deploy_btctl.sh'"
spawn btctl → PID 3433

$ curl http://192.168.1.15:8787/api/state
mode="usbfs 控制面旁路"  scanDisabled=1  connAttempts=0
hciInfo="HCI 4.0 / LMP 4.0 / CSR (0x000A) / HCI rev 8891 / LMP sub 0x22BB"
hciEvents="#1 Write_Scan_Enable=3 / #2 cmd complete op=0x0c1a st=0x00"
根页面 18924 B，Content-Length 正确，PING 0% 丢包，设备未楔死

构建期还修了一个会导致整页白屏的低级 bug：build_state() 里 "hciEvents" 字段前少了一个逗号，/api/state 返回的是无效 JSON，前端 JSON.parse 直接抛异常。修完后用解析器复验了整个状态对象，并静态核对了前后端所有字段（st.adapter / capabilityNote / connAttempts / hciEvents / hciInfo / lastConn / log / mode）与所有 POST 端点一一对应。

09最后一个坑：开机一两分钟必死

连续几次「部署后短暂正常、随即整机失联」之后，现场观察给出了决定性线索：硬重启后机器能短暂恢复，但大约一两分钟就死机断链。这个时间规律不像 USB 楔死（那种是操作当场触发），更像是某个开机后才启动的东西在慢慢作祟。

9.1 抓住上线窗口

因为窗口很短，逐轮对话必然错过，于是写了一个后台高频监测脚本（emergency_watch.sh）+ 设备端一键处置脚本（emergency_device.sh）：一旦探测到 5555 通就立刻 adb 接入，停掉事件泵、停掉自启脚本、抓取 ps / 日志 / 脚本源码。

9.2 根因：两条蓝牙路径同时抢同一个 dongle

真正的开机自启入口是 /system/etc/install-recovery.sh 里 10-28 加的那段 hook：

# --- /system/etc/install-recovery.sh ---
# --- TPMINI_BT_HOOK: bring up BlueZ (dbus + bluetoothd) after boot ---
if [ -x /data/local/tmp/bt_boot.sh ]; then
    /system/bin/sh /data/local/tmp/bt_boot.sh >/dev/null 2>&1 &
fi

# --- /data/local/tmp/bt_boot.sh（关键片段） ---
while [ $i -lt 90 ]; do                       # 等 sys.boot_completed=1
    b=$(getprop sys.boot_completed 2>/dev/null)
    [ "$b" = "1" ] && break
    sleep 2; i=$((i + 1))
done
sleep 3
if [ -f /data/local/tmp/bt_up.sh ]; then
    sh /data/local/tmp/bt_up.sh                  # ← 路径 A：拉起原生 BlueZ，btusb 开始收发 HCI
fi
...
if [ -x /data/local/tmp/btctl ]; then
    sleep 6
    /data/local/tmp/spawn /data/local/tmp/btctl_run.sh /data/local/tmp/btctl.log
                                                   # ← 路径 B：起 usbfs 旁路 btctl，unbind btusb + claim
    echo "[bt_boot] btctl started"
fi

取证日志里 Adapter /org/bluez/2665/hci0 has been enabled 与 [bt_boot] btctl started 相隔仅几秒，完全吻合。这也解释了此前多次「部署后短暂正常随即失联」：不是部署动作本身每次都致命，而是我们总在开机自启的 BlueZ 还在跑的时候，又拉起一个抢 dongle 的旁路程序。

9.3 处置：只改 /data，全部可逆

• 共 19 个文件 chmod 644 + 改名 .disabled：bt_boot.sh、bt_up.sh、bt_restart.sh、bt_down.sh、bt_status.sh、btctl* / deploy_btctl.sh / probe.sh / scan_once.sh、btctl_start/stop/demo、bringup*、go_bt* 等。
• hook 里的 [ -x bt_boot.sh ] 现在为假 → 下次开机不再拉起整套蓝牙栈。hook 文本仍在（条件为假，无害），没有去 remount /system 改它，风险更低。
• 保留 adb_tcp.sh（5555 通道）与 tune.sh（LMK / noop 调优）的 hook，设备的基础可用性不受影响。
• 顺带把一个定时炸弹一起禁了：bt_restart.sh 会做 btusb/unbind + bind 接口重绑定，正是早先实测会楔死 USB 的操作。

需要诚实补一句：这次开机时 ps 里没有 btctl 进程，所以「开机必死」并不能归咎于新版 usbscan_event_pump 单独造成（此前对它的怀疑不成立）。但事件泵每 100ms 读一次 0x81 确实属于持续流量，作为长期风险留在了清单里。

10最终做到了什么程度

能力边界（这是交付的一部分）

如果要把面板再跑起来，正确做法不是把旧自启脚本放回去，而是新建一个最小自启：只 spawn btctl_run.sh、完全不跑 bt_up.sh，让 usbfs 独占 dongle；同时把 100ms 常驻事件泵改成按需 / 低频；先手工启动观察 5~10 分钟确认不锁死，再考虑加自启。

11复盘：踩过的坑与工程教训

11.1 诊断方法上的坑

11.2 高危操作清单（这台机器专属）

11.3 工程环境与流程

11.4 最值得记住的三条

12如果重来 / 后续还能做什么

如果时间倒流，最想改的一个决定是：在第一次拿到 Write_Scan_Enable=3 成功回包时，就把目标从「主动扫描」切到「被动可发现」。当时我们已经手里握着能安全工作的一半能力，却因为执着于最初那条验收链路，又花了两轮硬重启去证明另一半不可行。当然，那两轮也换来了「控制面 / 数据面」这条最硬的结论 —— 不算白花。

A附录：产物、数字与术语

A.1 主要产物

A.2 关键数字速查

A.3 术语