Documentation
¶
Overview ¶
Package main implements cmd/boot_debug, a standalone diagnostic tool that walks the bot's BlueStacks boot sequence step-by-step and reports the state of every checkpoint with timing and diagnostic data the user can READ to understand what is happening on their machine.
The production boot path lives in internal/bot/bootorchestrator.go::Boot() and is bounded by ~215s of timeouts that hide transient state. This tool does the same steps in slow motion and writes a JSON report to logs/boot_debug.json.
The KEY questions this tool answers:
- After `open -a BlueStacks.app`, does ANY BlueStacks-VM-related process ever appear? (we want to see qemu-system-aarch64 or hd-adb or "BlueStacks Main" — not just BlueStacksAI which is the companion)
- Does any port in the candidate range [5555..5565] ever start listening? (BlueStacks 5.x on macOS occasionally opens on 5556 or 5557 instead of 5555)
- After polling adb, does `getprop ro.product.manufacturer` succeed against ANY candidate port?
Modes:
default (observe) — just record state every 2s for 60s. SAFE.
-launch — open -a BlueStacks.app, then poll for 90s.
-kill-launch — killall -9 BlueStacks + open, then poll for 90s.
DESTRUCTIVE: stops anything running in BlueStacks.
-portscan — scan all 5xxx ports + try adb connect on each.
Usage:
go run ./cmd/boot_debug go run ./cmd/boot_debug -launch go run ./cmd/boot_debug -kill-launch go run ./cmd/boot_debug -portscan
Click to show internal directories.
Click to hide internal directories.