-
Notifications
You must be signed in to change notification settings - Fork 662
fix(android): respect requested location accuracy on Android 12+ #250
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
12784a8 to
75bc6f5
Compare
|
When do you plan to merge these changes? |
totalpave
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
ios unit test failures are unrelated to this PR.
breautek
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@totalpave user was me -- accidentally reviewed under the wrong chrome tab...
|
hi all!, waiting update |
|
@breautek are we good to merge this? |
|
@breautek Can I help here , because waiting that changes? |
breautek
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My apologies. My initial review I guess wasn't sufficient, I did a another re-review and actually ran a test app against this PR and found a couple of issues which are noted below (or above?)
Once these issues are resolved, then I think we are good to merge.
|
@dpa99c can you check your MR ? |
…esting permissions on Android 12+ Handle bug on API < 32 when requesting COARSE permission results in TIMEOUT error.
75bc6f5 to
73719d9
Compare
|
@breautek I've made the requested changes - can you re-review and confirm you are happy to merge? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Re-tested the changes and appears to work as expected now.
All android tests passes. Confirmed that the failing iOS/Chrome test weren't the cause of this PR (they have been failing with commits on current master)
I think we are good to merge @dpa99c 👍
Thanks
|
thanks a lot |
|
My geolocation plugin working fine before 2 day suddenly my one plus nord and many client compalnt application location not detect. it was previously working fine "cordova-plugin-geolocation": "^4.1.0", |
|
All of a sudden "cordova-plugin-geolocation" stopped working on some models of VIVO, OPPO, and some MI mobile phones from 17 Nov 2022. When can we expect a quick fix? |
|
@js-kulkarni , @mobiliseapplabllp I am also facing the same issue. Since few days suddenly it stopped working on few mobile phone and in few others it is working properly. Tried so damn hard to get it working. Lets stay connected if someone finds a solutions then lets update here. Thank you. |
|
Guys, Any update pls ? Any help for this topic will be appreciated. |
|
I am facing the same issues in VIVO, OPPO, and MI I have enabled |
|
Good news, seems like Android have some update on Play Service which got download on VivoPhone automatically. I did restart my phone and the GPS is working fine now which earlier was not working on Vivo. |
Platforms affected
Android
Motivation and Context
Prior to Android 12, both COARSE and FINE location permissions were treated synonymously - requesting one would grant the other.
Therefore this plugin currently checks/requests both permissions on Android.
However, when an app is built with an SDK version (and running on device with) Android 12 (API 31) or higher, Android differentiates between precise vs approximate accuracy using these permissions (similar to iOS 14+) - see the Android documentation.
So currently when the methods of this plugin are invoked on Android 12+, this results in both both COARSE and FINE location permissions being requested, regardless of the value set for
enableHighAccuracyinPositionOptions, resulting in the user being asked to choose between precise vs approximate location permission:Description
This PR changes the Android implementation to respect the value of
enableHighAccuracypassed inPositionOptionsso ifenableHighAccuracy: falsethen only COARSE location permission is requested, resulting in the user only being asked to grant approximate location permission:If the user grants this permission and
enableHighAccuracy: trueis subsequently requested, the user in prompted to grant an upgrade from approximate to precise location permission:If the app's first permission request is for
enableHighAccuracy: true, then the user will be presented with the choice between approximate and precise location:I believe this PR resolves issues #188 and #235.
One further change this PR makes is to remove the check for location permissions on Android before invoking
clearWatch()since this is unnecessary.Issues with approximate location permission on Android
Note: As @jcesarmobile points out in this comment, there is a bug in the Chromium WebView which is present up until API 32 (empirical testing shows it to manifest in every API from 22 to 31 but not in 32+ where it appears to be fixed).
It happens when COARSE but not FINE location permission is granted and
enableHighAccuracy: falseis requested, and results in a{"code":3,"message":"Timeout"}error whengetCurrentLocation()orwatchPosition()is called, rather than returning the current location.Due to this issue, this PR implements API version-conditional functionality so that even when
enableHighAccuracy: falseis specified, both COARSE and FINE location permissions will still requested on API 31 and below, while on API 32 and above only COARSE permission will be requested.A further complication is specific to devices running API 31: even if the user grants precise (both COARSE and FINE) location permissions, if
enableHighAccuracy: falseis passed in thePositionOptionsobject to the W3C Geolocation API function on the originalnavigator.geolocationby this plugin, then this also results in a{"code":3,"message":"Timeout"}error.To prevent this, this PR modifies the native
getPermissionmethod on Android to return the current API level of the device.The web layer of the plugin
www/android/geolocation.jsthen checks this returned value and if it's equal to 31, ensuresenableHighAccuracy: trueis passed to to the W3C Geolocation API function, even ifenableHighAccuracy: falsewas specified by the app.There is one further edge case: on Android 12+ (API 32+), if
enableHighAccuracy: trueis requested but the user grants only approximate (COARSE but not FINE) location permission, this will result in a{"code":1,"message":"Illegal Access"}error.This is best handled by the app informing the user that precise location permission is required but they only granted approximate location permission.
The test harness app I created for this PR demonstrates this.
Testing
cordova-paramedicwith the same results between current plugin master branch and PR branch:To run the test harness app with this PR branch of the plugin:
To run the test harness app with the
apache/masterbranch of the plugin:Checklist
(platform)if this change only applies to one platform (e.g.(android))