Troubleshooting

initialize()’s completion resolved false

Not an exception — initialize() never throws. A false completion means the API key couldn’t be resolved: no app.onesygnal.API_KEY <meta-data> entry in AndroidManifest.xml, and no prior setApiKey() call, or the key resolved to a blank string. Fix the manifest entry or call setApiKey() before initialize() — calling it after is a silent no-op, since the key is only read once, at initialize() time.

initialize() resolved true but I don’t think config actually loaded

initialize() can succeed even if the config-fetch network call fails. Only an explicit “project inactive” response from the server marks initialization as failed; a network failure is treated as “nothing new to apply” rather than an error. The SDK falls back to whatever’s cached, or to built-in defaults if there’s no cache either. This isn’t a bug: it lets the SDK still track events and run cached surveys offline.

Surveys never trigger, ready never fires, but initialize() didn’t obviously fail

An unexpected error during initialization’s background work is swallowed silently, and:

• the completion resolves false
• ready never fires
• every subsequent trigger check short-circuits — no survey will ever show, even ones that would otherwise match, until you restart the process and call initialize() again.

A survey should have triggered but nothing rendered, and no event fired

Rendering the survey overlay fails silently — no exception and no survey:dismissed event — if there’s no resumed Activity available to attach it to. This typically means initialize() was called with a Context that isn’t (or wasn’t recently) a resumed Activity — e.g. applicationContext instead of the calling Activity. Pass the Activity itself to initialize(), or ensure it happens after an Activity has resumed.

A survey disappeared immediately after showing, and survey:dismissed fired for a question I didn’t answer

This is the fail-closed path for an unsupported question type. The SDK logs a warning (Survey suppressed: unsupported question type '<type>', including in release builds), tears down the overlay, and emits survey:dismissed with that survey’s ID so an integrator listening for dismissals still hears about it.

Some trigger rules never evaluate

If the SDK’s rules engine fails to load (e.g. due to a corrupted app install), the failure is non-fatal: initialize() still succeeds, but any survey whose trigger rules depend on the rules engine won’t evaluate those rules for the rest of the session.

Calling initialize() a second time

OneSygnal is a singleton. A second call’s completion fires with true immediately, and nothing else runs — the API key, locale, and every other setting from the first call stick. There’s no supported way to re-initialize with different settings without restarting the process.