dpa99c/cordova-diagnostic-plugin

Android 13 - getLocationAuthorizationStatus() return WRONG statuses for ACCESS_COARSE_LOCATION in some cases

Closed this issue · 2 comments

expcapitaldev commented

Bug report

CHECKLIST

  • I have reproduced the issue using the example project or provided the necessary information to reproduce the issue.
  • I have checked that no similar issues (open or closed) already exist.

Current behavior:
https://github.com/dpa99c/cordova-diagnostic-plugin#getlocationauthorizationstatuses return WRONG statuses example:

  1. call getlocationauthorizationstatuses and app plugin return NOT_REQUESTED for all permissions ACCESS_BACKGROUND_LOCATION, ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION
  2. call cordova.plugins.diagnostic.requestLocationAuthorization(qwe=>console.log(qwe),qwe=>console.error(qwe),cordova.plugins.diagnostic.locationAuthorizationMode.WHEN_IN_USE,cordova.plugins.diagnostic.locationAccuracyAuthorization.FULL) and choose "approximately" and only "just this time" -> result authorized_when_in_use - ok it is expected
  3. call again getlocationauthorizationstatuses, we will have
  1. open location settings on device and enable ACCESS_FINE_LOCATION
  2. call again getlocationauthorizationstatuses and for ACCESS_FINE_LOCATION we will have DENIED_ALWAYS and it is wrong status

Expected behavior:
step 5: call again getlocationauthorizationstatuses and for ACCESS_FINE_LOCATION expected status is GRANTED/ GRANTED in use

Steps to reproduce:
see Current behavior

Screenshots
do not need

Environment information

  • Cordova CLI version
    • cordova -v 10.0.0 (cordova-lib@10.1.0)
  • Cordova platform version
    • cordova platform ls cordova-android 11.0.0
  • Plugins & versions installed in project (including this plugin)
    • cordova plugin ls cordova.plugins.diagnostic 7.1.0
      Runtime issue
  • Device details
    • PIxel 6
  • OS details
    • Android 13

Android build issue:

  • Node JS version
    • node -v v14.17.4
  • Gradle version
    • ls platforms/android/.gradle 7.4.2
  • Target Android SDK version
    • android:targetSdkVersion in AndroidManifest.xml 32
  • Android SDK details
    • sdkmanager --list | sed -e '/Available Packages/q' 32.0.0

Related code:

see Current behavior

Console output

console output 

// Paste any relevant JS/native console output here


Other information:

dpa99c commented

This behaviour is a quirk of Android rather than a bug with this plugin:

  • In step 2, you authorized "approximate" location permission and "only for this time".
  • In step 4, you manually changed the setting switch for "Use precise location" and you expected that means "precise location" access will now be granted to the app.
  • However this is not the case: the plugin is deriving the status DENIED_ALWAYS for ACCESS_FINE_LOCATION from the native permissions manager which has determined that access to ACCESS_FINE_LOCATION is not granted.
  • The reason for this is because you granted approximate location access "just this time" which means that enabling the switch in Settings for "Use precise location" will have no effect because that doesn't affect "this time", it affects "next time".
  • You can confirm this by adding a further step to your list:
  1. Call requestLocationAuthorization() again with WHEN_IN_USE and FULL

  • This will show the permission dialog again, asking if you want to change location access from approximate to precise. It shows this even though you flipped the switch in Settings in step 4, because the previous permission request was temporary so subsequent changes to the permission in Settings will not affect it.

  • This is a quirk of the "Only this time" behaviour of Android permissions.

  • If you repeat your steps but instead of selecting "Only this time", select "While using the app", you will see that changing the switch in Settings in step 4 does cause the plugin to return ACCESS_FINE_LOCATION as GRANTED because in this case previous permission request was permanent.

I hope this makes sense - the permissions system in Android is a mess and sometimes unintuitive.
However this plugin can't change that behaviour therefore I hope you understand why I'm now closing this issue.

expcapitaldev commented

@dpa99c thanks for the quick and detailed answer, good evening and good luck!