NullPointerException in Android Remote Config callback

[svprdga]

Description

We are seeing a crash on Android when using countly_flutter Remote Config. The crash happens after calling remoteConfig.downloadAllKeys(...), when the native Android SDK finishes the remote config request and tries to notify Flutter through the plugin channel.

It looks like CountlyFlutterPlugin.notifyPublicChannelRCDL(...) calls publicChannel.invokeMethod(...) while publicChannel is null.

Package version

  countly_flutter: 26.1.0

Platform

• Flutter app
• Android
• Countly Flutter SDK 26.1.0

Usage

  Countly is initialized with config:

  final CountlyConfig config = CountlyConfig(
    serverUrl,
    appKey,
  )
    ..setRequiresConsent(true)
    ..setConsentEnabled([CountlyConsent.remoteConfig]);

  await Countly.initWithConfig(config);

Then Remote Config is fetched:

  await Countly.instance.remoteConfig.downloadAllKeys((
    RequestResult result,
    String? error,
    bool fullValueUpdate,
    Map<String, RCData> values,
  ) {
    // Handle downloaded values
  });

In our app this fetch is started asynchronously shortly after initialization.

Crash

  java.lang.NullPointerException: Attempt to invoke virtual method 'void io.flutter.plugin.common.MethodChannel.invokeMethod(java.lang.String,
  java.lang.Object)' on a null object reference
      at ly.count.dart.countly_flutter.CountlyFlutterPlugin.notifyPublicChannelRCDL(CountlyFlutterPlugin.java:88)
      at ly.count.dart.countly_flutter.CountlyFlutterPlugin$1.callback(CountlyFlutterPlugin.java:282)
      at ly.count.android.sdk.ModuleRemoteConfig.NotifyDownloadCallbacks(ModuleRemoteConfig.java:414)
      at ly.count.android.sdk.ModuleRemoteConfig.lambda$updateRemoteConfigValues$1$ly-count-android-sdk-ModuleRemoteConfig(ModuleRemoteConfig.java:110)
      at ly.count.android.sdk.ModuleRemoteConfig$$ExternalSyntheticLambda2.callback(D8$$SyntheticClass:0)
      at ly.count.android.sdk.ImmediateRequestMaker.onPostExecute(ImmediateRequestMaker.java:167)
      at ly.count.android.sdk.ImmediateRequestMaker.onPostExecute(ImmediateRequestMaker.java:16)
      at android.os.AsyncTask.finish(AsyncTask.java:771)
      at android.os.AsyncTask.access$900(AsyncTask.java:199)
      at android.os.AsyncTask$InternalHandler.handleMessage(AsyncTask.java:788)
      at android.os.Handler.dispatchMessage(Handler.java:106)
      at android.os.Looper.loopOnce(Looper.java:226)
      at android.os.Looper.loop(Looper.java:313)
      at android.app.ActivityThread.main(ActivityThread.java:8663)
      at java.lang.reflect.Method.invoke(Method.java)
      at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:567)
      at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1135)

Expected behavior

The plugin should not crash if the Flutter MethodChannel is unavailable. It should either skip the callback or guard the call with a null check.

Suspected cause

The public channel appears to be nullable in the Android plugin lifecycle, but notifyPublicChannelRCDL(...) invokes it without checking whether it has been initialized or is still attached.

A defensive check around publicChannel.invokeMethod(...) would likely prevent the crash.

[svprdga]

From what I’ve been able to gather after downloading a fork of the plugin and investigating the issue, it appears to be a NullPointerException caused by the methodChannel variable being null at the indicated point. The only place where that variable is set to null is inside onDetachedFromEngine. This is strange, because there’s no obvious reason why that method should be getting called under normal conditions while the activity is still in the foreground.

In any case, I’ve applied a defensive guard to mitigate the problem for now so I can ship a release:

        if (methodChannel != null) {
            methodChannel.invokeMethod("remoteConfigDownloadCallback", data);
        } else {
            log("methodChannel is null in notifyPublicChannelRCDL", LogLevel.WARNING);
        }

I’ll report back if I discover anything else or if I can gather more information.

