Android connected is not Android ready
An attached emulator still needs a completed Android boot before installation, settings, port reversal, or interface checks can start.
An attached Android emulator is only the first condition of readiness. Our Muniment Mobile gate waits for connection, then waits for Android to finish booting. Setup stays blocked until both checks pass.
One deadline covers both checks
The gate creates one 120-second deadline. It first waits for an emulator to appear as an ADB device.
Once the device connects, the gate polls its boot-completion property. This second check gets only the time left under the original deadline. A slow connection cannot silently start another 120-second wait.
The order matters because ADB can see an emulator before Android can support the journey that follows. Connection proves that the transport can address a device. It does not prove that Android finished its startup work.
| Order | Check | Gate state |
|---|---|---|
| 1 | An ADB device appears | Connected, still not ready |
| 2 | Android reports boot completion | Ready for setup |
Only the second result opens the gate. Installation, settings, port reversal, and interface flows all remain behind it.
A failed query still means not ready
The property query can fail temporarily while the emulator continues to boot. Our gate treats that failure as a not-ready result and polls again within the shared deadline.
That choice keeps uncertainty on the safe side of the boundary. A query failure supplies no affirmative boot-completion result. Letting setup proceed would turn missing evidence into permission.
An incomplete response receives the same treatment. Connection remains established, but readiness remains false until Android reports completion.
The regression tests hold the order
Stubbed regression coverage makes the boundary observable. One case returns a failed property query, then an incomplete response, before returning boot completion.
The test verifies that setup waits through those earlier results. It also verifies the order: connection comes first, boot polling follows, and setup comes last.
Another case never reports boot completion. The shared deadline expires before installation, settings, port reversal, or an interface flow starts.
These stubs test control flow rather than an emulator’s actual startup. They can prove that a temporary query failure does not bypass the gate.
This evidence comes from our Muniment Mobile note pinned to commit 8da44fbf3881992cc400.
The evidence neither validates the 120-second deadline nor benchmarks emulator startup time. It does not establish an optimal deadline across CI hosts.
A readiness gate should advance on affirmative readiness. Mere attachment, silence, and temporary query failure all belong on the waiting side.
For a device retry failure, inspect the structured test report before the console log.