Repository navigation
feat(harmony): drive HarmonyOS devices over hdc #767
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -146,7 +146,7 @@ export interface ToolContext extends InvokeToolOptions { | |
|
|
||
| // ── Device + Capability Types ── | ||
|
|
||
| export type Platform = "ios" | "android" | "ios-remote" | "chromium" | "vega" | "harmony"; | ||
|
Collaborator
There was a problem hiding this comment. Widening
Member
Author
There was a problem hiding this comment. [Diplomat]: Acknowledged, and deliberately not gated in code in 4ade1c2. A flow with a harmony device fails per-step only if a step reads the tree — a flow of pure |
||
|
|
||
| export type DeviceKind = "simulator" | "emulator" | "vvd" | "device" | "app" | "unknown"; | ||
|
|
||
|
|
@@ -195,6 +195,16 @@ export interface ToolCapability { | |
| vvd?: boolean; | ||
| device?: boolean; | ||
| }; | ||
| /** | ||
| * HarmonyOS support. `device` is a phone reached over `hdc`; `emulator` is a | ||
| * DevEco Studio instance, which only `boot-device` addresses — every | ||
| * interaction tool drives a *connected* target, and a booted emulator presents | ||
| * as one of those, so interaction tools declare `device` alone. | ||
| */ | ||
| harmony?: { | ||
| emulator?: boolean; | ||
| device?: boolean; | ||
| }; | ||
| /** Optional refiner. Returns true if this device is supported. */ | ||
| supports?: (device: DeviceInfo) => boolean; | ||
| } | ||
|
|
@@ -219,7 +229,14 @@ export interface ToolCapability { | |
| * On a missing binary, the HTTP layer returns 424 Failed Dependency with an | ||
| * install hint the agent can surface verbatim. | ||
| */ | ||
| export type ToolDependency = | ||
| | "adb" | ||
| | "xcrun" | ||
| | "emulator" | ||
| | "sim-remote" | ||
| | "vega" | ||
| | "harmony-emulator" | ||
| | "hdc"; | ||
|
|
||
| // ── Tool Types ── | ||
|
|
||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -8,7 +8,7 @@ import type { | |
| ToolDefinition, | ||
| } from "@argent/registry"; | ||
| import { chromiumCdpRef, type ChromiumCdpApi } from "../../blueprints/chromium-cdp"; | ||
| import { resolveDevice, harmonyConnectKey } from "../../utils/device-info"; | ||
| import { isTvOsSimulator } from "../../utils/ios-devices"; | ||
| import { isAndroidTv } from "../../utils/adb"; | ||
| import { assertSupported } from "../../utils/capability"; | ||
|
|
@@ -18,6 +18,7 @@ import type { DescribeNode, DescribeTreeData } from "../describe/contract"; | |
| import { describeIos, iosRequires } from "../describe/platforms/ios"; | ||
| import { describeAndroid, androidRequires } from "../describe/platforms/android"; | ||
| import { describeChromium } from "../describe/platforms/chromium"; | ||
| import { describeHarmony, harmonyRequires } from "../describe/platforms/harmony"; | ||
|
|
||
| export const AWAIT_SCREEN_IDLE_TOOL_ID = "await-screen-idle"; | ||
|
|
||
|
|
@@ -29,7 +30,9 @@ const zodSchema = z.object({ | |
| udid: z | ||
| .string() | ||
| .min(1) | ||
| .describe( | ||
| "Target device id from `list-devices` (iOS UDID, Android serial, HarmonyOS id, or Chromium id)." | ||
| ), | ||
| timeoutMs: z | ||
| .number() | ||
| .int() | ||
|
|
@@ -72,6 +75,7 @@ const capability: ToolCapability = { | |
| apple: { simulator: true, device: true }, | ||
| android: { emulator: true, device: true, unknown: true }, | ||
| chromium: { app: true }, | ||
| harmony: { device: true }, | ||
| }; | ||
|
|
||
| // A cheap fingerprint of the screen: role + label + value + frame (rounded to | ||
|
|
@@ -109,6 +113,9 @@ export function createAwaitScreenIdleTool(registry: Registry): ToolDefinition<Pa | |
| if (device.platform === "android") { | ||
| return describeAndroid(registry, device.id, undefined, androidIsTv); | ||
| } | ||
| if (device.platform === "harmony") { | ||
| return describeHarmony(harmonyConnectKey(device.id)); | ||
|
Collaborator
There was a problem hiding this comment. Errors from this fetch are dropped from the result, so a device that goes away mid-wait is reported as a screen that did not settle. Against an unreachable connect key the tool returns HTTP 200
Member
Author
There was a problem hiding this comment. [Diplomat]: Fixed in 4ade1c2. A device that goes away mid-wait was indistinguishable from a screen that stayed busy. await-screen-idle now folds the poll loop's |
||
| } | ||
| return describeChromium(services.chromium as ChromiumCdpApi); | ||
| } | ||
|
|
||
|
|
@@ -144,6 +151,7 @@ still before the timeout. Use after a launch/navigation to wait for the UI to re | |
| assertSupported(AWAIT_SCREEN_IDLE_TOOL_ID, capability, device); | ||
| if (device.platform === "ios") await ensureDeps(iosRequires); | ||
| else if (device.platform === "android") await ensureDeps(androidRequires); | ||
| else if (device.platform === "harmony") await ensureDeps(harmonyRequires); | ||
|
|
||
| // Resolved once, outside the poll loop, like `isTvOs` — an unlisted | ||
| // serial's TV probe is never cached, so leaving it inside | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -8,7 +8,7 @@ import type { | |
| ToolDefinition, | ||
| } from "@argent/registry"; | ||
| import { chromiumCdpRef, type ChromiumCdpApi } from "../../blueprints/chromium-cdp"; | ||
| import { resolveDevice, harmonyConnectKey } from "../../utils/device-info"; | ||
| import { isTvOsSimulator } from "../../utils/ios-devices"; | ||
| import { isAndroidTv } from "../../utils/adb"; | ||
| import { assertSupported } from "../../utils/capability"; | ||
|
|
@@ -19,6 +19,7 @@ import { describeIos, iosRequires } from "../describe/platforms/ios"; | |
| import { describeAndroid, androidRequires } from "../describe/platforms/android"; | ||
| import { describeChromium } from "../describe/platforms/chromium"; | ||
| import { describeVega, vegaRequires } from "../describe/platforms/vega"; | ||
| import { describeHarmony, harmonyRequires } from "../describe/platforms/harmony"; | ||
| import { | ||
| selectorSchema, | ||
| nodeText, | ||
|
|
@@ -57,7 +58,9 @@ const zodSchema = z | |
| udid: z | ||
| .string() | ||
| .min(1) | ||
| .describe( | ||
| "Target device id from `list-devices` (iOS UDID, Android serial, HarmonyOS id, or Chromium id)." | ||
| ), | ||
| condition: z | ||
| .enum(["exists", "visible", "hidden", "text"]) | ||
| .describe( | ||
|
|
@@ -136,6 +139,7 @@ const capability: ToolCapability = { | |
| android: { emulator: true, device: true, unknown: true }, | ||
| chromium: { app: true }, | ||
| vega: { vvd: true }, | ||
| harmony: { device: true }, | ||
| }; | ||
|
|
||
| // ── Tree matching ──────────────────────────────────────────────────────── | ||
|
|
@@ -243,6 +247,9 @@ export function createAwaitUiElementTool(registry: Registry): ToolDefinition<Par | |
| if (device.platform === "vega") { | ||
| return describeVega(device.id); | ||
| } | ||
| if (device.platform === "harmony") { | ||
| return describeHarmony(harmonyConnectKey(device.id)); | ||
|
Collaborator
There was a problem hiding this comment. The tree this returns carries the asleep hint when the panel is off, but the hint is only folded into the note on the timeout path - a wait that succeeds says nothing about it. With
Member
Author
There was a problem hiding this comment. [Diplomat]: Fixed in 4ade1c2. A successful wait against the last-composited frame was the dishonest half — the hint only rode the timeout path. A success whose tree carried the hint now surfaces it in the result's |
||
| } | ||
|
coderabbitai[bot] marked this conversation as resolved.
|
||
| return describeChromium(services.chromium as ChromiumCdpApi); | ||
| } | ||
|
|
||
|
|
@@ -298,6 +305,7 @@ or before tapping an element that appears asynchronously.`, | |
| if (device.platform === "ios") await ensureDeps(iosRequires); | ||
| else if (device.platform === "android") await ensureDeps(androidRequires); | ||
| else if (device.platform === "vega") await ensureDeps(vegaRequires); | ||
| else if (device.platform === "harmony") await ensureDeps(harmonyRequires); | ||
|
|
||
| // Resolve once, outside the poll loop — re-probing `xcrun` per fetch would | ||
| // blow the per-fetch budget for a fake UDID that never caches. Same for | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[Diplomat]: Docs promise 501 for the unsupported HarmonyOS tools; every one of them actually returns 400.
The README (and two skill docs) state that the HarmonyOS-unsupported tools return
501 NotImplementedOnPlatform; every one of them returns400instead. Trigger: callgesture-pinch,gesture-rotate,gesture-custom,rotate, any profiler tool, or any debugger tool with aharmony-<connectKey>id. None of those tools declares aharmonyblock in itscapability(gesture-pinch/index.ts:66, gesture-rotate/index.ts:86, gesture-custom/index.ts:51, rotate/index.ts:20, native-profiler-start.ts:51, andRN_ONLY_TOOL_CAPABILITY/DEBUGGER_TOOL_CAPABILITYin debugger/debugger-service-ref.ts:60 and :20), so the HTTP capability gate at http.ts:791-808 throwsUnsupportedOperationErrorand answers400withTOOL_CAPABILITY_UNSUPPORTED_OPERATIONand the message "Tool '' is not supported on harmony device." The501/NotImplementedOnPlatformErrorpath is only reachable fromdispatchByPlatform(utils/cross-platform-tool.ts:147) when a capability does declareharmonybut wires no branch — and every tool in this PR that declaresharmony:also wires a handler, so no shi …There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[Diplomat]: Fixed in 1840a2b.
Confirmed against a live server, not just a read: stood up
createHttpAppfrom this branch'sdist/with the real tool definitions and POSTed aharmony-id.Re-run with
harmony-emulator-argent_phone: identical 400s ("…on harmony emulator"), so the README's explicit "on both device kinds" was wrong on both kinds.I checked whether this is loose house style before changing anything, and it is not.
README.md:32was the only occurrence of501in any markdown in the repo, and the nearest twin describing the identical mechanism names the gate and the literal message instead:argent-metro-debugger/SKILL.md:12— "are RN-only and reject Chromium at the capability gate withTool 'X' is not supported on chromium app".Worse than the wrong number, the class named is the opposite of the reason printed beside it.
capability.ts:34-43reservesNotImplementedOnPlatformErrorfor "capability could say yes once filled in; the work just hasn't happened", and gives pinch on Android — adb has no multi-touch as theUnsupportedOperationErrorexample. One contact and/dev/inputdenied is that first case verbatim. So the docs now say the tools are refused at the capability gate with the literal message they actually produce; the code is correct as it stands.