Ever struggled with users mocking locations in your Android apps? Mock location apps have gained popularity amongst app users on the back of Pokemon GO and an increasing number of location tracking apps. A large number of users have discovered the power of mock location apps in order to fake their locations and game the system. Ironically mock location app were created by developers as a tool to test location features. What started off as a solution for app developers has now become a widespread problem for them. We ended up creating a monster!
Our friends at on-demand delivery company Runnr, now Zomato, brought this problem to our attention when contracted delivery riders were faking locations to game the system. So we built a feature to resolve this by getting real-time location timeline.
Also Read: Are your delivery drivers reaching customers on time?
Detecting Mock Locations & Fake GPS Position on Android
On Android 17 (JellyBean MR1) and below mock locations are detected using Settings.Secure. The app can detect that users have enabled ALLOW_MOCK_LOCATION but has no easy way to determine whether locations received are mock or real.
Solution: The general pattern with mock locations is that bearing speed, accuracy, altitude and time interval (between consecutive data points) are hard-coded values. The HyperTrack API server supports location accuracy by detecting these patterns in order to discard such locations .
On Android 18 (JellyBean MR2) and above mock locations are detected using Location.isFromMockProvider() for each location. The app can detect that the location came from a mock provider when the API returns true.
Solution: The HyperTrack SDK filters out mock locations on the device in order to prevent them from reaching the HyperTrack API server.
HyperTrack removes Mock Locations by default. Developers may enable them using HyperTrack.enableMockLocations(boolean) for testing.
Mock location apps insufficient for testing HyperTrack
In essence, mock location apps generate a continuous stream of locations (latlongs). The HyperTrack SDK generates more than that. Location data is accompanied with activity data. Location streams are organized as a collection of activities in the life of the user. Read more about it in our previous blog on the pitfalls of using location streams. This makes mock location apps insufficient for testing the full power of HyperTrack features.
Introducing HyperTrack.startMockTracking()
A user’s tracking session starts with HyperTrack.startTracking() and ends with HyperTrack.stopTracking(). In order to mock user movement, developers would call HyperTrack.startMockTracking(callback) and HyperTrack.stopMockTracking() respectively. These API calls would start a simulation from your current location to a nearby place of interest within a 5-10km radius so the session is long enough to test features. The simulation mocks your device location activity and other sensor data so the app can cover real-world entropy. This powers a simulated experience that is closer to real world data and helps test HyperTrack features across the dashboard widgets in-app tracking and web tracking views.
For detailed info on MockTracking APIs check out our post to mock user movement to test your live location feature.
What Next?
Detecting Mock Locations and removing them was just the start. Here is a short summary of what we plan to do next to make this more useful:
- For devices with Android 18 & above add “Mock Location detected” event for a user to receive Slack alerts for unexpected events.
- For devices with Android 17 & below add “Mock Location enabled” warning to a device's location history on the dashboard and widgets.
Let us know what more you would like to see from HyperTrack with regard to detecting mock locations. Get started by plugging the location SDK into your app. It takes a few minutes to start building your location features with detection and removal of mock locations with no extra lines of code.
