Choosing "allow only when in use" on android 10 above is considered as denied about aaper HOT 7 CLOSED

Hi @mochadwi, I was taking look at it today in order to make the changes I mentioned before, and after a deeper look, I noticed that it seems that it isn't an Android bug and rather it's all working as expected based on Android's definition of how this new permission ACCESS_BACKGROUND_LOCATION is supposed to work.

This is a pretty messy use case in terms of runtime permission requests so I'll try to explain what I got from Google's doc and this Medium article that I found on it.

First of all, this new permission ACCESS_BACKGROUND_LOCATION is not necessary to get a phone's location, but instead, it's only needed when you want to get a phone's location while your app's UI is closed.

That's the most important point summarised, so in other words, if all you need is to get the phone's location when your app's UI is open (a screen of your app is open), then you're fine with just requesting either ACCESS_COARSE_LOCATION or ACCESS_FINE_LOCATION instead, and don't need to worry about asking for ACCESS_BACKGROUND_LOCATION.

The whole point of the new permission ACCESS_BACKGROUND_LOCATION is to allow your app to get the phone's location while your app's UI is closed, which is why if the user selects an option from here other than "Allow all the time", then, to your app that means that the ACCESS_BACKGROUND_LOCATION permission is denied (because you can already get the phone's permission when your app is open due to the ACCESS_COARSE_LOCATION or ACCESS_FINE_LOCATION permissions)

So in other words, the only option valid to grant the ACCESS_BACKGROUND_LOCATION permission is "Allow all the time", because, in order to make the other options work ("Allow only while using the app" and "Ask every time"), you already have other permissions to do so, which are the foreground location permissions which are the ACCESS_COARSE_LOCATION and ACCESS_FINE_LOCATION ones.

This isn't a very intuitive use case for developers, but that's how Google decided to do it 🤷‍♂️ I'd recommend you to take a look at those 2 links I posted here at the top for more detailed info. In general, it seems like Google is trying to make things really difficult for an app to get a phone's location in the background, because users aren't aware of the fact that an app is tracking their location, since to them, the app is closed... and I guess that adding these "blockers" makes sense in terms of protecting the user's sensitive data, such as their location.

A couple more things to be aware of regarding this new ACCESS_BACKGROUND_LOCATION permission:

• If you really need to use it, then you'd need to ask Google Play Store permission to do so (even if you implemented the code properly and it's working fine) you'd still need to wait for the Play Store's approval after you upload your app there, as they point out in their docs:
  
• In devices with OS version 11 or higher, you cannot request for both foreground permissions and the new ACCESS_BACKGROUND_LOCATION one at the same time, or one right after the other because if you try to do so, then the permissions will be denied without showing the System dialog to the users. So in order to request for both foreground and the new background permission, you need to do so at different stages on your app, maybe you request for the foreground in one screen, and then later on you request for the background one as part of another screen or maybe when the user clicks on a button after requesting the foreground ones... Google explains this in their docs:
  

I hope all this helps, I'm sorry there's nothing we could do about it.

Regards,
Cesar

from aaper.

Really appreciate for your in-depth well explanation.

In the meantime I agreed with you, looks like our usecase is enough to request foreground location instead of background.

Really apologize for this false-positive report, I'm closing this issue now!

from aaper.

Hi @mochadwi, I'm afraid I don't understand what you need to do, please can you provide some context?

from aaper.

Hi @mochadwi, I'm afraid I don't understand what you need to do, please can you provide some context?

The BACKGROUND_LOCATION permission in Android 10 above choosing "Allow only this time" or "Allow only once" returned denied. Is it intended? @LikeTheSalad

from aaper.

Hi @mochadwi thanks for your feedback, I think you've encountered a pretty interesting issue here which tbh seems like an Android issue, though we can still work around it in Aaper... I'll let you know what I've found, though first let me show you a couple of things Aaper does in order to understand why is the permission is treated as denied:

Aaper doesn't do anything different from what requesting a runtime permission looks like in general, it basically does the following in order:

• Checks for the permission status, to see if it's granted or not by calling ContextCompat.checkSelfPermission(Context, "Some permission name")
• Then, if the permission is NOT granted, it proceeds to launch the System's request permission dialog, by calling: ActivityCompat.requestPermissions(this, ["Some permission name"], REQUEST_CODE) or just requestPermissions(this, ["Some permission name"], REQUEST_CODE) for Fragments.
• Finally, it waits for a response within the Activity's (or Fragment) method: onRequestPermissionsResult(requestCode: Int, permissions: Array<out String>, grantResults: IntArray) and, this is the part where the issue is currently happening with your case. I'll explain it further below.

To summarise, I just want you to know that the way Aaper works is just by doing the same things anyone is supposed to do when requesting for Android's runtime permissions, this means that if something isn't working properly with Aaper, then most likely it isn't working without Aaper either.

The issue I noticed is that, when you request for the ACCESS_BACKGROUND_LOCATION permission, you are given the following options:

If you:

• Select "Allow all the time", then when you go back to your app, the method onRequestPermissionsResult brings in its grantResults: IntArray parameter that such permission is granted.
• Select any other option, such as "Allow only while using the app", then when you go back to your app, the method onRequestPermissionsResult brings in its grantResults: IntArray parameter that such permission is denied <-- This isn't expected, as Android should put the right permission status on this method's param, but it isn't.

The workaround

Even though the method onRequestPermissionsResult is telling that the permission was denied, it seems like if we call the tool to check the permission status: ContextCompat.checkSelfPermission(Context, "Some permission name") we can get the true status of it. So a workaround to this would be to ignore the parameters gotten in onRequestPermissionsResult and instead always check the permission grant status by calling ContextCompat.checkSelfPermission. I'll add those changes in the next release.

Thanks again for your feedback,
Cesar

from aaper.

thanks for your answer, @LikeTheSalad

I see, so this is the android behaviour/bugs by default, that's new to us, also thanks for the changes to have a workaround for this would love to wait for the next release!

from aaper.

No worries, thanks to your feedback I also could understand better how this new permission works, and I appreciate that. Cheers! 👍

from aaper.