ADB and dadb

ADB and dadb

中文

Boundary

external/dadb is the shared foundation for ADB transport, authentication, streams, forwarding, remote helper, and reusable device operations. The macOS app owns Swift concurrency adaptation, application state, windows, UI, and scrcpy-specific media/session orchestration. Do not duplicate growing shell queries and text parsers in both platform applications when the operation belongs behind dadb's stable helper protocol.

Current helper path

The Xcode target builds external/dadb:dadb-helper:dexJar, bundles dadb-helper.jar and its license, and DADBHelperRuntime.swift verifies/deploys the JAR to /data/local/tmp/dadb-helper.jar through the configured ADB executable. It then invokes helper main classes through app_process.

For device information, the app uses dadb.helper.ManagementSnapshotMain device and expects DADB_MANAGEMENT\tDEVICE followed by D\t<wireName>\t<base64 value>\t<base64 error> records. A missing vendor field is non-fatal: retain its English diagnostic detail, omit the empty UI row, and render remaining information.

Rules for new operations

• UI does not directly own Process lifecycle or parse large shell output; put reusable transport in an ADB service/helper boundary.
• Reuse the existing helper runtime rather than bundle a second JAR or invent a second remote location.
• Application, helper, protocol, event, and diagnostic details are English-only. Convert safe summaries into localized user-visible strings; do not leak raw helper detail into UI.
• Direct terminal ADB is for permitted diagnostics only. Application helper deployment is managed by the app runtime unless a task explicitly addresses deployment.

Verification

Check unavailable ADB, authentication/connection failure, timeout, disconnect, malformed helper records, and partial device data. When ADB/session behavior changes, compare semantics with the Android implementation and dadb rather than translating JVM implementation line by line.