External Research and Trade offs

External Research and Trade-offs

中文

This page defines how to use external reference implementations in the repository and records verified, durable trade-offs. It is neither a description of current behavior nor a task list. Current behavior is always defined by code, tests, and the owning technical topic.

Local references

Reference directory	Questions it can answer
external/scrcpy	Official protocol, server arguments, and socket/metadata/control semantics
external/dadb	Current ADB library behavior for authentication, transports, shell, and the helper
external/Easycontrol, external/ScrcpyForAndroid*	Android remote-control product shape, mobile integration, and local engineering strategies
external/Kadb, external/libadb-android	Alternative Kotlin/Android ADB boundaries and implementation choices
external/adb-mobile-ios	Mobile ADB/TLS research reference
external/screen-remote-ios	Form density, window rhythm, remote chrome, and asset semantics

External directories may be submodules or workspace references whose versions change. Record the inspected revision or reproducible code location before citing a conclusion.

Method

1. Classify the current problem as protocol, connection, media, control, UI, or engineering organization.
2. Read the current project's canonical topic and code to establish a baseline.
3. Select only external implementations relevant to that problem and identify their version, platform, and assumptions.
4. Express observations as a portable strategy plus conditions where it does not apply; do not copy directories or state models mechanically.
5. Verify with this project's tests, logs, or device experiments.
6. Merge verified durable conclusions into the owning canonical topic. Keep unverified ideas in issues rather than creating a second wiki design.

Durable trade-offs

Protocol and runtime

• Server arguments, metadata, control messages, and socket roles follow the bundled scrcpy version.
• Video, optional audio, and control sockets are established sequentially; concurrency in an external implementation cannot override this invariant.
• Strict protocol reads, single resource ownership, cancellable startup, and deterministic cleanup outrank local “faster” behavior.
• Do not extend private protocol semantics unless server and client change together with complete regression evidence.

ADB and connection

• dadb is the primary ADB source of truth. Other ADB projects help compare boundaries; they do not justify a parallel connection stack.
• Candidate dialing may race, while scrcpy socket establishment may not. These concurrency boundaries are distinct.
• TLS, pairing, and device identity use peer/serial semantics rather than inferring durable identity from a port or transient IP.

Codecs and performance

• Hardware, low-latency, C2, or buffer strategies are candidate preferences only and require capability checks and runtime fallback.
• External size, buffering, or decoder-selection rules are adopted only after validation on the current device matrix.
• An optimization preserves diagnostic signals and compares before/after on the same device, parameters, and operation path.

UI and assets

• The iOS prototype contributes design tokens, form density, and interaction semantics, not an Android page architecture.
• Android keeps DialogPage, section/card/row structures, and Compose lifecycle behavior; UI Design System is authoritative.
• Prefer tintable Android vectors for standard system semantics. Remote-control chrome may use reference assets when licensing and provenance are clear.
• Applied assets are represented by res/drawable* and real call sites; do not maintain a manual asset inventory that can drift.

Conclusions that do not follow

• “The external project does this, so the current project should too.”
• “The official implementation lacks a local strategy, so the local strategy must be removed.”
• “It is faster on one device, so the parameter is universal.”
• “The prototype is full screen, so Android dialogs should all be replaced.”
• “A plan item is unchecked, so the capability is definitely absent from current code.”

Research-note template

Temporary research belongs in an issue or work note and records at least: problem, current baseline, reference project and revision, differences, experiment, result, risk, and final destination. Only verified conclusions that will continue guiding implementation enter the wiki.

Canonical topics: Runtime Main Path, ADB, USB, and Wireless, Encoding and Decoding, and Engineering and Verification Rules.