IssueTracker

We’ve shared this with our product and engineering teams and will continue to provide updates as more information becomes available.

Ignore the sloppiness that may not be desired in here - this is an edited-down version of my thoughts from elsewhere:

Really hope services are exempt from the notification permissions. If they pursue this route, they should just allow the high priority notifications automatically, but require permission for posting normal/unimportant level notifications. Just an idea, I know that some dirty developers will abuse this and always use the high important level ones, though. Alternatively, create a new Importance level just for services, and let those go through no matter what. Users can use the existing notification channel tools to mute them as desired.

If services require permission grants, now you have to go out of your way to provide yet another explainer for the user on why you need to do something. We all know that casual users don't like to read such things (the browser toolbars included with installers have proven this), and will just hit any button (often guided via a dark pattern) that gets the pop-up out of the way. For some users, it will go over their head that denying the notification permission will also break critical functionality for apps that require foreground services.

So after this particular permission denial, the developer will get blamed for when processing doesn't happen when it's supposed to. My app *has to* use foreground services, as the user expects certain work to happen within very specific and quick timing when the app is in the background. It's a utility app, so the user barely opens it. If the app is in the background, and has a failure because of this, I wouldn't be able to create a notification stating that something is wrong **because** they've denied the permission. Then they'd think that it's my fault. It's also ridiculous, because they've removed a lot of those background receivers years ago and forced us to use services. They recommend work manager for some stuff, but it's worthless to me and my users when it just provides a promise to do your work "when it can" and still doesn't solve the restricted background receiver problem.

When the user updates from 12 to 13, they'd have no way of knowing that my app is broken unless they go into my app and read whatever new onboarding is required. In my case, the app is actually supposed to function in the background almost exclusively, alike Tasker. Are they then supposed to go through every app and see what is broken? Same goes for when you change your target API - your app is suddenly broken on 13 devices, and again you obviously have no way of telling the user of such. Doesn't help that Google continues to bury the Updates section in the Play Store - I used to like accessing the changelogs daily to see what my installed apps have added, but I don't go there anymore because the navigation is just too much work. They won't see the update notes, if you try to explain it there. I'm concerned about the Alarms permission right now, for similar reasons.

Increasingly exhausting development requirements aside: as a user, I'm also getting a little fatigued by all of the popups and setup required these days, especially when some permissions require you to go outside of the app and toggle stuff in App Info and other weird sections of the OS.

