In the real world, our users will typically have 14d of data on their phones - because we store data for 14d before it gets aged out of the database.
But when you are testing, you often have a version of the app that has just been set up, rather than one that has been running for 14d. So it can be hard to get a realistic database on your phone, which could mean we overlook important problems.
To address this, we have implemented a new function to import location history into a phone - and a helpful URL that will generate suitable data for you. This was implemented under SAF-711.
This article explains this function & how to use it, and also highlights a few pitfalls to watch out for.
Import Location Data onto the Mobile App
Here’s how to import historical data onto your mobile app…
If you have not enabled feature Flags yet, enable Feature Flags
To do this, go to the About screen, and tap on the “PathCheck GPS” heading 10 times (if it’s not working, click a few more times, we have seen it take 12 or more clicks on some devices - e.g. in Perfecto Cloud).
Under More / Feature Flags enable “Import from Google”
(the import doesn’t really come from google, the naming is historical - I’d like to fix, but this is what it is for now)
Now on the More screen, press the “Import past locations” button
Scroll down and press “Import from URL”
Enter the URL of some JSON data (see below), for example
https://diarmidmackenzie.pythonanywhere.com/location-data?latitude=51.5&longitude=-0.144
Press the confirmation button on the keyboard (green check on Android, not sure on iOS), then press Add.
The locations will be added to your local location database.
Note that hashes (needed for Exposure Notification Detection) will only be included if the JSON data provided included hashes. The App does not generate these hashes itself.
To check the data has been saved correctly, you can either:
Share data with Safe Places (see: How to Test GPS End to End)
Or: “Download Locally” (another Feature Flag) to share the JSON file via email, Slack or some other channel.
You can then inspect the JSON file manually, or upload it here for some basic analysis:
Location Data Tool
We suggested an example location URL above: https://diarmidmackenzie.pythonanywhere.com/location-data?latitude=51.5&longitude=-0.144
This particular URL will generate data that shows you wandering about randomly in & around Buckingham Palace gardens for the last 24 hours.
You can generate location data for any longitude & latitude that you like, and for up to 8000 data points (but I don’t recommend testing with > 4032 data points, which is 14d of data).
Just add a “points” parameter (e.g. “&points=4032”) to specify the number of data points that you want.
Data points are generated exactly 5 minutes apart.
Important Note: The tool includes a representative number “hashes” in the data, but these are random numbers, rather than properly computed hashes (to save compute resource). They should give a realistic model of hash storage for exposure notification performance testing - but they will not generate accurate exposure notifications [actually there is a further issue: the current App code (15/7) does not load the hashes into teh DB but discards them, we are working on a fix]
Some enhancements I’m considering:
Make timestamps a bit more variable: 5 mins +/- a random amount. This will make the data more realistic.
Allow data to be created up to time X, where X may be in the past. This will avoid overlapping data points in the case where someone installed the app some hours before they added the fake location data
Make the hashes added to the data correct (not random), so that the data can be used to test Exposure Notifications.
More control over the shape of the data that is generated - right now it’s a slow random walk. We could make it more predictable, follow specific paths/shapes etc.
Requests on the above to Diarmid Mackenzie - I will also put the code into GitHub if others want to contribute (it’s a very simply Python Flask server).
Pitfalls
A few things to watch out for, if you are importing large historical location data sets onto a device. Hopefully we can address these in time…
There is no way to delete that data, other than explicitly deleting the app’s data (which will reset everything and require you to repeat onboarding), or a complet uninstall/reinstall of the app.
AFAIK there is no mechanism in the app to stop you overloading the database with far too many points, either from one upload with too many points, or from multiple uploads in sequence. If you put far more than 4000 data points in the app, it might start to behave oddly.
At the moment, Safe Places does not perform well with hundreds of location data points, and it is really really slow with 4,000 data points. This is reported as PLACES-492 - we understand the problem and are working on a fix, but until that fix is rolled out, you might want to keep data sets down to 1-2 days.
As per limitation above, the tool does not compute the correct hashes for the data points. So while it should offer realistic testing of exposure notification performance, none of these points will actually trigger an exposure notification (and so you’ll need a few real points for that purpose).
Getting 14d Data into Safe Places
For the same reasons that we want to test the GPS Mobile App with 14d data, we also want to test Safe Places with 14d data.
Currently, the best technique we have for doing this is to load 14d data into the Mobile App, using the techniques described above, and then share location data with Safe Places.
Clearly we could develop tooling to upload a 14d data set directly to Safe Places without using the Mobile App, but we have not done so yet. We probably will do so at some point, to simplify automation. This is one of a number of improvements we could make to better support isolated testing of Safe Places - see Testability of Safe Places - PathCheck GPS Mobile App interactions for details.