flutterfire
flutterfire copied to clipboard
🐛 [firebase_messaging] Add support for Android 13's POST_NOTIFICATIONS permission
Bug report
Describe the bug
The requestPermission
method does not show the permission dialog on Android 13 and thus the permission to send notifications is not granted.
This is due to Android 13 introducing the POST_NOTIFICATIONS
permission.
See https://developer.android.com/about/versions/13/changes/notification-permission.
Sorry for bothering, but is there an update on this issue?
Because Android 13 is already coming in less then 2 months, and you don't want users to force update, and every app has it's release process.... this is an important issue.
@bhayatus and @krispypen I recently had my PR merged in the permission_handler
plugin as version 10.0.0
that solved this exact issue. I know this is not ideal as you might have to depend on another plugin, but as a temporary workaround this might work for you. I unfortunately do not have enough time at the moment to contribute the same changes here.
I hate making spammy comments like that but Android 13 release is just around the corner. The final beta release has been released.
Can we please please get this feature soon? 🙏🙏🙏
Yes, looking into it as we speak 👍
@russellwheatley is there anything I can do to help you make this feature happen?
@MarcinusX - Will be in review soon: https://github.com/firebase/flutterfire/pull/9348
Amazing, thank you! :)
Is #9348 going to be sufficient? I see no changes to getPermissions but maybe I'm missing something - it's really important to be able to tell the difference between "the user has never answered this question yet" and "the user said no". Currently, even with the new <uses-permission android:name="android.permission.POST_NOTIFICATIONS"/>
in the manifest, on a fresh app install on android 13, FirebaseMessaging.instance.getNotificationSettings()
is returning denied
, instead of notDetermined
.
@msackman Just reading the documentation for android 13 permissions. I don't think there is a setting for notDetermined
. Read this section here.
Quote:
If a user installs your app on a device that runs Android 13 or higher, your app's notifications are off by default.
So if it is a fresh install, it will be denied
until the user has granted permission.
@russellwheatley Well this seems problematic. On iOS with flutterfire, the behaviour is: 1) notDetermined
until you request permissions, so you can use this to navigate to a suitable page; 2) authorized
or denied
once the user has made a decision, so if you read either of these values, you know not to request permission again and just honour the user's choice.
With the android13 system, how do we detect that the user has not yet been asked for permission and so we should request it?
It's been authorized
or denied
for every android release prior to android 13 so I can't see how this is now becoming a problem. I don't think there is anyway to detect notDetermined
for android 13 (according to the documentation I posted previously), but if you find a way, I'd be happy to look into it.
@russellwheatley Yes but every Android release until now didn't require the app to figure out when to ask for permission - because it was silently granted - if the API said denied
then you just don't send notifications.
Ok, so in the case of android only, every app is now going to have to store an extra bool persistently recording whether or not it's asked for permission. It's honestly rare, IME, for iOS to offer a better dev experience, but this looks like it's going to be one. Hey ho.