initialize

Prepares the SDK's capture engine, storage, and state/flag registries so network, WebSocket, push, and timeline recording are ready to receive events. This does not open a network port or start the browser dashboard -- that only happens on an explicit startBrowser / startBrowserAsync call.

Calling this more than once is only sometimes a no-op, not unconditionally safe -- the exact outcome is one of InitResult's variants, and callers that ignore the return value can miss a real conflict:

• An equivalent config to the one already active returns InitResult.ExistingRuntime without changing anything.

• A debuggable build has already auto-initialized with a provisional DevConsoleConfig.default before your own code runs (via its own ContentProvider); your first explicit call with a real config replaces that provisional one and returns InitResult.Initialized. This is the one case a second call is expected to change anything.

• Two genuinely different explicit configs -- your own call after another explicit call already installed a different config -- do not merge or replace each other; this returns InitResult.Conflict and the previously active config keeps running.

Synchronous and expected to be called from the main thread (typically Application.onCreate or an activity's onCreate); it does not perform blocking I/O itself. On a protected build variant (release, wired to devconsole-noop) this is a no-op that always returns InitResult.Disabled -- every other DevConsole call becomes a no-op too, safely, rather than throwing.

Parameters