From 3ba475d7de475d672468ba9d3262705ac254125e Mon Sep 17 00:00:00 2001 From: PJ Date: Sat, 25 Apr 2026 19:20:59 +0700 Subject: [PATCH] docs: remove in-app SDK from architecture doc --- docs/development/architecture.md | 22 +++++++--------------- 1 file changed, 7 insertions(+), 15 deletions(-) diff --git a/docs/development/architecture.md b/docs/development/architecture.md index a07c6d8..7b143df 100644 --- a/docs/development/architecture.md +++ b/docs/development/architecture.md @@ -15,15 +15,12 @@ flowchart TB end SC["Maestro sidecar (JVM)"] - SDK["in-app SDK\n(Device / Emulator)"] CH["Chrome (CDP)"] RD[("runs/")] IN["sanderling inspect\nHTTP + SSE"] UI["Web UI (React)"] D -->|gRPC| SC - SC -->|UIAutomator / XCTest| SDK - R -->|"Unix socket
(pause / state / logs)"| SDK D -->|CDP| CH T --> RD --> IN --> UI @@ -35,16 +32,13 @@ flowchart TB **Maestro sidecar (JVM).** A Kotlin process that wraps `maestro-client` and exposes a gRPC surface matching the `DeviceDriver` interface. Handles UI input, screenshots, the system accessibility tree, and OS-level alerts. Native platforms only. -**In-app SDK.** A Kotlin (or Swift for iOS) library linked into the app under test. Exposes a Unix socket to the runner. Provides pause and resume, view-hierarchy dumps, coverage reads, log capture, and user-registered state extractors. Native platforms only. - -**Chrome (CDP).** For web targets, the Go binary drives Chrome directly over the Chrome DevTools Protocol. No sidecar or in-app SDK is involved. +**Chrome (CDP).** For web targets, the Go binary drives Chrome directly over the Chrome DevTools Protocol. No sidecar is involved. ## Transports | Channel | Platform | Transport | Purpose | |---|---|---|---| | Go to Maestro sidecar | Native | gRPC (localhost TCP) | UI input, screenshots, system alerts | -| Go to in-app SDK | Native | Unix domain socket | Pause / resume, hierarchy, coverage, logs, extractors | | Go to Chrome | Web | Chrome DevTools Protocol | UI input, screenshots, DOM hierarchy, console logs | On native, the transport split exists because only real UI events need to cross process and OS-API boundaries. Introspection is cheap, frequent, and lives on a fast local socket directly to the app. On web, CDP handles both. @@ -64,17 +58,15 @@ pause ─► capture state ─► evaluate properties ─► pick action **Native (Android / iOS):** 1. The runner asks the driver to wait until the UI is idle. -2. The runner sends `PAUSE` to the SDK over the Unix socket. The SDK freezes the main runloop at a safe point. -3. The SDK sends back a `STATE` message: view hierarchy, coverage delta, logs since last step, exception list, snapshot values. -4. The runner feeds state into goja. Extractors re-read; properties re-evaluate; the action generator returns a weighted tree. -5. The runner writes the trace entry for this step. -6. The runner picks an action by weight. -7. The runner sends `RESUME` to the SDK, then dispatches the action through the driver (gRPC to sidecar → Maestro → UIAutomator or XCTest). -8. Loop. +2. The runner fetches the UI hierarchy and logs from the sidecar. +3. The runner feeds state into goja. Extractors re-read; properties re-evaluate; the action generator returns a weighted tree. +4. The runner writes the trace entry for this step. +5. The runner picks an action by weight and dispatches it through the driver (gRPC to sidecar -> Maestro -> UIAutomator or XCTest). +6. Loop. **Web (Chrome):** -Steps 2-3 use CDP to capture the DOM hierarchy and console logs directly; there is no SDK pause/resume. The rest of the cycle is identical. +CDP captures the DOM hierarchy and console logs directly. The rest of the cycle is identical. The cycle runs hundreds of times per minute. Every step produces one row in `trace.jsonl` and one screenshot.