Starts the CloudX SDK's warm-ups at process start, via androidx.startup.

This does not initialize the SDK. CloudX.initialize is still required, and nothing here changes when or how it runs. What this reclaims is the window between the process starting and the publisher calling initialize() — often hundreds of milliseconds, sometimes seconds on a cold start — by resolving the slow device signals (user agent, WebView version, advertising ID, App Set ID, carrier, app info) and opening the TLS connection to the CloudX host during it, so the first config and bid requests find them already warm. The install ID rides along, but only as a Block Store reconcile of an ID a previous launch already persisted; on a true first launch it is still minted on demand by the first read.

The host connection is warmed in release builds only. A ContentProvider runs long before the publisher can set the debug seams: CXDebugConfig.initServer still points at production, so the warm-up would address the wrong host, and building the HTTP client this early would capture a still-empty CXDebugConfig.debugHttpInterceptors into the process-cached client. A debug build warms the host from initialize() instead, once both are set.

Every warm-up is best-effort and asynchronous. If one fails or has not finished by the time initialize() runs, the SDK behaves exactly as it does today: it falls back to a device-derived user agent, a persisted or absent ID, and its own connection setup. Nothing here can fail the host app's startup.

The initializer is registered automatically through manifest merging. A publisher who would rather the SDK do nothing before initialize() can remove it in the app manifest:

<provider
    xmlns:tools="http://schemas.android.com/tools"
    android:name="androidx.startup.InitializationProvider"
    android:authorities="${applicationId}.androidx-startup"
    android:exported="false"
    tools:node="merge">
    <meta-data
        android:name="io.cloudx.sdk.CloudXStartupInitializer"
        tools:node="remove" />
</provider>

The xmlns:tools declaration on the provider makes the block paste in as-is. A manifest that already declares the prefix on its <manifest> element can drop it.

With the entry removed the SDK still performs the same warm-ups, just later — initialize() fires them itself.

This class is public only because the manifest names it. It is not an API to call.