Investigate background location usage

[lognaturel]

I believe that in Android versions prior to 10, we have verified that it is possible to lock the screen while collecting a geoshape|trace, keep walking, and end up with a complete geoshape|trace. My understanding from reading Google docs is that this is no longer possible in Android 10. We should confirm and update docs as appropriate.

CC @getodk/testers

[mmarciniak90]

I'm not able to give you an unequivocal answer. It seems that the results are different than expected. Maybe I missed some conditions. Please look at my test results.

Test details:

• Released version 1.30.1
• Verified Geotrace and Geoshape widgets
• Automatic location recording
• Recording interval: 10 seconds
• Accuracy requirement: None
• Locked screen when 2 points were set
• ~ 3 minutes with locked screen
• checking test without locked screen recorded 18 points on each device

	Android 7.0	Android 8.1	Pixel 3a before upgrade - Android 10.0
received points	5	4	3
received points	6	4	3
received points	5	4	3
received points	4	3	4
received points	4	4	3
received points	5	4	3

---

EDIT: 1st June Because of changes in our test devices, I checked this case for a new device Samsung M11 with Android 10, and I compared these data with results from Android 11.

	Samsung M11 - Android 10.0	Pixel 3a - Android 11
received points	6	3
received points	4	3
received points	4	3
received points	4	3

[lognaturel]

Well that's interesting. I'm not surprised that the counts are trending down as Android version goes up. Google has been working on the accuracy/battery balance so that's probably what we're seeing. @seadowg, @grzesiek2010 I'm realizing I might have been confused about the meaning of foreground/background. Is an app in the foreground until it goes out of memory even if the screen is locked and/or another app is in active use?

This came up because I keep seeing a notice to update our "background location usage" when we publish new versions of the app to the Play Store. Starting March 29, apps that have background location usage may be removed from the Play Store.

@seadowg, @grzesiek2010 and I have reviewed the background location docs a number of times and concluded we don't do anything that is considered background location access. However, the Play Store notice makes it seem like some kind of automated check thinks we do.

[seadowg]

There is a "definition" here. Looking at that if we are getting location updates while the device is locked (and onPause has been called in FormEntryActivity) it feels like we could be considered to dealing with location in the "background". Here the docs mention stopping location updates at onPause "provided the app doesn't need to collect information even when it's running in the background" which would also nudge me towards believing we're collecting location data in the background.

Going back to the definition of "background" it seems clear to me that the right thing to do™️ to ensure we're not misbehaving is to have the location updates handled by a foreground service (similar to how we do audio recording). On a more general note, it feels like Android wants anything that touches a hardware resource to be in a foreground service. I guess this is so it's clear to the user (and the OS).

[lognaturel]

There is a "definition" here.

Thanks, I could not find that for some reason.

This video does strongly suggest that location updates should be stopped in onPause. The checklist looks incomplete to me. You?

~Now I'm wondering whether we should consider asking for the permission and requesting the right to use background location from the Play Store. I do know of a couple of organizations' workflows that rely on being able to collect traces and shapes while the screen is locked. Will think more on this. Any other opinions?~ ARG, ANDROID. Using a foreground service means the app will retain access when in the background:

Your app retains access when it's placed in the background, such as when the user presses the Home button on their device or turns their device's display off.

-- here

Unfortunately I think we have to do this for the next release. The risk of being removed from the Play Store is too high. Any sense of how big of a lift this might be?

[seadowg]

Unfortunately I think we have to do this for the next release. The risk of being removed from the Play Store is too high. Any sense of how big of a lift this might be?

The nice thing is it looks like a lot of the logic is isolated in the BackgroundLocationManager. I think the complexity will be in how to communicate points back to the AuditEventLogger (and in a way that doesn't double down in our usage of Collect.getInstance().getFormController()). I'd imagine it's a week or two to get it together, QAed etc.

[lognaturel]

@yanokwa just tested this with Android 11 and did NOT get points while the screen was locked. This is another good reason to do this work for the next release. As I understand from here, we would have to declare a ForegroundService of type location.

@yanokwa also identified an unexpected interaction with Google Maps and the GPS Status app. Opening one or the other while using Collect lowers the accuracy radius (smaller is better). Closing those apps returns to a higher/worse accuracy radius.

Perhaps related, why do we ask for both fine and coarse permissions? Could we ask for fine only?

[kkrawczyk123]

I have tried it on Collect v1.30.1 on Android 11 device, these are my results:

widget/maps	1st try	2nd try	3rd try
geotrace/Google Maps	3	4	3
geotrace/Mapbox	1	1	1
geotrace/OSM	3	4	3
geoshape/Google Maps	3	3	4
geoshape/Mapbox	1	1	1
geoshape/OSM	3	3	4

The most interesting results are visible when used Mapbox. I locked the screen always when 2 points were already added and when unlocked I had 1 point less. Even more interesting thing is that when I paused collecting points they were still adding. I was able to save the result and also reproduce it on my device with Android 9.0. It's probably another issue connected to Mapbox only.

[yanokwa]

@kkrawczyk123 Did you test to see if accuracy in geopoint changes if you toggle between Collect and GPS Status (or Google Maps)?

[kkrawczyk123]

@yanokwa I have done a quick check on accuracy changes. I think that just minimizing and opening Collect from the background or through an icon is causing a reduction of accuracy (doesn't matter if points are collected or just geowidget is opened). I have also noticed that when toggling between any other apps like Printer or Collect Tester not only Google Maps app. Is there anything more you want me to check on that one?

[yanokwa]

Sorry about the delay, @kkrawczyk123. I have tried this and couldn't repro the behavior I reported earlier. I think it's likely due to my physical location.

That said, it's very interesting what you've found. I'll ask the person who clued me into this issue originally to see if they can repro what you found.

[yanokwa]

Oh, and @kkrawczyk123 when you say "reduction of accuracy" do you mean it goes from 10 m to 5 m? Or do you mean it goes from 10 m to 15 m?

[kkrawczyk123]

@yanokwa I meant reduction like 10m to 15m.

[lognaturel]

I meant reduction like 10m to 15m.

This seems like it would be expected from an app like Collect Tester that doesn't request location data. When returning to Collect, the last point that was read from sensors is now older and so considered less trusted. This makes the accuracy radius worse.

What about using Google Maps or GPS Status, @kkrawczyk123? What a user reported is that he is in Collect and sees a bad accuracy radius (e.g. 20m), then switches to GPS Status which shows a better accuracy radius (e.g. 5m), and when returning to Collect the better accuracy radius is captured. Is this something you looked for?

[kkrawczyk123]

@lognaturel Toggling between Collect and Google Maps works similar to any other app and after returning I can see worse accuracy but when I use Google Maps ex. look for any locations when I am back to Collect accuracy seems to be slightly better. I have made a gif: https://drive.google.com/file/d/1bA4sr5qoXQ3TrAIv4UADPdzsh6vGxxPc/view?usp=sharing

[lognaturel]

Thanks, @kkrawczyk123, that's really interesting. I wonder whether it might be because that Google Maps action forces a location reading. Similarly, GPS Status may manually set a higher frequency to read from sensors and/or force always reading from GPS. I'm not really sure there's anything to do around this accuracy question, @yanokwa, unless you want to try to find out whether GPS Status does anything interesting. Even if it does, I'm not sure we'd want to replicate it and change the battery usage characteristics.

[seadowg]

@lognaturel @yanokwa @kkrawczyk123 could we move any further discussion around accuracy to a different place please? I'll update the issue description, so it's clear what we're trying to achieve here.

I'm just going to create a new issue.

[lognaturel]

We don't do this often but I think investigation issues can be helpful to track a few (possibly) related questions. Creating action-oriented issues seems like the right thing to do once we decide on what to do.

I think https://github.com/getodk/collect/issues/4675 is it for now and we can close this.