Problem
For fraud-sensitive flows such as attendance, timecard, delivery check-ins, or field-service check-ins, Android mock locations are important metadata. Android can mark a Location as coming from a mock provider, but react-native-get-location currently does not expose that flag to JavaScript.
The current Android mapper returns fields such as provider, latitude, longitude, accuracy, altitude, speed, bearing, and time:
That means an app receives only coordinates and related metadata, with no way to distinguish a location that Android has already marked as mock.
Requested behavior
Expose a boolean field on Android location results, for example:
type Location = {
latitude: number;
longitude: number;
// ...existing fields
mocked?: boolean; // Android only
}
The Android implementation could populate it from the same native Location object before resolving the promise.
Recommended compatibility approach:
- Use
Location.isMock() on Android 12 / API 31+.
- Use
Location.isFromMockProvider() on older Android versions.
- Or use AndroidX
LocationCompat.isMock(location) as the compatibility helper.
References
Security note
This would not prove that a location is physically real. A rooted or instrumented device may still bypass client-side checks. But exposing Android's native mock-location flag would let apps make informed decisions, block obvious mock-provider locations, send risk metadata to the backend, or route suspicious events for review.
Why this belongs in the library
The flag must be read from the same native Location object used for the coordinates. If apps need to call a separate mock-location detector after receiving coordinates, they can introduce time-of-check/time-of-use inconsistencies where the detector and the submitted coordinates do not refer to the same fix.
Problem
For fraud-sensitive flows such as attendance, timecard, delivery check-ins, or field-service check-ins, Android mock locations are important metadata. Android can mark a
Locationas coming from a mock provider, butreact-native-get-locationcurrently does not expose that flag to JavaScript.The current Android mapper returns fields such as
provider,latitude,longitude,accuracy,altitude,speed,bearing, andtime:Locationtype: https://github.com/douglasjunior/react-native-get-location/blob/master/src/specs/NativeRNGetLocation.tsThat means an app receives only coordinates and related metadata, with no way to distinguish a location that Android has already marked as mock.
Requested behavior
Expose a boolean field on Android location results, for example:
The Android implementation could populate it from the same native
Locationobject before resolving the promise.Recommended compatibility approach:
Location.isMock()on Android 12 / API 31+.Location.isFromMockProvider()on older Android versions.LocationCompat.isMock(location)as the compatibility helper.References
Location.isMock()docs: https://developer.android.com/reference/android/location/Location#isMock()Location.isFromMockProvider()docs: https://developer.android.com/reference/android/location/Location#isFromMockProvider()LocationCompat.isMock(location)docs: https://developer.android.com/reference/androidx/core/location/LocationCompat#isMock(android.location.Location)FusedLocationProviderClient.KEY_MOCK_LOCATIONdeprecation note points developers toLocation.isMock()/LocationCompat.isMock(): https://developers.google.com/android/reference/com/google/android/gms/location/FusedLocationProviderClient#KEY_MOCK_LOCATIONSecurity note
This would not prove that a location is physically real. A rooted or instrumented device may still bypass client-side checks. But exposing Android's native mock-location flag would let apps make informed decisions, block obvious mock-provider locations, send risk metadata to the backend, or route suspicious events for review.
Why this belongs in the library
The flag must be read from the same native
Locationobject used for the coordinates. If apps need to call a separate mock-location detector after receiving coordinates, they can introduce time-of-check/time-of-use inconsistencies where the detector and the submitted coordinates do not refer to the same fix.