Hi @seadowg
Thanks for your work on this.
From my perspective option 5 would work, although I think that would mean re-deploying all existing forms so that I can allow external GPS providers to be used. Not a problem as I have a relatively small number (<20) of 'live' or 'dormant' forms.
My concern would be (if I had shenanigans going on) how to differentiate between 'real' external GPS and mock-location (I think @JulFrey was making that point in his response) with option 5 - it sounds like this 'opens' mock-location feature, but doesn't flag that a mock-location is being used?
An advantage of a negative value for accuracy (option 3) is that it allows the 'administrator' to spot questionable data (currently I am guessing that any zero-value dataset is flagged manually or by script, which should be pretty simple to adapt), and differentiates that from manual data (genuinely zero-value) or internal GPS data. Still not sure it's the 'best' solution, but it gives the nuance and means that administrators could use an 'if -ve multiply by -1' script once they have assessed the veracity of the data (could that even be introduced as a new feature of Central in the data validation process?)
Another option (um, number 7?) would be to use the audit log (is that always automatically recorded?) so that if Android detects a mock-location provider, it triggers a field/ variable within the audit log for that form, but records all mock or internal GPS locations with their accuracy and leaves manual locations as 0. That would be an 'easy' flag, and not affect the data collected. Administrators concerned about false data could look for that flag in the audit - which should be as simple as the current 'look for zero', but still gives the nuance of differentiating manual locations (assuming maps-placement appearance is in play). The audit log would not work for manual transfer of data (i.e. via Briefcase on a PC with a cable!) but then you'd be likely to have an idea whether that device had external GPS capabilities set up...
Both of these options have zero / low impact on already deployed forms, I think, making either backwards compatible. They do require notification to anyone relying on 0 to catch the naughty enumerators, so are not without 'cost', but it looks like option 5 isn't 'free' either...
However, we need to check it works for those who are concerned about abuse of mock-location providers, so should probably involve them in the decision-making process (to avoid the pendulum swinging away from their comfort zone). Quick shout out to @Lama , @caneeraj, @arcunha and the redoubtable @Xiphware in case they have any further thoughts. Seems like the issues were raised in one way or another, now I look back at the 'cause' of the zero-accuracy setting. Not wishing to be critical of that discussion, it appears to have looked at solving their immediate problem without picking up on the current consequences - so I am mindful of finding something that works for everyone (including you lovely people at ODK!).
Well that's thruppence of my tuppence (or 3 of my 2 cents) worth on this topic! Hope it helps...