【HarmonyOS 7 商用机型】uitest 服务两个问题：daemon 未自启动阻塞 aa test；UiDriver 注入触点无法到达应用窗口组件手势

设备与版本：HUAWEI JDY-AL50，HarmonyOS 7.0.0.109（SP6C00E105R4P3），1080×2406；hdc shell 以 uid 2000（shell）运行。以下均为该机型该版本实测结论，未验证其他机型/版本。

我们在维护一款鸿蒙自动化测试工具，需要通过 UiTest API 注入多点触摸轨迹（Driver.injectMultiPointerAction + PointerMatrix）做手势保真验证。实测中发现两个系统层问题，均有可复现配方，希望得到官方确认或指引。

问题一：uitest daemon 未自启动，aa test 直接阻塞失败

现象：在 aa test 运行的测试用例里调用 UiDriver API（如 PointerMatrix.create）返回 null，并伴随：

UiTestKit_Conn: WaitForPublishedCaller - Wait for ApiCaller publish by server timeout
UiTestKit_Client: uitest_napi.cpp UnmarshalReply: code=17000006, message='ipc connection is dead'
系统日志明示：uitest_daemon need to be pre-started

临时方案（已验证有效）：在同一 shell 会话先拉起 daemon 再跑测试：

hdc -t <serial> shell 'uitest start-daemon <token> & sleep 1.5; aa test -b <bundle> -m <module> ...'

期望：aa test 流程自动拉起 daemon，或在官方文档中明示该前置步骤。开源 OpenHarmony 的 aa test 流程不需要这一步，商用机行为差异容易让开发者排查很久（我们定位此问题花费了数个迭代）。

问题二：注入触点可到达系统层窗口，但无法触发应用窗口内组件锚定的手势

现象：injectMultiPointerAction 返回成功，触摸流能驱动系统层界面（实测滚动过了系统协议页），但普通应用窗口内锚定了 ArkUI PanGesture 的组件始终不识别手势。

对照实验（同一滑块测试页、同一坐标、同一速度；oracle 为页面自带的姿态判定行，RESULT=NONE 表示手势未触发，PASS/FAIL 表示手势已触发仅判定结果不同）：

即：注入形态无关（直线/细粒度/突发均不触发），两条通道的事件构造在源码上同构（最终都经 SysUiController::InjectTouchEventSequence → SimulateInputEvent），差异在执行上下文或注入路由层——app 进程发起的注入（经 IPC 到 daemon）与 shell CLI 直接发起的注入，到达应用窗口组件手势的行为不同。

期望：确认该行为是否符合预期；若为权限/路由模型设计如此，希望文档说明；否则希望修复使 app 侧注入与 shell 侧注入行为一致。

同机型观察到的相关限制（供参考）

• shell 用户访问 /proc/bus/input/devices、/dev/input/*、/sys/class/input/* 全部被拒，uinput sendevent 原始事件注入通道不可用；
• hdc shell 不向客户端透传远端命令退出码（远端 false 客户端仍返回 0），且远端 stderr 并入客户端 stdout；
• uitest uiRecord record 的 CSV 缓冲到 SIGINT 才落盘，且录制进程与并发注入会话互斥。

附：英文原文（复现配方与完整上下文）

Device: HUAWEI JDY-AL50, HarmonyOS 7.0.0.109 (SP6C00E105R4P3). hdc shell runs as uid 2000 (shell).

Harness: one debug-signed carrier HAP whose ohosTest module injects a PointerMatrix through Driver.injectMultiPointerAction, driven by aa test -s traj <json>; the verdict returns on hilog.

Problem 1: the uitest daemon is not started on these builds, and aa test blocks without an undocumented pre-start step (uitest start-daemon <token> & in the same shell session). Symptom: PointerMatrix.create returns null, uitest_napi.cpp UnmarshalReply code=17000006 ipc connection is dead, WaitForPublishedCaller - Wait for ApiCaller publish by server timeout, and the system log states uitest_daemon need to be pre-started.

Problem 2: injectMultiPointerAction reports success and its touch stream drives system-layer surfaces (it scrolled the OS agreement page), but a component anchored to an ArkUI PanGesture in an ordinary app window never sees the gesture. Comparison runs (same slider fixture, same coordinates, same speed; RESULT=NONE = gesture never fired, PASS/FAIL = fired): uitest uiInput swipe fired 3/3 (350 px/s passed; 200 px/s mis-judged a fail - both prove the gesture fired), while the carrier injected 0/4 across shapes (2-point line with a 1.4 s hold then a 500 px jump; 41 points x 12 px fine steps; 51-point burst at 40000 px/s finishing in 49 ms). Both transports share the event-construction path (SysUiController::InjectTouchEventSequence -> SimulateInputEvent), so the difference sits in the execution context or injection routing, not the event shape.

Related shell-surface restrictions on the same build: /proc/bus/input/devices, /dev/input/*, /sys/class/input/* denied to uid 2000 (so raw evdev injection via uinput sendevent cannot run); hdc shell does not propagate remote exit codes and merges remote stderr into client stdout; uitest uiRecord record buffers its CSV until SIGINT and conflicts with concurrent injection sessions.