geofence is sometimes not created properly; tracking stops completely

[shankari]

Now that I have a recent model phone, recording errors in tracking so we can investigate them later.

[shankari]

trip to CVS, Ava's and back on 29th Jan from around 5:30 to 6:20 not tracked

Geofence was not exited

$ grep "TripDiaryStateMachineService.*handleAction" /tmp/2022-01-30_Trips_to_CVS_and_Avas_and_back_missing_America_Los_Angeles.loggerDB.withdate.log | tail -n 4
25848,1643335257.909,2022-01-27T18:00:57.909000-08:00,"TripDiaryStateMachineService : handleAction(local.state.waiting_for_trip_start, local.transition.exited_geofence) called"
25855,1643335257.925,2022-01-27T18:00:57.925000-08:00,"TripDiaryStateMachineService : handleAction(local.state.waiting_for_trip_start, local.transition.exited_geofence) completed, waiting for async operations to complete"
26248,1643335509.445,2022-01-27T18:05:09.445000-08:00,"TripDiaryStateMachineService : handleAction(local.state.ongoing_trip, local.transition.stopped_moving) called"
26251,1643335509.465,2022-01-27T18:05:09.465000-08:00,"TripDiaryStateMachineService : handleAction(local.state.ongoing_trip, local.transition.stopped_moving) completed, waiting for async operations to complete"

And the last geofence creation was at the right location

26257,1643335509.512,2022-01-27T18:05:09.512000-08:00,"CreateGeofenceAction : creating geofence at location Location[fused [redacted] hAcc=15 et=+18d0h50m45s826ms alt=
-4.099999904632568 vel=0.44552988 bear=64.941536 vAcc=1 sAcc=??? bAcc=??? {Bundle[mParcelledData.dataSize=620]}]"
26258,1643335509.515,2022-01-27T18:05:09.515000-08:00,BuiltinUserCache : Added value for key CURR_GEOFENCE_LOCATION at time 1.643335509514E9
26259,1643335509.5170002,2022-01-27T18:05:09.517000-08:00,"CreateGeofenceAction : creating geofence at location [redacted]"

And the foreground service was not killed for the entire day.

kshankar-35069s:e-mission-data-collection kshankar$ grep "01-29.*PERIODIC" /tmp/2022-01-30_Trips_to_CVS_and_Avas_and_back_missing_America_Los_Angeles.loggerDB.withdate.log | wc -l
      32

$ grep "01-29.*checkForeground" /tmp/2022-01-30_Trips_to_CVS_and_Avas_and_back_missing_America_Los_Angeles.loggerDB.withdate.log | wc -l
      16

$ grep "01-29.*checkForeground.*found 1 active" /tmp/2022-01-30_Trips_to_CVS_and_Avas_and_back_missing_America_Los_Angeles.loggerDB.withdate.log | wc -l
       9

$ grep "01-29.*checkForeground.*found 2 active" /tmp/2022-01-30_Trips_to_CVS_and_Avas_and_back_missing_America_Los_Angeles.loggerDB.withdate.log | wc -l
       7

will take the same trip tomorrow and see if it is reproducible.

[shankari]

Another trip to CVS today, not recorded. Will try trip to a different location tomorrow.

[shankari]

Walk around the block at night, not recorded.

[shankari]

Trip to El Monte Center at around 3pm, not recorded. Resetting the FSM by turning tracking off and on and trying a similar trip again.

[shankari]

Trip there recorded. But not trip back? ending at around 4:05 ("ready for next trip", no trip visible) Showed up as trip from 4:11 to 4:15 although I was home by 4:05 as recorded above. Since I noticed this immediately, generated android bug report.

[ericafenyo]

Bonjour @shankari, I would like to ask if there is any plan of replacing geofence with any other technology for starting a trip. If I am correct, @PatGendre did an experiment with Activity detection.

[shankari]

@ericafenyo I would like to explore activity detection for trip starting, but don't have the time right now. We will need to test it carefully, estimate the additional power drain and ensure that we don't have a lot of false positives.

In the short-term, I plan to work around this issue by recreating the geofence if there have been no trips for a day.

After resetting the FSM, my tracking has been working perfectly.

[PatGendre]

Hi @ericafenyo no sorry I did not experiment activity detection, it would be interesting of course but would take extensive testing as @shankari said.

[ericafenyo]

Ok thanks

[asiripanich]

@shankari I can confirm this behaviour exists on my fork as well.

[shankari]

@asiripanich on android or iOS. I have only seen this on android in my testing

[asiripanich]

I have seen this on both platforms.

[shankari]

@asiripanich have you seen individual trips missed, or tracking stop completely? For really short trips, having the geofence not trigger is expected behavior. For example, if I go to my neighbour's house, it will not detect it. That is the nature of the geofence API on the phone and is not something that can be changed easily.

This is still open as an issue because in my case, the tracking did not resume even for longer trips until I restarted the FSM (please see the comment history). I have changed the title to reflect this. I would be very surprised to encounter this behavior on iOS since we use the visit notifications as a backup for the geofence on iOS, and it is unlikely that both of them will be broken.

But I could be wrong!

Can you confirm what you do see on iOS?