adb: resolve to known-good binary instead of trusting PATH order#49
Merged
adb: resolve to known-good binary instead of trusting PATH order#49
Conversation
Surfaced during the first real Layer 3 visual smoke against a booted Android emulator. The agent's installAndLaunch (#39) and captureScreenshot (#38) were calling `adb` via the PATH-resolved binary, which on this dev machine was `~/.apportable/SDK/bin/adb` — an i386 Mach-O from 2014 that fails to exec on Apple Silicon with "spawn Unknown system error -86". Visible adb installs (Android Studio default, /Applications/android- sdk-macosx, Homebrew) were further down PATH and never reached. New helper resolveAdbPath() in src/adb.ts walks a fixed priority order: env-var locations first ($ANDROID_HOME, $ANDROID_SDK_ROOT), then known macOS install paths (Android Studio default, the older /Applications/android-sdk-macosx, /opt/homebrew, /usr/local), and falls back to "adb" via PATH. First existing path wins. src/validation/capture.ts (Android branch) and src/validation/launch.ts (install + launch) now resolve via this helper instead of trusting PATH. Real-mode smoke confirms the fix: on this machine, adb now resolves to /Applications/android-sdk-macosx/platform-tools/adb (universal binary, x86_64+arm64). The Apple Silicon spawn error is gone. Newly-surfaced (separate concern, documented in README): when multiple Android targets are attached (e.g. physical device + emulator), adb requires ANDROID_SERIAL=<serial> to disambiguate. This is a stock adb feature, not something the agent needs to implement — the agent runs adb directly and inherits the env var. Tests: 19/19 npm run ci green. (No adb-specific test in CI since that requires a real Android SDK; resolution logic is verified by the real-mode smoke output above.) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Surfaced during the first real Layer 3 visual smoke against a booted Android emulator. The agent's
installAndLaunch(#39) andcaptureScreenshot(#38) were callingadbvia PATH, which on this dev machine was~/.apportable/SDK/bin/adb— an i386 Mach-O from 2014 that fails to exec on Apple Silicon with"spawn Unknown system error -86". Visible adb installs (Android Studio default,/Applications/android-sdk-macosx, Homebrew) were further down PATH and never reached.Resolution priority
New helper
resolveAdbPath()insrc/adb.ts:$ANDROID_HOME/platform-tools/adb$ANDROID_SDK_ROOT/platform-tools/adb(legacy spelling)~/Library/Android/sdk/platform-tools/adb(Android Studio default on macOS)/Applications/android-sdk-macosx/platform-tools/adb(older standalone install)/opt/homebrew/bin/adb(Homebrew on Apple Silicon)/usr/local/bin/adb(Homebrew on Intel)"adb"(fall back to PATH)First existing path wins.
src/validation/capture.ts(Android branch) andsrc/validation/launch.ts(install + launch) now use this helper instead of trusting PATH.Real-mode smoke
On this dev machine, adb now resolves to
/Applications/android-sdk-macosx/platform-tools/adb(universal binary). The Apple Silicon spawn error is gone.Newly-surfaced (separate concern, documented in README)
When multiple Android targets are attached (e.g. physical device + emulator),
adbrequiresANDROID_SERIAL=<serial>to disambiguate. This is a stock adb feature, not something the agent needs to implement — the agent runsadbdirectly and inherits the env var. README's "Optional flags" section now documents both the resolution priority and the disambiguator.Test plan
npm run ci— 19/19 green.resolveAdbPath()real-mode lookup returns/Applications/android-sdk-macosx/platform-tools/adb(universal binary) on this machine.captureScreenshot({platform: "android"})no longer hits the i386 spawn error; surfaces the multi-device disambiguation message cleanly.NATIVEAPPTEMPLATE_VISUAL=1 npm run dev -- "..."withANDROID_SERIAL=emulator-5554to confirm full Android Layer 3 path works.🤖 Generated with Claude Code