christocracy
commented
5 years ago Please don’t post immense logs to the thread without wrapping in <details></details> tag.
https://gist.github.com/ericclemmons/b146fe5da72ca1f706b2ef72a20ac39d
Closed nattyg93 closed 5 years ago
christocracy
commented
5 years ago Please don’t post immense logs to the thread without wrapping in <details></details> tag.
https://gist.github.com/ericclemmons/b146fe5da72ca1f706b2ef72a20ac39d
christocracy
commented
5 years ago There’s nothing I can do for Nokia devices. I purchased a TA-27 for myself, precisely because of dontkillmyapp and it’s consistently the worst.
nattyg93
commented
5 years ago Up until the past few days I had been getting very consistent and good data after removing the "battery saver" package. That is to say, that I don't believe the problem to be related to that as it has been working.
christocracy
commented
5 years ago Same happens for me. Sometimes my TA-27 works, sometimes not. I regularly field-test with 7 others. The only other that regularly has issues is Huawei. Every other of my devices works perfect.
Nothing I can do, it’s Nokia’s fault.
christocracy
commented
5 years ago You definitely do not want to use a Nokia as your primary dev device.
nattyg93
commented
5 years ago Yes, HMD Global's reluctance to fix this issue is problematic. I'll run it on different device to ensure the behaviour does not appear elsewhere. Thanks Chris.
nattyg93
commented
5 years ago This issue does not seem to be exclusive to the Nokia as I am experiencing the same behaviour on a Xiaomi Mi A1 (and a Samsung S9). You can see footage here: https://youtu.be/FL-ABXWq_gI Also, once the app is put into the background location services seem to stop as the pin icon disappears from the notification bar.
christocracy
commented
5 years ago I don't see what that video is trying to say. I suggest you test with the /example app in this repo.
I regularly field-test with an Mi A2 @ 9.0.0 and a Samsung A520 @ 8.0.0
nattyg93
commented
5 years ago If you watch the notification bar you can see the plugin starting then immediately stopping. It does this over and over. When I have debug enabled it makes the starting up noises over and over also. I have run a minimal version and this issue does not seem to present itself.
This bug only seems to appear when I start the plugin by calling BackgroundGeolocation.startSchedule(). When I call BackgroundGeolocation.start() there is no issue.
christocracy
commented
5 years ago This is the first time you’ve mentioned anything about schedule.
nattyg93
commented
5 years ago I've only just discovered that this bug only presents when using startSchedule.
nattyg93
commented
5 years ago Using a minimal app which has a single button which will run the code below, I've narrowed the bug down, and it seems to only occur when I provide the url. If omit it, then it will work.
await bg.BackgroundGeolocation.ready(bg.Config(
desiredAccuracy: bg.Config.DESIRED_ACCURACY_HIGH,
distanceFilter: 1.0,
stopOnTerminate: false,
startOnBoot: true,
foregroundService: true,
enableHeadless: true,
isMoving: true,
disableStopDetection: true,
pausesLocationUpdatesAutomatically: true,
debug: false,
logLevel: bg.Config.LOG_LEVEL_VERBOSE,
notificationTitle: 'yoo',
notificationText: 'yoooooo',
autoSync: true,
autoSyncThreshold: 50,
schedule: ['2019-04-17-09:00 2019-04-30-00:00'],
url: '<ANY_VALID_URL>',
batchSync: true,
maxBatchSize: 50,
reset: true,
));
await bg.BackgroundGeolocation.startSchedule();Are you watching the logs?
christocracy
commented
5 years ago What exactly am I supposed to be looking for. It's not unusual you'll see the foreground-service (and its notification) appear / disappear.
The plugin launches the foreground-service to perform HTTP requests so the OS doesn't suspend the app while in middle of performing HTTP requests.
christocracy
commented
5 years ago I want you to post your tracking to my dev server http://tracker.transistorsoft.com.
String username = 'nattyg93'; // <-- Any arbitrary username (eg: Github username)
Map deviceParams = await bg.Config.deviceParams;
bg.BackgroundGeolocation.ready(bg.Config(
reset: true,
url: 'http://tracker.transistorsoft.com/locations/$username',
params: deviceParams
));I think I've found a bug.
If you have the scheduler enabled and are currently within a scheduled ON period:
Plugin won't track.
Try installing latest from master
dependencies:
flutter_background_geolocation:
git:
url: https://github.com/transistorsoft/flutter_background_geolocation.git@christocracy This seems to have rectified the issue.
christocracy
commented
5 years ago Will be published tomorrow
nattyg93
commented
5 years ago There still seems to be a bug when I run startSchedule() with the schedule set to:
["${formatDate(DateTime.now())} ${formatDate(DateTime.now().add(Duration(days: 7))}]It seems to only happen when location permissions have not been granted yet. The way I have managed to consistently make the bug appear, is by uninstalling the app, installing it again, then running ready() and startConfig(), wait for the permission dialog and counting to 3 slowly, then tapping allow. Then the plugin starts and stops as before.
A simple work around seems to be to use DateTime.now().subtract(Duration(minutes: 1) for the start time in the schedule and that seems to fix the issue.
nattyg93
commented
5 years ago Actually, subtracting 1 minute from the time doesn't seem to fix the issue as I initially had thought. Although, running requestPermssion() manually before startSchedule() seems to fix the issue.
nattyg93
commented
5 years ago Also, when the plugin stops (either due to stopTimout or restarting the device) then it still exhibits the same stopping and starting behaviour.
christocracy
commented
5 years ago Show me a short snippet of logs where the plugin is performing this “stopping and starting behaviour”.
christocracy
commented
5 years ago How is that you're observing this "stopping and starting" behaviour? If it's by observing the foreground-notification, that's supposed to go on / off depending on that state of the plugin.
christocracy
commented
5 years ago I suggest you create a simple "Hello World" app that reproduces this issue then share that app with me.
nattyg93
commented
5 years ago In response to your request for logs, see below. I restart my phone and at around 10:45. You can clearly see that we start getting the 🔴 TrackingService destroyed lines which is where the plugin notification starts flashing on and off. This is while I continue to walk around the office to trigger the moving detection.
I'm looking into a simple "Hello World" example wherein I can consistently reproduce this is same issue.
christocracy
commented
5 years ago I have reproduced this in /example app. I see the problem. Fix coming today.
It has nothing to do with the schedule.
christocracy
commented
5 years ago Fix merged to master.
nattyg93
commented
5 years ago I've done a quick test and it seems to have fixed the issue. I'll do some more comprehensive testing when I'm back in the office.
nattyg93
commented
5 years ago After more testing this seems to have fixed the issues we have been experiencing.
It would be good if we could get a response on #55 please.
nullxx
commented
3 years ago This happends the same on react-native
Your Environment
flutter doctor):Expected Behavior
The plugin should run in the background tracking locations.
Actual Behavior
When I start walking with my phone the notification will start for a split second then stop immediately, then start then stop several times over. Also, the tracking is very janky - it is only recording a handful of positions over the space of several hundred meters. It had been working quite well, but seems to have dropped off in quality over the past few days.
Steps to Reproduce
1. 2. 3. 4.
Context
Debug logs