NullPointerException in SDKCore.recover() permanently blocks SDK initialization when a crash file exists

[DanBoSlice]

When a crash file ([CLY]_crash_*) exists in the storage directory, every subsequent call to Countly.instance().init(config) throws a NullPointerException because SDKCore.recover() is invoked before the networking field is assigned.

The crash file is never cleaned up after the exception (the deletion line comes after the NPE), so the bug repeats on every application restart.

This is a critical bug. Once a single crash is recorded, the SDK becomes permanently non-functional for that storage directory. All events, sessions, and future crashes accumulate on disk indefinitely. The only recovery is manually deleting the crash file from the filesystem.

Root Cause

In SDKCore.init(InternalConfig), the call order is:

// SDKCore.java — init()
recover(config);                              // internally using networking
networking = new DefaultNetworking();         // networking assigned AFTER

recover() iterates stored crash files and calls processCrash(), which eventually calls Storage.push() → networking.check(config). Since networking is still null at this point:

   java.lang.NullPointerException: Cannot invoke "ly.count.sdk.java.internal.Networking.check(ly.count.sdk.java.internal.InternalConfig)" because "this.networking" is null
       at ly.count.sdk.java.internal.SDKCore.onSignal(SDKCore.java:682)
       at ly.count.sdk.java.internal.ModuleRequests.injectParams(ModuleRequests.java:38)
       at ly.count.sdk.java.internal.Storage.pushAsync(Storage.java:218)
       at ly.count.sdk.java.internal.SDKCore.onCrash(SDKCore.java:455)
       at ly.count.sdk.java.internal.CrashImpl.processCrash(CrashImpl.java:93)
       at ly.count.sdk.java.internal.SDKCore.recover(SDKCore.java:493)
       at ly.count.sdk.java.internal.SDKCore.init(SDKCore.java:126)

Steps to Reproduce

1. Initialize the Countly SDK with crash reporting enabled
2. Trigger a crash that gets recorded as a [CLY]_crash_* file in the storage directory
3. Restart the application and call Countly.instance().init(config) again
4. SDK init throws NPE every time — the crash file is never sent or removed

Expected Behavior

recover() should execute after networking is initialized, or processCrash() should handle a null networking field gracefully. The crash file should be cleaned up even if processing fails, to avoid a permanent init-blocking loop.

[arifBurakDemiray]

Hello again @DanBoSlice 🙌

Thank you for reporting this. The root cause was an initialization ordering issue in SDKCore.init(), recover(config) was called before the networking field was initialized. When a leftover crash file existed on disk, the recovery path called networking.check(config) while networking was still null, causing the NPE. Since the NPE occurred before Storage.remove(config, crash), the crash file was never cleaned up, causing the same failure on every subsequent init.

Fix:

• Moved recover(config) to after the networking initialization block in SDKCore.init()
• Added a checkNetworking() helper with a null guard, applied to all networking.check(config) call sites as defense-in-depth (onSignal, processCrash, initFinished)

Also added 14 unit tests covering: single/multiple crash file recovery, session file recovery, simultaneous crash + session recovery, corrupt/empty crash files, feature combinations (RemoteConfig, Location, all features), networking null-safety for all signal types, and a regression test verifying the permanent-block scenario no longer occurs. Additionally reproduced the NPE on unfixed code and confirmed the fix using a standalone reproducer app

The fix is in this PR and will be included in the next release: #266

Thanks again for flagging this, reports like yours help us make the SDK better for everyone! Let us know if you run into anything else. 🙏

[arifBurakDemiray]

Hello @DanBoSlice 🙌

I want to let you know that we have released Java SDK 24.1.5, which encompasses the fix for the issue.
https://github.com/Countly/countly-sdk-java/releases/tag/24.1.5

Have a great day!