fix(adb): immune to adb-version conflicts + live-bound port detection#16
Merged
Merged
Conversation
Boot-And-Wait was throwing "instance '<x>' did not boot / become
adb-reachable within 300 s" on hosts that ALSO have a different-version
system adb (Android SDK platform-tools v1.0.41) alongside BlueStacks'
HD-Adb v1.0.36. The two kill each other's adb server on the shared
default port 5037 ("server version doesn't match this client; killing"),
so getprop sys.boot_completed fails forever even though the instance
booted fine. Nothing about the instance is wrong.
- Pin HD-Adb to its OWN server port (ANDROID_ADB_SERVER_PORT=15037) and
only ever use HD-Adb.exe (Resolve-HdAdb; never a system adb.exe).
- Merge the live-bound listening port (Get-NetTCPConnection, band
5550-5900) into Get-AdbPortCandidates, AFTER the conf ports, to rescue
a stale status.adb_port. Deterministic test seam for the live scan.
- Mirror the server isolation in the engine's Connect-WaitBoot.
- Run-Resolve-Tests: + probe seam and 3 merge/dedup cases (now 25);
re-embedded into blueStackRoot.cmd; Check-Embedded-Sync + Run-Tests (28) pass.
Proven live with a v41 server on 5037: isolated getprop 30/30 OK, shared-port
control 0/12 (exact reporter error), port detection 20/20 stable, full
Boot-And-Wait end-to-end PASS.
…E->v11 Addresses "what if 15037 is already in use before my session": - Resolve-AdbServerPort probes 15037..15057 and uses the first FREE port (reusing our own HD-Adb server if already up), so a non-adb app or a foreign-version adb already on 15037 is skipped, never fought. Explicit ANDROID_ADB_SERVER_PORT still wins. Mirrored in bsr_engine.ps1. - Release our private adb server on exit (kill-server in a finally), so nothing of ours lingers on the port after the tool finishes. - Run-Resolve-Tests: +6 free-port cases (now 31). Re-embedded; suites green. - README: download link v9 -> v11; BlueStacks version 5.22.169 -> 5.22.210 (the version we ran the boot/adb path on this session). Verified live (real, non-stubbed probe): non-adb listener on 15037 -> tool picks 15038; our own HD-Adb server on 15037 -> reused.
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.
The report
A user hit
instance '<name>' did not boot / become adb-reachable within 300 seven though the instance was fully booted (Home visible, Magisk installed). The instance was never the problem.Root cause (reproduced on this machine)
The host had a system
adbof a different version — Android SDK platform-tools v1.0.41 at…\Android\Sdk\platform-tools\adb.exe— alongside BlueStacks' bundled HD-Adb v1.0.36. When both touch the default adb server port 5037, they kill each other:So every
getprop sys.boot_completedthe tool issued failed, andBoot-And-Waittimed out at the throw.The fix (host-side adb plumbing only)
ANDROID_ADB_SERVER_PORT=15037, and only ever useHD-Adb.exe(Resolve-HdAdb, never a systemadb.exe). A foreign-version adb on 5037 can no longer touch our server. (HD-Adb v1.0.36 honours the env var — verified.)Get-AdbPortCandidatesnow also consults the actually-bound listening port (Get-NetTCPConnection, band 5550-5900), merged after thebluestacks.confstatus.adb_port/adb_portvalues (which stay authoritative). Rescues the boot wait when the conf is stale.Connect-WaitBoot.Validation (live, on
Tiramisu64_9)cands=[5645,5555]identical all 20×, 0 missed the real portBoot-And-Waitwith v41 squatting 5037boot_completed=1,Is-BlueStacks=TrueAlso note: conf
status.adb_port=5646was stale while the instance was really on 5645 — the live scan found 5645 independently (the second value of the port-detection hardening).Tests
tests/Run-Resolve-Tests.ps1: deterministic probe seam + 3 new conf+live merge/dedup cases → 25/25tests/Run-Tests.ps1→ 28/28tests/Check-Embedded-Sync.ps1→ engine + orchestrator + APK in sync (re-embeddedblueStackRoot.cmd)