Skip to content

investigate(android): separate ADB transport addressing from device-command payload #2617

Description

@thymikee

investigate(android): separate ADB transport addressing from device-command payload

Question and evidence

Can typed transport addressing eliminate repeated flattening/reparsing of ADB arguments while preserving local, provider and managed-device routing?

At PR #2611 a3a0ea216356813323b0008642c05f6f5dc57fcc, transport prefixes and device commands share one argv. Provider scope reads and strips serials, Limrun adds one again, managed-host wiring rewrites ports, and generic host copies relay device-shell provenance.

Evidence: kernel construction/relay, packages/platform-android/src/adb-provider-scope.ts, Limrun prefix, managed host normalization, and src/platform-runtime-host.ts / src/platform-runtime-operation-host.ts.

Investigation scope

This issue authorizes a bounded design trace and disposable prototype, not a production migration.

  1. Trace local device execution, provider-scoped forwarding, managed server-port substitution, generic host ingress and background spawn. Inventory accepted addressing forms and global commands; do not assume serial and serverPort represent the entire ADB grammar.
  2. Compare keeping the existing argv design with a narrow immutable command plus typed addressing. Illustrative shape only: { target, command }, where target carries validated transport selection and the shell command retains kernel-owned quoting/provenance. Identify where generic argv enters and where final argv is serialized.
  3. Demonstrate the smallest prototype across local, provider and managed routes. Preserve fix(device-shell): one typed device-shell boundary for adb, exec-out, and hdc #2611 refusal behavior, explicit shell fragments, device isolation, requested/managed-port rules, binary output and lazy loading. Preserve existing spawn behavior; do not claim fix(device-shell): one typed device-shell boundary for adb, exec-out, and hdc #2611 already guards every spawn.
  4. Enumerate every relay/parser removed, any new parser/adapter, and the remaining execution boundaries. Reuse existing owners; no global invocation registry or generic command framework.

Acceptance and stop criteria

  • Deliver a route diagram/table and concrete proposed API, with an explicit continue/stop recommendation and implementation cut set.
  • In the prototype, serial selection/port substitution operate on addressing without copying or reconstructing shell payloads. Show whether generic host copies can lose shell-specific relay knowledge; report residual exceptions honestly.
  • Characterize ordinary and shell/exec-out commands, explicit serial mismatch, global/host-preconfigured commands, managed forbidden commands, port precedence, provider forwarding and binary results against the current path. Use existing transport/provider tests, not only a new synthetic executor.
  • Report changes in independently authored routing/provenance decisions, production LOC and eager closure. Stop if complexity merely moves into an equivalent number of bridges, weakens enforcement, or needs unrelated lifecycle changes.
  • Record any released executor API affected and compatibility obligations before recommending migration. A production proposal must include exact validation lanes and unresolved native/provider evidence; do not mark this issue as a completed implementation.

Dependencies and exclusions

Blocked by: #2611 landing. Re-audit its merged transport shape first. #2026 owns quoting and the exhaustive current migration; this investigation must not broaden or block it. #2545 owns daemon/root closure, not ADB invocation representation. No HarmonyOS redesign, provider admission redesign, new enforcement framework or issue-driven production changes in this spike.

Effort: M for investigation; production migration likely L. Risk: medium–high for a later migration because routing and device isolation depend on normalization. No existing issue found for separating these representations.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions