Repository navigation
[shared_preferences_android] Detaching a background engine unregisters the API used by the main engine #194920
Description
What package does this bug report belong to?
shared_preferences
What target platforms are you seeing this bug on?
Android
Have you already upgraded your packages?
Yes
Steps to reproduce
- Use
shared_preferences(legacySharedPreferencesAPI) in an Android app that runs a second Flutter engine in the same process, for example a WorkManager task or an FCM background handler that starts its ownFlutterEngine. - Let the background engine start, then detach (destroy it) while the main engine is still running.
- Call
SharedPreferences.getInstance()in the main isolate.
Expected results
The main isolate keeps working, because its engine is still attached to the plugin.
Actual results
The call throws ArgumentError: No instance with no name has been registered.
Cause: SharedPreferencesApiInstances in Messages.g.kt is a process-wide map keyed by instance name. LegacySharedPreferencesPlugin.onDetachedFromEngine calls SharedPreferencesApiRegistrar().register(null), which removes the default entry, so detaching any one engine removes the registration the other engine still uses. The error text comes from _throwNoInstanceError in messages.g.dart.
SharedPreferencesPlugin.onDetachedFromEngine does the same for the data_store entry used by SharedPreferencesAsync and SharedPreferencesWithCache.
I will open a PR for the legacy plugin.
Activity
mbcorona commentedon Oct 21, 2026
Hi @zkrige, thanks for the precise writeup and the PR.
Routing to team-android.
fix(shared_preferences_android): keep APIs registered until the last …
stuartmorgan commentedon Oct 29, 2026
@tarrinneal I think there's a fundamental issue with the ffi/jni registration system here in multi-engine case that we never considered. With method channels, each instance of a plugin gets its own channel, because channel registration is messenger- (meaning engine-)specific, but this registration system isn't.
The registration call is probably going to need to take some engine-specific context, handle this internally.
[beta] Expose engineId on native plugin bindings and registrars on An…
[pigeon] Support multi-engine Native Interop registration and instanc…
[shared_preferences] Updates Pigeon to 30.0.1 to support multi-engine…