Skip to content

fix(android): prevent crash if callbackInfo is null in BackgroundWorker (fixes #527) #615

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

jonathanduke
Copy link

@jonathanduke jonathanduke commented Jul 9, 2025

Fixes #527

This PR prevents a NullPointerException when FlutterCallbackInformation.lookupCallbackInformation(...) returns null in BackgroundWorker.kt.

Cause

If the stored callback handle (retrieved from SharedPreferences) is invalid or stale, lookupCallbackInformation(...) returns null. The existing code attempts to access callbackInfo.callbackLibraryPath without checking for null, which crashes the app.

Fix

Add a null check for callbackInfo and fail gracefully:

if (callbackInfo == null) {
    Log.e(TAG, "Failed to resolve Dart callback for handle $callbackHandle.")
    completer?.set(Result.failure())
    return@ensureInitializationCompleteAsync
}

This should prevent the app from terminating with an error such as those mentioned in the linked issue:
Attempt to read from field 'java.lang.String io.flutter.view.FlutterCallbackInformation.callbackLibraryPath'

EDIT: fixed compilation error on return thanks to @Tulleb

Copy link

docs-page bot commented Jul 9, 2025

To view this pull requests documentation preview, visit the following URL:

docs.page/fluttercommunity/flutter_workmanager~615

Documentation is deployed and generated using docs.page.

@Tulleb
Copy link

Tulleb commented Jul 17, 2025

I am facing compilation issue with your fix @jonathanduke:

e: file:///[...]/BackgroundWorker.kt:100:17 'return' is prohibited here.
e: file:///[...]/BackgroundWorker.kt:100:24 Return type mismatch: expected 'com.google.common.util.concurrent.ListenableFuture<androidx.work.ListenableWorker.Result>', actual 'androidx.work.ListenableWorker.Result'.

FAILURE: Build failed with an exception.

@jonathanduke
Copy link
Author

I am facing compilation issue with your fix @jonathanduke:

e: file:///[...]/BackgroundWorker.kt:100:17 'return' is prohibited here.
e: file:///[...]/BackgroundWorker.kt:100:24 Return type mismatch: expected 'com.google.common.util.concurrent.ListenableFuture<androidx.work.ListenableWorker.Result>', actual 'androidx.work.ListenableWorker.Result'.

FAILURE: Build failed with an exception.

Thank you, @Tulleb. I was able to update and compile locally.

@Tulleb
Copy link

Tulleb commented Jul 20, 2025

I can confirm my latest build release is not crashing anymore thanks to this fix 👍

But I'm worried it does prevent some background thread from properly running though.

@jonathanduke
Copy link
Author

But I'm worried it does prevent some background thread from properly running though.

Yes, I agree. Fixing the null exception should prevent the whole app from crashing, but the actual cause of the issue with the handle being invalid is not fixed here. From what I understand, the plugin seems to be storing a pointer in the shared preferences that can become invalid if the signature of your app's background entry method changes. But also in recent commits, the authors changed the key in the shared preferences dictionary, so it might also be related to that. I had a hard time replicating the error on-demand to investigate that further.

@jonathanduke
Copy link
Author

@ened, this issue seems to be affecting many users as discussed in issues #527 and #621. Can you review when you get a chance and publish a patched version if possible? As discussed above, it doesn't fix the cause of the issue related to the handle stored in shared preferences; this is just intended to prevent the exception from crashing the whole app. Thanks!

@mihalycsaba
Copy link

I can confirm this has happened to me, had to reinstall the app to be able to launch it.

@jonathanduke
Copy link
Author

I can confirm this has happened to me, had to reinstall the app to be able to launch it.

I attempted to add this workaround to my app to prevent the exception before I patched the plugin code:

  // isNewBuild is a custom value where I'm detecting if the build number increased since the last run
  if (Platform.isAndroid && (kDebugMode || isNewBuild)) {
    final dir = await getApplicationSupportDirectory();
    final prefsFile = File(
      p.join(dir.path, "../shared_prefs", "flutter_workmanager_plugin.xml"),
    );
    if (await prefsFile.exists()) {
      await prefsFile.delete();
    }
  }

  await Workmanager().initialize(/* ... */);

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

java.lang.NullPointerException while app is in backeground around 2 hours than it's getting crashed
3 participants