start
Binds the embedded server and opens the browser dashboard. The SDK never does this on its own -- initialize only prepares capture/storage, so nothing is reachable over the network until a host calls this (or startBrowserAsync) explicitly, typically from a debug menu action, or unconditionally from onCreate if that suits the host.
A suspend function, safe to call from any dispatcher including Main -- the underlying bind loop does blocking socket probes across StartRequest.portRange internally, and that work is already moved off the caller's dispatcher, so calling this from lifecycleScope.launch { } on the main thread will not ANR.
StartRequest.bindingMode decides loopback-vs-LAN for this call, and no DevConsoleConfig value provides a default for it: DevConsoleConfig.browserConfig.binding governs only the starts this method is not making -- the in-app inspector's More-screen Start button -- so a host that wants LAN from both surfaces sets both. See the KDoc on io.devconsole.api.BindingMode and io.devconsole.api.BrowserBinding. The default StartRequest() binds loopback, which is the safe choice -- see docs/THREAT_MODEL.md at the repository root before ever passing bindingMode = BindingMode.LAN.
Return
a StartResult -- StartResult.Started carries the bound io.devconsole.api.BrowserEndpoint and the session io.devconsole.api.AccessInfo (the connect URL/code); every other variant is a reason it didn't start (see StartResult's KDoc for what each one means and whether it's retryable).
Parameters
binding mode and port range for this start attempt. Defaults to loopback on 8080..8099.