Dealing gracefully with location services toggle #127
Comments
|
This is legit server behavior. Need to investigate the client. |
|
This is because we got a geofence exit at 14:02, but it was null! and then at 9:30, we got something similar and continued tracking. It looks like we got Here's the relevant code. This is really bizarre. There's literally nothing between the two log statements other than parsing the event. Was the event malformed? Was the app terminated? The app is not supposed to be terminated because it is in a service. I guess it could be that the event was malformed. The one thing that I do know is that it can't be the usercache because we don't access it between those two log lines. Although I guess another option could be that the we did get to the usercache but the logs were lost because they weren't committed. I wish I had system logs from that time, but alas no chance. |
|
That seems to settle it - we need to create a geofence on every sync if the state is Note that we did not even get a geofence exit when we left Mountain View, only when we got to Berkeley. What if this place was in HI? We would never turn on tracking again, unless the phone was rebooted... That would also solve issues around turning location tracking on and off... |
|
This will also fix #128 |
|
Ran into something similar again. This time, I was on my way to Berkeley when I checked to see if v1.9.0 was live, so that I could demo the targeted surveys to David. It was, so I installed the update right then. I remember that this was when I was sitting in the BART train at Millbrae BART, because I wondered whether the concrete cover would affect download speeds. After that, all tracking was stopped until I manually turned it on the next afternoon in San Francisco. The rest of the trip to Berkeley, the trip from Berkeley to home, the trip from home to San Francisco. Here's the related log. Feb 24, 2017 ~ 12:20 AM, uploaded to store Didn't launch updated app for a while. Launched updated app here, trying to initialize FSM. We start reading locations to create a geofence. Changed, but still too low accuracy. Changed, but still too low accuracy. Changed, but still too low accuracy. Changed, but still too low accuracy. Changed, but still too low accuracy. Finally, we give up and don't create the geofence. Then, I re-launched the app. Hm. we detect that setup is complete and we are in waiting_for_trip_start This is because we update the version as soon as we broadcast the initialize. But ok, we send an initialize again. I am not sure where this broadcast is coming from. Ok so now we have a valid point finally and we create a geofence there. The
But we don't. In fact, we don't get any geofence exit for the trip back from The next geofence exit occurs on the next afternoon when I turned on tracking |
|
This is similar to the prior case described in #127 (comment), except that:
During prior testing, if a geofence was created while in motion, on android, we would get a geofence exit immediately. on ios, we would not get a geofence exit, but we could query to see if we were within or outside of the geofence. I wonder if that behavior has changed in newer google play services. Now that I have an idea of what causes it, I can try to reproduce on the test phones, adding additional logging every time... |
|
Ran into a similar issue, reported by Hassan.
|
|
This is what I see from the logs: Transitions seem to work fine until the 6th, and then there is a big gap until the 13th And then a big gap until the 14th and then the 16th. Multiple init calls around the 16th and then a stop followed by a start |
|
It looks like this is because location tracking was turned off. Around the 6th, here's what happened Trip ended, we moved to And then we exited the geofence, but we got an error while handling the exit Looking at the code, it was generated from here According to the documentation
Geofence service is not available now. Typically this is because the user turned off location access in settings > location access. In that case, we should have generated a What happens on further inits? Let's the And on the 16th.... Looks like geofence creation failed because we didn't get |
|
#127 (comment) is not really related to this - it is related to turning location services off. |
This is the hostel177,1501074077.28,2017-07-26 10:01:17.281000-07:53,"CreateGeofenceAction : creating geofence at location Location[fused -23,546635,-46,694265 acc=73 et=+1d12h50m39s505ms]" This is school1156,1501074918.12,2017-07-26 10:15:18.118000-07:53,"CreateGeofenceAction : creating geofence at location Location[fused -23,562364,-46,722099 acc=32 et=+1d13h5m3s2ms]" at the hostel21200,1501126395.71,2017-07-27 00:33:15.708000-07:53,"CreateGeofenceAction : creating geofence at location Location[fused -23,548618,-46,692886 acc=25 et=+2d3h23m2s323ms alt=826.0 vel=0.0 bear=0.0]" still at the hostel21641,1501126688.58,2017-07-27 00:38:08.575000-07:53,"CreateGeofenceAction : creating geofence at location Location[fused -23,548583,-46,692925 acc=16 et=+2d3h27m55s328ms alt=821.0 vel=0.0 bear=0.0]" still at the hostel22346,1501130694.62,2017-07-27 01:44:54.625000-07:53,"CreateGeofenceAction : creating geofence at location Location[fused -23,548573,-46,693115 acc=13 et=+2d4h34m41s317ms alt=855.0 vel=0.0 bear=0.0]" still at the hostel22743,1501131053.88,2017-07-27 01:50:53.882000-07:53,"CreateGeofenceAction : creating geofence at location Location[fused -23,548577,-46,693106 acc=22 et=+2d4h40m40s417ms]" at some weird location. Note that the accuracy is 15123242,1501131474.8,2017-07-27 01:57:54.803000-07:53,"CreateGeofenceAction : creating geofence at location Location[fused -23,544863,-46,690586 acc=151 et=+2d4h47m41s310ms vel=0.0 bear=0.0]" What is the threshold for bad points for geofence creation? |
|
Similar issues were reported by another user, but in her case it turned out that she was turning location tracking on and off manually. But we were not tracking even when the tracking was on (e.g. when she was using Uber). I don't think we listen to network on/off notifications. |
|
Similar issues reported by one other user. The last Location received was at After this, we do not get ANY locations. There is no reason why we should stop here Why aren't we invoked again with a new location? The next log is from the regular sync! One thing to note is that just before this location, we actually did detect the So that might be why we don't get any more locations - we turned location So when we detected the trip end, where did we create the geofence? At the Biblioteca Brasiliana, which is correct. Then while creating the geofence, we got some more points And create the geofence in parallel Then we finish processing this last spurious point. So the The geofence implementation on android seems to be really flaky in Brazil (see |
|
From #127 (comment),
It turned out that she was turning tracking off and on as well. |
|
ok so we were supposed to have handled location tracking turning off in 2da64dd why isn't it working? Apparently, I handled both the
|
|
so apparently, we should get a transition with type -1 Let's check the documentation to see if it has changed. |
|
on connecting a debugger and retrying, got but then nothing. no transitions or anything. |
|
ok so this is really stupid, but it is because we weren't listening to this notification in the |
actually, we don't launch anything. It looks like that way of showing the |
|
although so maybe this is a kind of |
|
Found another issue while debugging this. If the user tries to initialize when location services are turned off, the service stays in the e.g. and |
|
It turns out that this is because we don't deal with failure to create the geofence by generating a notification. The last few logs from the failed geofence creation attempt are: so then we return |
|
ok, so given our use cases, I think that the correct architecture is that we generate a broadcast message for The challenge with doing this through the transition notifier is that if a particular client forgets to configure it, they can run into the same issue with it not working silently. We could fix that by displaying the current english notification as backup if nothing is configured, and potentially localize that when we are localizing the native code. |
|
ok so to return to #127 (comment) we actually need an activity to make this work.
So I can't do this directly from a service - I have to generate a notification, and then when that notification is clicked, and the activity is launched, I have to call these methods from the plugin code, which is where I have access to the activity. |
|
ok! so passing the pending intent as an object and then handling it in a new Next, need to solve the issue of generating a Also, might want to rationalize the code paths because on the turning off during geofencing now, we actually generate two notifications. |
actually, we can't do this because in some of the places we pass in the and in others, it is from a Status object. If we move to new |
|
This may also explain why I have never received any complaints about this for iOS :) |
|
Hi,@shankari, thanks, I downloaded the fixed apk but the install failed. Maybe because I use an Android 5 phone? Nevertheless if I remember what you said there is way to end a trip manually in the dev zone? (actually I don't know what to do with the transition notify field) |
shankari
changed the title
Should work with android 5. The
Click on the pencil button next to the state and select "End Trip" (see video below) |
|
Yes I installed the apk (not the gz). I had a simple message like "application not installed". Thanks for the video ! I was not looking at the good place in the dev zone ui. It seems to have worked. |
Did you install it directly from the phone or using |
|
I installed it directly. I am out of the office now, I won't be able to try apk install until tomorrow, sorry. |
|
@hmharvey @PatGendre I tried installing it on a physical device and there was a problem with how the apk was signed. Sorry! This newly signed version does work on my android 6 test phone. Let me know if you still have issues... fix-location-services-release-correct-certs.apk.gz |
|
hi, i could install the fix but when i start it, i need a QR code, so i cannot use it. i see the error 6 instead of 1000 for absence of location though. |
|
Yes, as I said in #127 (comment), you need a QR code for this version. You can use the |
And when you click on the notification, it should open the app and ask you to enable location services |
|
ok thanks, the app (network) is very slow but it works |
|
great! I should get feedback from @hmharvey and @deepalics0044 too and then I will merge everything and update the |
|
Testing the new apk:- 1) With location on 2) With location off 3) With location on after off I am testing the new apk I will let you know soon. |
|
@deepalics0044 The profile screen doesn't automatically refresh. Try manually refreshing or killing the app and re-launching to see the real state. |
Hm, this was possibly due to the location services toggle. At any rate, it should work now, specially if you refresh... |
So was your report with the old apk or the new one? |
|
It is working fine now. The toggle goes to on state as soon as I turn the location on. Trips are being recorded accordingly. |
|
@deepalics0044 great! I will wait until tomorrow morning my time to give @hmharvey a chance to respond. But given that we have a couple of people validate this already, I am not inclined to wait any further. I will merge this fix, update Thanks all! |
|
Sorry, just now testing it. I seem to be having troubles with the tracking toggle button as well. Initially, I couldn't seem to turn it on, I got an "Error 1000 while creating geofence" even though my location was on. Turning my location off and back on manually seemed to fix it. |
|
@deepalics0044 @hmharvey so just to clarify, the tracking toggle button currently only reflects whether the user turned tracking on/off for the emission app (e.g. whether it is in the There are basically two controls:
So at least right now, this is expected behavior. Basically, the user said, "e-mission, please stop tracking me". Then you turned on location services on the phone, so for all apps. But you haven't yet allowed e-mission to start tracking you. It's only when you turn the tracking back on and say "e-mission, ok to track me again", that the FSM goes back to If this is unclear, please suggest a way to rename the tracking button :) |
|
I am going to merge this now and close this bug. But I would strongly encourage everybody to perform ongoing ad-hoc testing. So, not just while sitting at your desk, but also while you are out and about. If you find anything broken, please file another issue. Thanks! |
Bump up the versions of all plugins related to the fix for e-mission/e-mission-data-collection#127 - e-mission/e-mission-data-collection#169 - e-mission/cordova-unified-logger#28 - e-mission/cordova-server-sync#34
Found this while investigating weird behavior on the server side.
Details. Will upload client log soon.
Why are my trips on the 30th and the 2nd smushed together?
Raw trips are already smushed.
We apparently have no data from the 30th to the 2nd
We really don't.
Not even unfiltered locations
Looking at all data, we see so it looks like the phone was up and we were recording battery information, but we just did not record any data after
STOPPED_MOVINGtransition at shattuck until magically started getting points around the same location again. How did we even start tracking again without an EXITED_GEOFENCE transition?No other transitions in that entire period
The text was updated successfully, but these errors were encountered: