Termux API 通知监听策略

核心发现

Termux API 的 termux-notification-list 可以读取系统通知栏，包括微信消息通知。这为消息监听提供了第二通道。

双通道监听架构

通道 A: DB 轮询（主推）
  ├─ 优点: 完整消息内容、历史消息可追溯
  ├─ 缺点: 10秒延迟、IO开销
  └─ 适用: 所有消息类型

通道 B: 通知监听（辅助）
  ├─ 优点: 实时性高（通知即时触发）、零IO
  ├─ 缺点: 内容可能被截断、锁屏/免打扰时缺失、无群聊完整信息
  └─ 适用: 新消息触发器（收到通知后触发一次DB轮询）

混合策略实现

# 在 hermes_wechat_daemon.py 中增加通知轮询线程

def poll_notifications():
    """Poll notifications via termux-notification-list."""
    known_keys = set()  # (pkgName, title, content) hash

    while True:
        ok, stdout, _ = run_termux_api(["termux-notification-list"])
        if ok:
            notifs = json.loads(stdout)
            wechat_notifs = [n for n in notifs if n.get("pkgName") == "com.tencent.mm"]

            for n in wechat_notifs:
                key = hash((n.get("title"), n.get("content")))
                if key not in known_keys:
                    known_keys.add(key)
                    # 触发一次紧急DB轮询（不等待常规轮询周期）
                    trigger_urgent_poll()

        time.sleep(3)  # 通知轮询更频繁

Termux:API 权限要求

1. 通知访问权限: 设置 → 应用 → Termux:API → 通知访问 → 允许
2. 电池优化: 关闭 Termux 和 Termux:API 的电池优化
3. 自启动: 允许 Termux 后台运行

与现有 LSPosed 模块的配合

功能	LSPosed 模块	Termux API	DB 轮询
发送消息	✅ Broadcast	❌	❌
接收消息（完整）	❌（hook未触发）	⚠️（可能截断）	✅
接收触发（实时）	❌	✅	❌（10s延迟）
历史消息	❌	❌	✅
群聊 @识别	❌	⚠️	✅

最优方案: 通知作为触发器 → 立即执行 DB 轮询获取完整内容 → LLM 处理 → LSPosed 发送回复

Termux X11 的作用

Termux X11 提供 X11 服务器，可在 proot 中运行图形应用（如 Firefox、VS Code）。

对微信自动化的直接帮助有限:

• 微信是 Android 原生应用，不是 X11 应用
• 但可以在 X11 中运行图形化调试工具（如 sqlitebrowser 查看解密后的 DB）
• 可运行 Python GUI 脚本进行可视化监控

Termux Boot 的作用

确保手机重启后自动恢复全部服务:

1. 启动 frida-server
2. 启动微信
3. 启动守护进程
4. 发送启动确认通知