[arifBurakDemiray]

Hi @svprdga,

Thanks for the detailed report and for digging into the source, really helpful. We'll investigate on our side.

Your diagnosis looks right. The AsyncTask callback is landing after onDetachedFromEngine has nulled the channel. A few likely triggers for the detach itself:

• Hot reload / hot restart during development
• Multi-engine setups (FlutterEngineGroup, cached engines, add-to-app)
• Engine cache eviction or explicit engine.destroy() calls

If none of those apply in your case, let us know, that would be useful context.

Regardless, we'll add the null guard across all the affected callbacks (RC, feedback, content, etc.), not just RCDL, so the plugin tolerates detach during in-flight work.

Thanks again!

[svprdga]

Hello @arifBurakDemiray ,

None of the cases you mentioned apply to me. I’ve done all my testing without using hot restart (many of the tests were actually done in profile or release mode). The activity also remains in the foreground at all times, and there are no multi-engine setups or anything unusual involved, just a normal Flutter app.

That said, there are a few details worth mentioning about the times I’ve managed to reproduce the issue (which is not always reproducible):

• The app starts while the device has no internet connection.
• At some point, the device regains internet connectivity while a system dialog is being shown (perhaps this triggers an onPause on the activity, though I’m not sure).
• Right at that moment, the crash occurs.

It almost looks like the AsyncTask that tries to fetch the remote config remains pending somehow, and once the device regains internet connectivity, that AsyncTask finishes execution. But by that point, for some reason, the methodChannel is already null.

I should also mention that I don’t have a reliable way to reproduce it intentionally. Sometimes it happens, sometimes it doesn’t. It’s almost as if the methodChannel becomes null only during a very small timing window or something along those lines...

[arifBurakDemiray]

Hi @svprdga,

Thanks for the extra context, that reproduction pattern is very useful.

The fix is already in place on our side. We've applied the same null-guard across all methodChannel.invokeMethod(...) call sites in the Android plugin (RC, feedback, content, rating widget, etc.), not just RCDL. It will ship in the next minor release. So whatever is causing the detach, the plugin will no longer crash.

That said, the root cause is still interesting. A couple of questions that might narrow it down:

• Do you have any connectivity-monitoring plugins installed (connectivity_plus, internet_connection_checker, network_info_plus)? Some of them touch the activity/engine lifecycle on network state changes.
• Is the system dialog you mentioned a captive portal / "Sign in to Wi-Fi" overlay, a permission prompt, or something app-specific?
• If you can enable verbose Countly logging (Countly.setLoggingEnabled(true)) and capture logs around a reproduction, the plugin logs every lifecycle event (onAttachedToEngine / onDetachedFromEngine / onAttachedToActivity / onDetachedFromActivity) at INFO level. The sequence would pinpoint when and why detach fires.

We'll keep this open until the fix ships.
Have a nice day!

[svprdga]

Hello @arifBurakDemiray ,

About the fix: perfect, as I mentioned, I applied a custom patch on my side, but as soon as the next version is available I'll update to it.

Answering your questions:

• To give you a better understanding of the context, this is my app: https://play.google.com/store/apps/details?id=com.svprdga.wifiqrconnect
• As you can see, my app works heavily with connectivity-related features. When the error occurs, what the app is doing is using the Android API to connect the device to a Wi-Fi network. This causes a system dialog to appear asking the user whether they want to connect. You can reproduce it yourself if you download the app.
• Regarding the logs: I checked to see whether any relevant logs from your SDK appeared, but that wasn't the case. I even added more logs myself at key points inside onDetachedFromEngine and other places, but I couldn't get any additional useful information beyond what I already mentioned.

[arifBurakDemiray]

Hi @svprdga,

Thanks for the extra details. The app context and the Wi-Fi dialog reproduction are really helpful, and it lines up with what we expected on our side.

The null-guard fix we've prepared covers all the relevant callbacks in the Android plugin, so the crash you're seeing won't reoccur once you update.

It will ship in the next minor release. We'll keep this issue open until it's out and update you here when it's published.

Thanks again, and have a nice day!