Skip to content
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

Workaround for Location Auth Status being DENIED_ALWAYS #486

Closed
TheNaqvi opened this issue Nov 29, 2022 · 2 comments
Closed

Workaround for Location Auth Status being DENIED_ALWAYS #486

TheNaqvi opened this issue Nov 29, 2022 · 2 comments

Comments

@TheNaqvi
Copy link

Bug report

CHECKLIST

  • [y ] I have read the issue reporting guidelines

  • [y ] I confirm this is a suspected bug or issue that will affect other users

  • [y ] I have reproduced the issue using the example project or provided the necessary information to reproduce the issue.

  • [ y] I have read the documentation thoroughly and it does not help solve my issue.

  • [y ] I have checked that no similar issues (open or closed) already exist.

Current behavior:

Location Auth status is DENIED_ALWAYS when the option to "ask everytime" is selected on android. This is after the location has been requested once.

I realize this has been documented that there is no way for the plugin to distinguish between android "NOT_REQUESTED" and "DENIED_ALWAYS" statuses. Is there any work around so I can detect the "NOT_REQUESTED" status even after the user has been asked for permission once?

Expected behavior:
There should be a way to decipher between "NOT_REQUESTED" and "DENIED_ALWAYS"

Steps to reproduce:
Using the "cordova-diagnostic-plugin-example" app

  1. Request location authorization (Select any option)
  2. Go to location settings for the app
  3. Set the location access to "Ask every time"
  4. Check debug logs. The status returned is "DENIED_ALWAYS" when it should be "NOT_REQUESTED"

Environment information

  • Cordova CLI version
    • 11.0.0
  • Cordova platform version
    • android 11.0.0
  • Plugins & versions installed in project (including this plugin)
    • cordova-plugin-androidx-adapter 1.1.3 "cordova-plugin-androidx-adapter"
    • cordova-plugin-camera 6.0.0 "Camera"
    • cordova-plugin-device 2.0.3 "Device"
    • cordova-plugin-file 7.0.0 "File"
    • cordova-plugin-geolocation 4.1.0 "Geolocation"
    • cordova-plugin-statusbar 3.0.0 "StatusBar"
    • cordova.plugins.diagnostic 7.1.1 "Diagnostic"


Thanks a lot for this plugin and for the help! :)

@dpa99c
Copy link
Owner

dpa99c commented Nov 29, 2022

As outlined in #422, the issue here is that on Android 11+, granting permission "Only this time"/"Ask everytime" means that permission is granted only for the duration of the current app session: when the app is restarted, permission is revoked.
The Android SDK itself provides no way to differentiate between NOT_REQUESTED and DENIED_ALWAYS - they have the same programmatic state, therefore this plugin uses local persistent storage to flag when a given permission has been requested and granted via the plugin. So if Android indicates NOT_REQUESTED/DENIED_ALWAYS, the plugin uses the persistent flag to determine if permission has been requested and therefore differentiate between the two.

This worked fine up until Android 10, however the "Only this time" option added in Android 11 causes a problem:
There's no way for the plugin to tell if the user pressed "Only this time" or "Allow always" in the permissions dialog because the programmatic outcome in Android is the same: the permission state is GRANTED.
Therefore in both cases, the plugin flags this permission as having been requested.
But when the app is restarted the permission is silently revoked by Android and so when the native Android state indicates NOT_REQUESTED/DENIED_ALWAYS, the plugin determines that since the flag has been set for that permission, the state must be DENIED_ALWAYS.

Therefore is no programmatic solution that the plugin can implement to solve this - it is a deficiency in the Android permission states model.

There is however a workaround, as outlined in this comment.

I think this is worth bringing into the main plugin documentation so I'll add a section to the README.md

@dpa99c dpa99c closed this as completed in 0b5d059 Nov 29, 2022
@TheNaqvi
Copy link
Author

TheNaqvi commented Dec 1, 2022

Thanks a lot! I have used the workaround in my app.

Just a note on the new commit in the readme, there is a small typo in there

On line 3818, the final "case" in the switch should probably be diagnostic.permissionStatus.DENIED_ALWAYS .
Cheers!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants