Using Lefebure NTRIP client as a mock location provider, in association with a RTK receiver, I realized that when when starting a geopoint, user can wait for long for a fix, in fact until he activate location on the phone.
In opposition to the usage of a standard location provider , Collect doesn't ask to activate it, but it still need.
Hi @mathieubossaert
Does it ask for the location permission properly? I wonder if it's a problem only with detecting that the location is disabled or both.
Hi @Grzesiek2010 ,
It doesn't ask for anything. Collect launches the map and nothing happens until I activate the location on the phone.
Could you make sure that the location permission (for ODK Collect) is revoked in settings and then try again? Maybe it's already granted and you only enabled/disable the location?
this is the alert I get using the integrated GPS. And I can't go to the map until I activate the location.
When I use the mock location (lefebure NTRIP) I do not get the warning and Collect shows the Geo-widget map
Yes but I'm asking about the permission request. If you have the location permission disabled in settings:
You should see this dialog (or similar depending on the Android version):
Do you see it when the permission is disabled?
Sorry I did not understand.
Yes I do
But I'll be able to check it with the mock provider tomorow.
Here is a video to show you the problem
Starting without GPS permission, collect asks to allow collect to access the location.
But once accepted, nothing happens since I activate the location in the settings :
The screencast seems corrupted. I'll fix it later 
I can't achieve to get a valid mp4 of my screencast on discourse.
The video is here :
I believe 0:49 is the permissions dialog that @Grzesiek2010 was asking about. And then 1:08 confuses me because I don't see a click but that's turning on location at the Android level, right? And you're saying it would be helpful to see whether we can do the same check on whether location is enabled at the Android level when a mock provider is used?
You probably know this but in case anyone is wondering about the accuracy of 0 at the end, you can capture accuracy from a mock location by using the allow-mock-accuracy parameter. More at the bottom of this docs section.
Hi @LN ,
even if I turn the location permission ON at 0:03, and also at 0:49 when Collect asks for it, what happens from 1:00 to 1:08 is Collect waiting for a location that will never come, until I activate it manually at 1:09. (I should have been slower to get it more visible on the screencast !)
Then at 1:14, Collect can center the map to the location provided by the mock location app.
So, using a mock location provider, even if I grant both Android and Collect to access the location, I still need to activate it manually and I don't get any message from Collect when I try to start a Geopoint without location activated (0:59).
Yes 
I chose a form with an early geo question, and this one does not has this parameter set.
I just tried on a fresher Android flavor (9) and I can't reproduce it
I do not have my old phone with me, I'll check its version in the evening.
1 Like
So you confirm you clicked (enabled) the location at that point? The cursor is not moving so it looks like you open the drop-down menu and the location is disabled initially and then it becomes enabled without any action.
yes I confirm. The phone is a Huawei P8 Lite running Android 8.0.0
Ok so the issue seems to be that ODK Collect does not correctly detect if the location is enabled/disabled.
Now the question is if it happens only when that mock location provider is used or if the Android location provider is used too. Could you check the same scenario on the same device without that mock location provider to let us know?
It happens only when the mock location app is set. The second scenario confirms.
This seems to be a bug in older Android versions. I was able to reproduce it on Android 7. Since it's a part of Android SDK I don't think we can easily fix this issue.
1 Like
I think so as I change to Lineage 16 (Android 9) last friday and I don't have the bug anymore.
All our colleagues are running Android 12/13 version so it's ok for me.
1 Like