Unable to receive location events on multiple flutter engines
Your Environment
- Plugin version: 4.13.3
- Platform: Android
- OS version: Android 13
- Device manufacturer / model: Samsung Galaxy S20 Ultra
- Flutter info (
flutter doctor):
[✓] Flutter (Channel stable, 3.13.5, on macOS 13.3 22E252 darwin-arm64, locale en-NL)
[✓] Android toolchain - develop for Android devices (Android SDK version 33.0.2)
[✓] Xcode - develop for iOS and macOS (Xcode 14.3.1)
[✓] Chrome - develop for the web
[✓] Android Studio (version 2022.1)
[✓] VS Code (version 1.85.0)
[✓] Connected device (2 available)
[✓] Network resources
- Plugin config: -
Expected Behavior
Calling the method bg.BackgroundGeolocation.onLocation(...) should register a callback for location updates. Regardless of the flutter engine in which it is called. Nor should it matter which, if any, other flutter engines are also active.
Actual Behavior
Any flutter engine not created first throws a MissingPluginException when calling the method bg.BackgroundGeolocation.onLocation(...).
Steps to Reproduce
Sample application
Note that the required changes to the platform code and AndroidManifest.xml are missing in this example. It only reflects how the dart API would be used.
import 'package:flutter_background_geolocation/flutter_background_geolocation.dart'
as bg;
@pragma('vm:entry-point')
void carEntrypoint() {
bg.BackgroundGeolocation.onLocation((location) {
// Do stuff with the location update.
});
}
void main() {
bg.BackgroundGeolocation.onLocation((location) {
// Do stuff with the location update.
});
}
Context
Let it be clear that our use case is quite niche. However I'm interested if there's a solution to our problem and I'd be happy to contribute a pull request if we can decide on a common fix.
Our navigation application supports Android Auto. To ensure a good user experience we make use of multiple flutter engines. One for the Flutter app on the phone (when opened) and one for Android Auto (when connected). Ideally we would be able to receive location events on both of these engine instances.
A workaround would be to pass location events from the "first" engine to other engines. Sadly we cannot be sure which of the flutter engines starts first (either the MainActivity or CarAppService). This is dependent on the actions of our end users.
Potential solution
During testing I noticed that the setActivity(...)-method in BackgroundGeolocationModule.java is where the relevant "StreamHandlers"/EventChannels are set. This method is only called once, regardless of how many flutter engines are created, since only one activity is launched.
The onAttachToEngine(...)-method, also in BackgroundGeolocationModule.java, is called for each engine created. Could this be an alternative place where we create the "StreamHandlers"/EventChannels for each flutter engine?
And subsequently dispose of them in the onDetachedFromEngine()-method.
Debug logs
Logs
The following MissingPluginException was thrown while activating platform stream on channel com.transistorsoft/flutter_background_geolocation/events/location:
MissingPluginException(No implementation found for method listen on channel com.transistorsoft/flutter_background_geolocation/events/location)
When the exception was thrown, this was the stack:
#0 MethodChannel._invokeMethod (package:flutter/src/services/platform_channel.dart:308:7)platform_channel.dart:308
<asynchronous suspension>
#1 EventChannel.receiveBroadcastStream.<anonymous closure> (package:flutter/src/services/platform_channel.dart:652:9) platform_channel.dart:652
<asynchronous suspension>
@christocracy any insights on this?
No, I forgot about it. Have you tried forking the plug-in and implementing it yourself?
No worries, thank you for the response!
I haven't forked it yet but I'd be happy to. Mainly I was hoping to validate if my proposed solution has any potential or not.
Would you be interested in the results of my findings (including a potential PR) or rather not?
Go ahead and I'll test it out.
I got around to implementing a solution to the problem we were seeing. Happy to hear any feedback on the implementation or any other findings.
This issue is stale because it has been open for 30 days with no activity.
This issue was closed because it has been inactive for 14 days since being marked as stale.