Closed casperkloppenburg closed 4 years ago
christocracy
commented
5 years ago "await bg.BackgroundGeolocation.log" but only an old version of the log
There's no such thing as an "old version of the log". The plugin inserts log entries as records in a SQLite database in real time.
Even if an iOS app crashes, it's not going to prevent tracking from resuming. If an iOS app crashes while the device is moving, it's going to restart after ~200 meters.
christocracy
commented
5 years ago I also have trouble with emailLog. It doesn't send the email.
Have you configured a Mail account on that device? If you haven't, #emailLog will return an error. #emailLog should open the default Mail app on the device.
christocracy
commented
5 years ago I suggest you reboot your problem phone. After updating iOS, you should always reboot the phone.
christocracy
commented
5 years ago Also, make sure #ready is always executed, regardless of anything. Make sure you don't have BackgroundGeolocation.ready placed into a view which only gets navigated to by user performing some UI action.
Whenever the app boots, you must call #ready of tracking won't resume.
casperkloppenburg
commented
5 years ago There's no such thing as an "old version of the log". The plugin inserts log entries as records in a SQLite database in real time.
Even if an iOS app crashes, it's not going to prevent tracking from resuming. If an iOS app crashes while the device is moving, it's going to restart after ~200 meters.
Got it. I'm going to do a couple of tests to see if I can get the logging working. I'm going to delete the app data and retry the tests.
Have you configured a Mail account on that device? If you haven't, #emailLog will return an error.
emailLog should open the default Mail app on the device.
The native email client opens and the log is added to the attachments as an archive file. But after sending the email, it doesn't appear in the inbox. I think the email filter is tripping up.
I suggest you reboot your problem phone. After updating iOS, you should always reboot the phone.
Have you tried to turn it off and on again? :-) Unfortunately, I already did this a couple of times between tests.
Also, make sure #ready is always executed, regardless of anything. Make sure you don't have BackgroundGeolocation.ready placed into a view which only gets navigated to by user performing some UI action.
Whenever the app boots, you must call #ready of tracking won't resume.
FYI, I'm using the example app from your repository "Advanced App". Only changes I made to the source are these settings passed to the ready function: "reset: true, logMaxDays: 30, logLevel: LOG_LEVEL_DEBUG" here. To be clear, without these changes, so straight from the repo, I have to same problem.
christocracy
commented
5 years ago Have you tried to turn it off and on again? :-)
I say this because if you're using a Mock location app, such as Lockito, it can mess up the device's location settings, even after disabled. After using a Mock location app, always reboot your device.
christocracy
commented
5 years ago LOG_LEVEL_DEBUG. Use LOG_LEVEL_VERBOSE
casperkloppenburg
commented
5 years ago I say this because if you're using a Mock location app, such as Lockito, it can mess up the device's location settings, even after disabled. After using a Mock location app, always reboot your device.
Good to know. I'm not running Lockito, but it makes me wonder if some other app is messing things up. Will investigate this further.
LOG_LEVEL_DEBUG. Use LOG_LEVEL_VERBOSE
Will do.
christocracy
commented
5 years ago What's the status of this issue?
casperkloppenburg
commented
5 years ago Going to give you some new info in a couple of days.
casperkloppenburg
commented
5 years ago I did another test. This time I managed to grab the log.
What happened: June 27 I started the example app again with background tracking on (freshly pulled from the repo; Advanced App version 1.0.9). You see some locations being logged around 15:00. At 18:11 I left home (30 km ride). It seems that the plugin woke up successful at that moment, but only a couple of locations are logged at the start of the ride. Looking at the data on your site, is shows an "unknown" activity and a battery of -100%. Today (June 29) I went back to the office and opened the app again at arrival. I didn't touch the app for 2 days. Both the ride home (June 27 ~18:00 to 18:40) and the ride back to the office (June 29 ~14:00 to 14:40) are not logged this time.
Tracker URL: http://tracker.transistorsoft.com/iphoneblack?device=Flutter-iPhone7-2-12-3-1&end=2019-6-29&start=2019-6-27
Log:
casperkloppenburg
commented
5 years ago For comparison, I deployed the exact app (same source) on another iPhone, and that one is working as expected: http://tracker.transistorsoft.com/iphonewhite. I had both iPhone with me on the ride home on June 27, as you can see looking at the data. For completeness, here is the log (I can't paste it here because it is too big): https://gist.github.com/casperkloppenburg/804d6815f8ca0d2ba174bdadc9670ff7
christocracy
commented
5 years ago Reboot bad phone and try again.
casperkloppenburg
commented
5 years ago Thanks for the quick response. But I did that already, see our previous conversation
casperkloppenburg
commented
5 years ago Any suggestions on how to fix this or where to look?
casperkloppenburg
commented
5 years ago Any help would be appreciated.
christocracy
commented
5 years ago I've was on vacation all last week. I recorded a 6-day road trip, including a 2300km round-trip flight + 200km highway drive without missing anything.
christocracy
commented
5 years ago If you're having problems with some particular device, the problem must be on that particular device. It is not a plugin config issue.
Try resetting settings: Settings->General->Reset
casperkloppenburg
commented
5 years ago Thanks for the suggestion. The past few days I did some additional testing. I reset the "Network" and "Location & Privacy" settings as you mentioned and this didn't help unfortunately. Then I did a full factory reset, completely wiping the device as if new (without restoring a backup afterwards). This also didn't solve the issue, which I find very suprising.
Interestingly, a couple of days later, I'm trying to open the example app again, but it closes/crashes immediately on startup. It gives a blank screen for a split second before it closes. Note that the app opened just fine a couple of days ago when I made a test ride: http://tracker.transistorsoft.com/erwintest2?device=Flutter-iPhone7-2-12-3-1&end=2019-7-26&start=2019-7-26
Maybe this is also the reason why the plugin stops working after a day. Could there be something that prevents the app/plugin from running after a while, because of something expiring (signing key or license thing?).
I also tested your plugin with React Native with your example app, and the same problem occurs; the tracking starts perfectly but stops tracking the next day.
casperkloppenburg
commented
5 years ago This is what happens:
I just reinstalled the example app with flutter run --release and now the app starts up just fine again.
I also pulled a crash report from the device which might be useful. Don't know if this has something to do with the plugin, but because the phone is almost completely empty and it says something about RTLocationAwarenessManager, I think this might be related. There are multiple crash reports like this one, and they all look the same. It seems the report is cut in the middle, but this is everything it is showing:
christocracy
commented
5 years ago The plugin has nothing to do with an RTLocationAwarenessManager. Are you booting the app in XCode?
christocracy
commented
5 years ago Could there be something that prevents the app/plugin from running after a while, because of something expiring (signing key or license thing?).
No. The iOS plugin has no licensing, it doesn't consume license keys. It's free. Only Android consumes license keys.
casperkloppenburg
commented
5 years ago New information. I reproduced the app crashing on startup with the other iPhone (the one that works fine). So the problem is not related with the issue at hand. Let's forget it for now.
We did another test today. We drove to Amsterdam and back: http://tracker.transistorsoft.com/erwintest2?device=Flutter-iPhone7-2-12-3-1&end=2019-8-1&start=2019-8-1. As you can see, the tracking stopped again at 11:23:17. We had to wait at a bridge. The plugin detected that we were standing still, which is correct. But then it crashed, apparently.
This is the crash log of 11:23:56:
casperkloppenburg
commented
5 years ago I have a lot of crash logs since then. It seems that the plugin is restarted every time, like you said, but crashes immediately.
christocracy
commented
5 years ago These crashlogs don't reference the plugin at all (TSLocationManager). They're full of references to Flutter.
Upgrade your Flutter SDK. Here's my flutter doctor:
ford:SampleApp chris$ flutter doctor
Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel stable, v1.7.8+hotfix.3, on Mac OS X 10.14.5 18F132, locale en-CA)
[✓] Android toolchain - develop for Android devices (Android SDK version 28.0.3)
[✓] Xcode - develop for iOS and macOS (Xcode 10.3)
[✓] iOS tools - develop for iOS devices
[✓] Android Studio (version 3.4)
[✓] Connected device (3 available)And upgrade to XCode 10.3.
casperkloppenburg
commented
5 years ago [✓] Flutter (Channel stable, v1.7.8+hotfix.4, on Mac OS X 10.14.6 18G84, locale nl-NL)
[✗] Android toolchain - develop for Android devices
✗ Unable to locate Android SDK.
Install Android Studio from: https://developer.android.com/studio/index.html
On first launch it will assist you in installing the Android SDK components.
(or visit https://flutter.dev/setup/#android-setup for detailed instructions).
If the Android SDK has been installed to a custom location, set ANDROID_HOME to that location.
You may also want to add it to your PATH environment variable.
[✓] Xcode - develop for iOS and macOS (Xcode 10.2.1)
[✓] iOS tools - develop for iOS devices
[!] Android Studio (not installed)
[✓] Connected device (1 available)Seems okay. I will upgrade my Xcode but I doubt it will make a difference.
I'm going to test the React Native version of your example app and collect the crash logs. Maybe that will give us some new insights.
Thanks for the support so far.
casperkloppenburg
commented
5 years ago I have some new information to share.
I tested with React Native and this seems to work without a problem. The issue has to do with a bug in Flutter, which occurs when the app tries to update its UI when it is running in the background. It seems to be related to this issue: https://github.com/flutter/flutter/pull/37006
This doesn't mean that the problem is fixed, but we can at least pin it down to a bug in the Flutter framework. It happens on the iPhone 5, 6 and 6 Plus. Everyone that uses this plugin is affected by this bug, provided that they are using Flutter and are trying to support older iPhone devices like 5 and 6, which are still very popular devices. At least the Flutter dev team is aware of the problem, and it is being tracked here: https://github.com/flutter/flutter/issues/37813
I'm going to do some testing if I can find a temporary workaround, and will post my findings here if I found anything useful.
christocracy
commented
5 years ago I recently added a new State.didLaunchInBackground property. Perhaps you could use that that make a decision on your UI rendering?
bg.BackgroundGeolocation.ready(bg.Config(
...
)).then((bg.State state) {
if (state.didLaunchInBackground) {
// Don't do UI stuff.
} else {
// Ok, launched by user. App must be in foreground.
}
});I recently added a new State.didLaunchInBackground property. The app doesn't crash, the plugin does, it seems.
I've created a very simple project that reproduces the problem on my iPhone 6's (2 different models are now having this problem, and another one, a slightly different model version, works OK strangely enough). https://github.com/casperkloppenburg/flutter-geolocation-crash
To reproduce the problem:
The app is as simple as it can be, so I don't know where to look anymore. I've reset the phone to its factory settings. Several threads online are suggesting that this error occurs when the app tries to access the UI while in background. Does your Flutter wrapper do something with a background callback that may cause a rerender of the UI? This pull request is suggesting a workaround fix, but this doesn't work in our situation: https://github.com/flutter/flutter/pull/37006
Crash log (note that thread 3 is crashing):
christocracy
commented
5 years ago The plugin itself does nothing with UI.
The crash contains no reference to TSLocationManager. I haven't seen a crash from the SampleApp in months and I field-test it every day and analyze my results at http://tracker.transistorsoft.com/transistor-flutter. I don't miss any tracking, ever.
This looks like a Flutter issue specific to some iOS version with apps that happen to be launched in the background. flutter_background_geolocation, of course, listens to several iOS APIs which will cause the app to be re-launched in the background.
This link references the same error in your stacktrace.
stale[bot]
commented
4 years ago This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. You may also mark this issue as a "discussion" and I will leave this open.
stale[bot]
commented
4 years ago Closing this issue after a prolonged period of inactivity. Fell free to reopen this issue, if this still affecting you.
Your Environment
flutter doctor): [✓] Flutter (Channel stable, v1.5.4-hotfix.2, on Mac OS X 10.14.3 18D109, locale nl-NL) [✗] Android toolchain - develop for Android devices ✗ Unable to locate Android SDK. Install Android Studio from: https://developer.android.com/studio/index.html On first launch it will assist you in installing the Android SDK components. (or visit https://flutter.dev/setup/#android-setup for detailed instructions). If the Android SDK has been installed to a custom location, set ANDROID_HOME to that location. You may also want to add it to your PATH environment variable.[✓] iOS toolchain - develop for iOS devices (Xcode 10.2.1) [!] Android Studio (not installed) [✓] Connected device (1 available)
Expected Behavior
The plugin should continue to run in the background.
Actual Behavior
I'm using the example app "Advanced App" from the example directory. Locations are logged perfectly fine, but after a day, the app stops logging.
Steps to Reproduce
Context
The first ride works without issues: http://tracker.transistorsoft.com/erwin2?device=Flutter-iPhone7-2-12-3-1&end=2019-6-9&start=2019-6-9%202%3A0 The example app has woken itself up perfectly and the locations can be seen on the tracker website (I had the app open a couple hours before leaving, and the app successfully activated itself when leaving with the car).
But the next day, it seems that the app stops reporting anything after the first location. So it seems to detect some movement, but it doesn't report anything after that: http://tracker.transistorsoft.com/erwin2?device=Flutter-iPhone7-2-12-3-1&end=2019-6-10&start=2019-6-10%202%3A0 You can see that it reported only 1 data point on that day, but I made the same trip as the day before (but in reverse direction).
I didn't open the app in between. So, it seems that the app is working correctly until the first data point the next day. I made some trips after that, but these are also not logged, as if the background process crashed and stays closed. If I open the app manually, it starts logging immediately as if nothing happened (it remembered the Username "erwin2"), but it says "Database is empty" when I press "Upload locations".
I encountered this problem only with this iPhone. I have another iPhone that worked better, but not perfect. For reference, here is the data for that other iPhone: Ride A to B: http://tracker.transistorsoft.com/casper?device=Flutter-iPhone8-1-12-2&end=2019-5-10&start=2019-5-10 Ride B to A: http://tracker.transistorsoft.com/casper?device=Flutter-iPhone8-1-12-2&end=2019-5-14&start=2019-5-14 Difference is that this is a iPhone 6s (MN0X2ZD/A) with no internet but at location A (start of the ride). Another difference is that this iPhone was not used for phone calls etc in between.
Debug logs
Logs
``` Sorry, I used the "await bg.BackgroundGeolocation.log" but only an old version of the log is returned (days ago). Nothing is appended. I also have trouble with emailLog. It doesn't send the email. If you have a reliable way to collect the logs, I'm happy to put some time into getting these for you. ```