[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 (this PR)
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
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

A remote kill switch that picks the IOneSignal implementation at process start, with OneSignalImpV2 as a placeholder copy of OneSignalImp.

Details

Motivation

Part of SDK-5538. The never-crash init (PR 4) rewrites init and the manager getters for every app. The switch protects installs where init already works from a regression in that rewrite: flipping the flag puts them back on OneSignalImp on the next cold start without a release. It cannot reach installs whose init never succeeds, because they never cache flags; for them the old behavior is the crash, so there is nothing to restore and OneSignalImpV2 is the only fix.

Scope

• NeverCrashKillSwitch reads the feature flags cached by the previous run from ActivityLifecycleInitializer (androidx.startup, before Application.onCreate), once per process. A backend change applies on the next cold start.
• sdk_never_crash_disabled in the cached sdkRemoteFeatureFlags (any casing) selects OneSignalImp; otherwise OneSignalImpV2.
• Present means off: installs whose init never succeeds never fetch flags, so they keep the new behavior. A fresh install, a locked device, an unreadable cache, or first use before evaluation also keep OneSignalImpV2.
• OneSignal creates its implementation through the switch.
• OneSignalImpV2 is a verbatim copy of OneSignalImp (only the class name differs), so behavior is unchanged either way. PR 4's diff on it then reads as the change from the old code.
• localOverride in NeverCrashKillSwitch forces either implementation for local testing.
• The flag still needs to be created on the backend.

Known gaps (follow-ups)

• The switch reads the OneSignal prefs file on the main thread before Application.onCreate.
• The startup provider only runs in the main process, so secondary processes always get OneSignalImpV2.

Testing

Unit testing

NeverCrashKillSwitchTests: the flag selects OneSignalImp in any casing; no flag, a fresh install, an unreadable cache, a locked device and first use before evaluation select OneSignalImpV2. All suites, spotless, detekt and 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

• OneSignal.kt: 1/1 touched executable lines (100.0%) (3 touched lines in diff)
• ActivityLifecycleInitializer.kt: 1/1 touched executable lines (100.0%) (4 touched lines in diff)
• NeverCrashKillSwitch.kt: 29/29 touched executable lines (100.0%) (76 touched lines in diff)
• OneSignalImpV2.kt: 108/399 touched executable lines (27.1%) (919 touched lines in diff)
  • 291 uncovered touched lines in this file

Overall (aggregate gate)

139/430 touched executable lines covered (32.3% — requires ≥ 80%)

Per-file detail (informational; gate is aggregate above):

• OneSignalImpV2.kt: 27.1% (291 uncovered touched lines)

❌ Coverage Check Failed

Aggregate coverage on touched lines is 32.3% (minimum 80%).

📥 View workflow run

[sherwinski]

Throwing out this comment for consideration:

The device can only read this flag after a successful init call, since that is when flags are fetched and cached. The description says that installs whose init never succeeds keep the new behavior but those are the installs producing the "Must call 'initWithContext'" crashes. So the switch can only restore the old code for devices that were already working, and the old code it restores is the crash. Let me know if my understanding here is off or I missed anything.

[abdulraqeeb33]

@sherwinski your read of the mechanics is right, and the description should have been clearer about intent. The switch is not for the crashing installs; for them legacy is the crash and V2 is the only fix. It is for everyone whose init already works: PR 4 changes init and the getters for all apps, and if that has a happy-path bug (deadlock, bad replay, behavior change after init) the flag puts them back on OneSignalImp without a release. Reworded the Motivation to say that.

One more point: most "Must call initWithContext" crashes are per-launch ordering, not installs that never init, so those devices do cache flags on their other launches.