[abdulraqeeb33]

Stack (base feat/never-crash, merged to main as one unit; split out of #2793):

1. refactor: [SDK-5538] add SdkOperation names for init-gated entry points #2800 SdkOperation names
2. feat: [SDK-5538] remote kill switch with a placeholder OneSignalImpV2 #2801 Kill switch with a placeholder OneSignalImpV2
3. feat: [SDK-5538] deferred managers that stand in before init #2802 Deferred managers
4. fix: [SDK-5538] never crash on invalid init or calls before init #2803 Never-crash init (this PR)
5. test: [SDK-5538] guard stand-ins and the public API against drift #2828 Drift tests for the stand-ins and the public API

Description

One Line Summary

OneSignalImpV2 becomes the never-crash implementation: an invalid init or a call before init logs instead of crashing the app.

Details

Motivation

SDK-5538 (doc): never crash the app, log instead. Today a null appId throws a Kotlin NullPointerException, an empty appId with nothing cached still starts the SDK, and any accessor or login before init throws. Wrappers (.NET, RN, Flutter, Unity) add their own guards for this; the native SDK should own it.

How to read this diff

OneSignalImpV2.kt starts as a copy of OneSignalImp (PR 2), so its diff here is the behavior change. OneSignalImp only takes the nullable signatures and keeps its old crash for nulls; it is what the kill switch falls back to. The base tests still run against OneSignalImp; the new tests are the *V2Tests files.

Scope

Init

• initWithContext(context: Context?, appId: String?) and initWithContextSuspend accept null.
• An empty, null or NUL appId falls back to the cached appId. Cached appIds (config model and legacy prefs) are validated too. With nothing usable, init is skipped and logged (WARN for null, ERROR otherwise). Falling back from an empty or NUL appId logs one WARN.
• A null context, or ensureApplicationServiceStarted throwing: log and return false.
• Init state lives in InitGate. Waiters follow a retry that starts while they wait. A cancelled initWithContextSuspend ends in FAILED, so a later init can still succeed.
• Every init attempt ends: a LinkageError, or init code that returns without finishing, marks the attempt FAILED instead of leaving every sync call blocked.
• A retry after a failed init skips services that already bootstrapped (StartupService), so subscriptions are not duplicated.
• Consent or GMS settings changed while init is finishing reach the config model, and consent granted then wakes the operation queue.

Calls before init (NOT_STARTED or FAILED)

• login, logout and updateUserJwt log and return. Composite login returns NOT_INITIALIZED.
• Accessors return the deferred managers from PR 3. Queued registrations replay before services start and before SUCCESS.
• Every other call logs an ERROR naming the call, once per init attempt (repeats go to DEBUG, so a polling getter can't flood remote logging). The init failure trace is attached once per attempt.
• Calls made before any init attempt are summarized in one ERROR when the attempt ends, success or failure, since remote logging only starts inside init. Queued registrations are not counted.
• A call on an interrupted thread no longer throws InterruptedException.

During init

• Accessors still block and return the real manager.
• A call from the thread running init (for example a listener replayed during init that calls back into OneSignal) returns right away instead of waiting on itself.

Unchanged

• Misconfigured*Manager (missing Gradle module) still throws.

Kill switch on (OneSignalImp)
Identical to main. A Java null context (either init), or a null appId on initWithContext, throws the same NullPointerException with the same message the non-null facade used to, so crash grouping is unchanged.

Public API

• String to String? and Context to Context? on initWithContext and initWithContextSuspend. Same JVM descriptor, binary compatible, apiCheck passes.
• KDocs on init, login and updateUserJwt state that the context, app ID, external ID and token are required, and what happens when one is missing (logged and ignored, or INVALID_ARGUMENT for the composite login).

Testing

Unit testing

• InitGateTests: readiness per state, tryStart, waiting, a waiter following a retry, the init-thread guard, a late failed attempt not clearing a retry, an interrupted thread, an attempt that returns without completing, ERROR once per attempt then DEBUG, and the summary.
• SDKInitV2Tests, SDKInitSuspendV2Tests: null context; empty or null appId with and without a cache; accessors and login before init; captured references forward after init and after a retry; no duplicate operations on retry; replay before SUCCESS; one error per call per attempt with the trace once; a LinkageError during init ends the attempt as FAILED; consent kept; cancelled suspend init can retry; JWT listeners queued; cache fallback logs WARN.
• AppIdHelperV2Tests, OneSignalImpV2Tests, StartupServiceTests.
• The base SDKInitTests, SDKInitSuspendTests, OneSignalImpTests and AppIdHelperTests pass against OneSignalImp. OneSignalImpTests also checks the legacy null-argument crash keeps its old type and message.
• Each fix was reverted to confirm its test fails. core 1369, location 46, in-app-messages 172, notifications 246 pass; spotless, detekt, apiCheck pass.

Manual testing

Not yet tested on a device.

Affected code checklist

• Notifications
  • Display
  • Open
  • Push Processing
  • Confirm Deliveries
• Outcomes
• Sessions
• In-App Messaging
• REST API requests
• Public API changes

Checklist

Overview

• I have filled out all REQUIRED sections above
• PR does one thing
• Any Public API changes are explained in the PR details and conform to existing APIs

Testing

• I have included test coverage for these changes, or explained why they are not needed
• All automated tests pass, or I explained why that is not possible
• I have personally tested this on my device, or explained why that is not possible

Final pass

• Code is as readable as possible.
• I have reviewed this PR myself, ensuring it meets each checklist item

[github-actions]

📊 Diff Coverage Report

Diff Coverage Report (Changed Lines Only)

Gate: aggregate coverage on changed executable lines must be ≥ 80% (JaCoCo line data for lines touched in the diff).

Changed Files Coverage

• StartupService.kt: 6/6 touched executable lines (100.0%) (9 touched lines in diff)
• InitGate.kt: 100/103 touched executable lines (97.1%) (209 touched lines in diff)
• OneSignalImp.kt: 4/4 touched executable lines (100.0%) (12 touched lines in diff)
• OneSignalImpV2.kt: 121/135 touched executable lines (89.6%) (213 touched lines in diff)
• AppIdResolutionV2.kt: 11/11 touched executable lines (100.0%) (37 touched lines in diff)

Overall (aggregate gate)

242/259 touched executable lines covered (93.4% — requires ≥ 80%)

📥 View workflow run