Calling Permission.notification.request() is returning wrong value on iOS

[tkeithblack]

🐛 Bug Report

On iOS when I call Permission.notification.request() the very first time, and the user clicks "Allow", the return value of PermissionStatus.permanentlyDenied is returned. This should return granted.

When I call Permission.notification.request() the second time the return status of 'granted' is returned.

See code example below:

Future<bool> requestNotificaitonAccess(
      {@required BuildContext context}) async {
    var status = await Permission.notification.status;

    if (status.isGranted) {
      print('requestNotificaitonAccess isGranted = true.');
      return true;
    }

    if (status.isDenied) // We have not asked yet
    {
      var requestedResponse = await Permission.notification.request();

      // ERROR: WHEN USER SELECTS 'Allow'
      // requestedResponse ==  PermissionStatus.permanentlyDenied

      var secondTryResponbse = await Permission.notification.request();

      // secondTryResponbse ==  PermissionStatus.granted

      ...
      
  }

Version: 8.1.2

Platform:

• [ YES] :iphone: iOS

[tomaschyly]

For me issue was this:

8.0.0: This release contains the following breaking changes:

Starting from this version the permissions on iOS are disabled by default. To enable a permission, specify the correct GCC_PREPROCESSOR_DEFINITIONS in the ios/Podfile file. For an example check out the Podfile of the example application.

I had to update my pod file to write now only permissions that I want with 1, now everything works for me.

[JDDV]

@tkeithblack, it sounds like @tomaschyly solution should fix your problem. Can you tell me if it solved your problem so I can close this issue? Thanks in advance!

[tkeithblack]

Thanks for the suggestion, but I already have the following defined in my podfile

## dart: PermissionGroup.notification
        'PERMISSION_NOTIFICATIONS=1',

I dug a little deeper and noticed that for the Notification requests it prompts the user immediately upon checking the status. However, for Contacts and Microphone it does not.

This is what I'm seeing after a fresh app install.

var status = await Permission.microphone.status;
// The above function returns PermissionStatus.denied. However it does NOT
// prompt the user yet. This is consistent with the documentation.

if (status.isDenied || status.isPermanentlyDenied)
{
      var requestedResponse = await Permission.microphone.request();
      // Upon calling the above request the user is prompted to allow microphone
      // This function does not return until the user makes their choice.
      // When user selects 'OK' PermissionStatus.granted is returned.
      // Again, this is consistent with the expected behavior.
}      

However, I am not seeing the expected behavior when calling exactly the same way for notifications.

var status = await Permission.notification.status;
// The above function immediately prompts the user with the permission request
// and immediately returns before user makes a selection. The return value is 
// PermissionStatus.permanentlyDenied.
// NOTE: Documentation states this should only check the permissions, not prompt user.

if (status.isDenied || status.isPermanentlyDenied)
{
      var requestedResponse = await Permission.notification.request();
      // When this function is called it DOES wait, however, the prompt for the user
      // to approve notifications has already been displayed with the call to
      // await Permission.notification.status

     // After user selects 'Allow' requestedResponse == PermissionStatus.permanentlyDenied

     // When I make a second call to request, this second call returns PermissionStatus.granted
      requestedResponse = await Permission.notification.request();
}      

This was tested with version:
permission_handler: ^8.1.4+1

Thanks, Keith

[JDDV]

Hi @tkeithblack, Thank you for a clear description of your problem. However, I can not reproduce the same behavior as you mention in your reaction.

For me when I execute this line: var status = await Permission.notification.status; I only get the PermissionStatus.denied back, but the user is not prompted with the request for the notification permission.

How I tested it was using your code snippet combined with the standard Flutter Incremental Counter project when you make a new Flutter Application project.

In the _incrementCounter() method I've added your code snippet for the notification permission, and in the pubspec.yaml I added the newest version of the permission_handler.

As mentioned before you need to change the podfile and add some lines to the info.plist as stated in the documentation (which I do believe you already have).

When testing using your code snippet I started of by only executing var status = await Permission.notification.status;, followed by a print(status) which only printed out the status (which was PermissionStatus.denied) in the console, but did not prompt the dialog to accept or deny the permission.

Then I added the other lines of code you provided, this did give me a dialog where I could allow or deny the permission. Also here I added a print(requestedResponse) to see what the status would be. This returned for me PermissionStatus.granted when I clicked on Allow. I removed the second request line you had in your code snippet since that line is duplicate code at that moment.

So this is the code snippet I tested it with:

var status = await Permission.notification.status;
    print(status);
    
    if (status.isDenied || status.isPermanentlyDenied)
    {
      var requestedResponse = await Permission.notification.request();
      print(requestedResponse);

      // Removed the second `request` line in your code snippet that was supposed to be here
    }

For me it's unclear why it behaves differently, so I would suggest a flutter clean followed by a flutter pub get and pod install command. It sounds like it might be a caching issue or something, since I don't get the same behavior as you do.

Let me know if it worked on your project!

[tkeithblack]

Thanks for your reply, I will try and recreate in the counter app and see what the difference might be.

On Thu, Aug 5, 2021 at 2:50 AM Jan-Derk de Vries @.***> wrote:

Hi @tkeithblack https://github.com/tkeithblack, Thank you for a clear description of your problem. However, I can not reproduce the same behavior as you mention in your reaction.

For me when I execute this line: var status = await Permission.notification.status; I only get the PermissionStatus.denied back, but the user is not prompted with the request for the notification permission.

How I tested it was using your code snippet combined with the standard Flutter Incremental Counter project when you make a new Flutter Application project.

In the _incrementCounter() method I've added your code snippet for the notification permission, and in the pubspec.yaml I added the newest version of the permission_handler.

As mentioned before you need to change the podfile and add some lines to the info.plist as stated in the documentation (which I do believe you already have).

When testing using your code snippet I started of by only executing var status = await Permission.notification.status;, followed by a print(status) which only printed out the status (which was PermissionStatus.denied) in the console, but did not prompt the dialog to accept or deny the permission.

Then I added the other lines of code you provided, this did give me a dialog where I could allow or deny the permission. Also here I added a print(requestedResponse) to see what the status would be. This returned for me PermissionStatus.granted when I clicked on Allow. I removed the second request line you had in your code snippet since that line is duplicate code at that moment.

So this is the code snippet I tested it with:

var status = await Permission.notification.status; print(status);

if (status.isDenied || status.isPermanentlyDenied)
{
  var requestedResponse = await Permission.notification.request();
  print(requestedResponse);

  // Removed the second `request` line in your code snippet that was supposed to be here
}

For me it's unclear why it behaves differently, so I would suggest a flutter clean followed by a flutter pub get and pod install command. It sounds like it might be a caching issue or something, since I don't get the same behavior as you do.

Let me know if it worked on your project!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Baseflow/flutter-permission-handler/issues/614#issuecomment-893244516, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD4WS62BKWJF7BAYUA5GUWLT3I7FDANCNFSM477KU6GQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .

[Pherne]

Hello @tkeithblack, did you find a solution to this, yet? I'm asking because I may have a similar issue. My colleagues reported that our app always displays that it doesn't have permission to receive notifications. However in the settings the permission is granted. Unfortunately I can't reproduce this on my simulator and it only seems to happen on physical devices.

[tkeithblack]

The issue I had may have been different from you. As stated above, when calling Permission.notification.request() the very first time, and the user clicks "Allow", the return value of PermissionStatus.permanentlyDenied is returned. This should return granted. (Note this is ONLY the first time before the user has granted permission).

When I make the second call it returns the correct granted status. You might try changing your code so that you call Permission.notification.request() a second time if it initially returns a denied state.

Look over my initial message for further details.

Best of luck.

[lora-explora]

I had the same issue. Thanks @tkeithblack for the tip with the second request call. I got it to work like that.

[TimHoogstrate]

This issue seems to be solved. Feel free to reopen when needed.