@3 Indeed if there is some error, it wouldn't make sense to have a sticky notification for it.
But I don't think offering a channel for foreground services would solve it.
I just prefer to avoid this new permission completely.
I've heard that on IOS, because this is so common, people often see it for all the apps they install, which is, as you wrote, causing "fatigue" of granting. People seeing it so many times means that most will just grant it and waste the time about it, including of developers for such a basic functionality.
Android isn't IOS. Notifications has existed on it much more time than on IOS, and it's still having a better management of them for users (at least by most videos I've watched that compare them).

I do understand that many apps abuse the notifications to show plenty of them, but this is why we have a review system, and this is why we have control of how to block notifications channels. Google even added something to manage the notifications based on usage of them, as I remember.

I think I can summarize the reasons as such:

1. It's a very basic thing on Android, almost as much as Internet permission.

2. I would hate seeing it for almost every app I install. Apps would probably always request it right away after the first launch, as there is no real context to it, as opposed to other permissions.

3. According to what I've heard, on IOS it's exactly like this, meaning almost all apps request it right away. Android isn't IOS. It got notifications way before IOS, and it still, even today, has a better management and UI for handling notifications.

4. This permission is all-or-nothing. Users who see this permission request would not know what will happen when denying it, so some important notifications would be missed.

5. What would happen for foreground-notifications (the sticky ones of foreground services, showing "loading", "processing", "downloading", "updating...", etc...) ? If they will also be hidden, users won't see that the app is doing something. And when they have errors, users won't see them either. If they would still be shown, that's just something apps could use instead of this permission.

6. If you think about apps that use notifications too much, that's why we have reviews, that's why we can contact developers, that's why we have plenty of features to control of notifications, including of course long pressing it to see which app shows it. Android 10 even got "Adaptive Notifications", which prioritizes them for you based on various things. Google also blocks apps that use the notifications for spamming ads a few years ago. I remember there was a company called "AirPush" that abused it for a lot of ads showing on notifications.

I've just tested how foreground services work on the first preview of Android API 32 ("Tiramisu") , and it shows how useless this new permission is:

When you have the permission to show foreground services, notifications are shown. It doesn't even matter if you use a foreground service or not... In fact, you can avoid having any service at all on the manifest...

Attached here a sample of such a project, to show how useless this new permission is.

While I do think there are alternatives to this behavior, I think they would all be just as bad.
Please Google, remove this new permission. Users have enough permissions to grant already. This one is too basic to be requested...

Correction: Android API 33. I'm still not used to even seeing API 32 and API 33 just came...

Seems that I was quite to reach the conclusion. This permission doesn't do anything for now.
Even without any permission at all, I can show notifications as usual, despite targeting the new API.

Sorry for my mistake.
Still, I think that no matter what Google will do in this matter, it will be a bad solution as it would compromise either the new permission, or foreground-services.

Testing on emulator of Android 13 Developer Preview 2 , the behavior has changed:

If you have the foreground service permission, whether you use the foreground notification or not, it will be blocked.

This means that users won't have any clue of foreground services being active as long as the notification permission isn't granted.
If you really wish to see which apps are active, when you expand the notifications you get "Active apps"...

Such a terrible UX...

Adding this useless permission will only cause more people to press "Next" more often.

See attached to understand.

This monolithic runtime permission is unnecessary and will end up being just noise (like on iOS). Most users will either blindly accept or deny it. In the first case, the new permission does nothing to protect user privacy or enhance trust, it's just an annoyance like a gdpr popup. In the second case it may make it harder to deliver good UX and place an unnecessary burden on developers to support users. For people who won't blindly click through the runtime permission, the fine control that notification channels offer (including blocking all notifications) is a superior approach. As a user first and also a developer, I truly hope this will be reconsidered as it would be a downgrade. Thanks!

@12 It's worse:
If the user now denies it (accidentally or not), the app needs to be removed&re-installed to re-enable notifications...

@13 I haven't tested it yet but the doc indicates that the permission prompt won't show up unless you uninstall and reinstall. Notifications should still be able to be turned back on in system settings, right?

@13 I think you are correct, at least according to the docs:
https://developer.android.com/about/versions/13/changes/notification-permission
https://android-developers.googleblog.com/2022/03/second-preview-android-13.html

So the confirmation can't be shown again, which isn't like the runtime permissions.

The docs also have explanation of the context of what to show before the notification permission request, though, and it looks bad.
Now ever app that needs to show notifications for various reason would have to have these extra useless steps. And as new notifications types might be added to an app, it won't be able to work properly because of it, as it won't show them anymore.

I predict more inner notifications because of this, more wasting time of both users and developers on something that was so trivial and fundamental on Android.
This is about as bad as how Xiaomi creates its own useless permissions and break apps by default.

I agree with the reporter. Google is making basic things worse with this unnecessary and ridiculous permission.
Currently, users can disable notifications easily if they want to. Force apps asking for this basic permission every time after installing is bad behavior.
For small apps that rarely show a notification (only show when they really need to, eg when error) this is a disaster.

@16 Indeed. Not all notifications are created equal. Some are for errors, some are for loading/saving/processing, some are supposed to show forever, some are actual messages,...
Only a small portion are considered unwanted by most people, and those can be blocked.

There are already many permissions, so much that there are articles about how annoying it is:
https://www.techradar.com/news/i-already-regret-downloading-the-android-13-beta

The more permissions there are, the more users will just choose "accept" all the way, which will actually make it the opposite of being secure/private.

We have enough permissions already. Notifications permission is going to be added to almost all apps.

In addition to the notification permission, Google also wants to add a new permission of scheduling alarms, that apps must request. The only apps that won't need to request it are clock/alarm/calendar apps:
https://blog.esper.io/android-13-exact-alarm-api-restrictions/
I've requested here to change this (please consider starring) :
https://issuetracker.google.com/issues/233235358
https://issuetracker.google.com/issues/233239412

This is just too many trivial permissions for basic functionality that Android always had.
So many confirmations and annoyances that both users and developers need to deal with.

The more permissions Google adds, the more frustrating it gets to install apps and start using them already.

For both notifications and alarms, users already have the control of being able to disable them.
Please Google, don't add those terrible permissions that require user confirmation!

Thank you for your feedback. The Notification Permission will be added in Android T

probably the most dismissive response i've seen, not unexpected but disappointing all the same

@20
Please look at all the people who are against this change.
Please explain, according to what people here wrote, why do you think it's better to have this permission than not having it?

Why wouldn't users want to see error notifications and other important notifications?
Why wouldn't users want to see what's the purpose of some foreground services?
Why would users want to see this confirmation dialog for almost all apps instead of just going to the settings on their own and disable the exact notification channels they want (or all), making it easier to control exactly what they want and what they don't want?
Why would you add a permission that is so commonly used, that it encourages the "permissions fatigue" that you yourself told it's against (because users will just go "next next next"), when was asked about having many permissions?
https://www.androidpolice.com/2015/06/06/android-m-will-never-ask-users-for-permission-to-use-the-internet-and-thats-probably-okay/
https://youtu.be/f17qe9vZ8RM?t=1510 
It's about as common as Internet permission, so why have it?

@20 Also on reddit, see that people are against this permission :
https://www.reddit.com/r/android_devs/comments/tqnjbq/vote_against_the_new_notification_permission_on/

@20 Two very important notifications that shouldn't be removed, for example:
1. Login error (requires re-login)
2. Error message for apps that you perform something within them and expect it to continue in the background (and without knowing it might fail).

And of course foreground notifications, which should show the user what the app is doing.

On IOS it might make sense, but on Android there are just too many examples of notifications that should be shown.

Why mark as Obsolete ?
It's not old at all.
This is a very new permission.
What's the use of this permission, when denying it? It hides notifications that the user should know of: errors, foreground-services, and of course future ones.

Added an alternative request:
https://issuetracker.google.com/issues/236621924

This is iOS behavior.  I would just buy an apple product if I wanted iOS. Surely this is how most android users feel. Freedom to control my phone's behaviour and appearance are the only reasons to own an android. This was a terrible idea and if the trend continues,  I doubt you will retain any customers willing  to buy high end androids. People will only buy your cheap products because that's what they're becoming, cheap iOS knockoffs.