WAI
Status Update
Comments
lb...@gmail.com <lb...@gmail.com> #3
Attached APK of the example app, in case it gets updated to handle this issue.
sa...@google.com <sa...@google.com>
ad...@google.com <ad...@google.com> #5
We have passed this to the development team and will update this issue with more information as it becomes available.
lb...@gmail.com <lb...@gmail.com> #6
@5 Thank you.
A different, yet better&safer approach that have existed for all Android versions so far, is to auto-grant the permission for apps that target older API versions.
Much better than showing the permission confirmation dialog in times that might not fit the app's behavior.
It would also make it less annoying to have it shown in the beginning.
A different, yet better&safer approach that have existed for all Android versions so far, is to auto-grant the permission for apps that target older API versions.
Much better than showing the permission confirmation dialog in times that might not fit the app's behavior.
It would also make it less annoying to have it shown in the beginning.
lb...@gmail.com <lb...@gmail.com> #7
@5 In addition, even though it's probably very rare, there might be apps that show notifications and don't have an Activity (example is addon apps), which is even more reason not to have this dialog as part of this backward compatibility behavior.
So in this case, it's even more important that backward-compatibility would auto-grant the permission instead of a dialog.
So in this case, it's even more important that backward-compatibility would auto-grant the permission instead of a dialog.
ma...@gmail.com <ma...@gmail.com> #8
Hii
ma...@gmail.com <ma...@gmail.com> #9
Hii guys
te...@gmail.com <te...@gmail.com> #10
Is this why Google Auto isn't working correctly. When driving, I keep losing connections (mobile networks). Upon investigation, Google Auto is trying to get me to respond to a notification that I can never see - I'm driving, additionally, the screen is blocked with Google Auto's mobile screen. Is this a bug?
lb...@gmail.com <lb...@gmail.com> #11
@10 Well, you can test your theory by granting these apps the permission to show notifications, and see if it helps
vi...@google.com <vi...@google.com> #12
Thanks for the feedback. We have looked into the issue you have reported and would like to inform you that this is working as intended.
Description
1. Install apps that target API that's lower than API 33, and can show notifications yet chooses to show them in the background.
A perfect example Example is this one:
2. Notice that some of such apps don't get to show the notification permission dialog right away, and the reason is the poor backward compatibility that's also documented:
"
If your app targets 12L (API level 32) or lower, the system shows the permission dialog the first time your app starts an activity after you create a notification channel, or when your app starts an activity and then creates its first notification channel. This is usually on app startup.
"
- What happened.
When the time comes to show notifications, because the apps didn't get to show the notification permission dialog, it also won't show the notification itself.
The reason for this, is that some apps don't create the notifications channels right away. Only when it's time to use them.
You can also create your own POC app, that will use an Alarm/Worker to just schedule showing a notification. Just make sure the creation of the notification channel is also there.
- What you think the correct behavior should be.
The dialog should be shown whether the app has created notification channels or not.
Currently it breaks many apps because of it.
- Is this a security related issue? Yes/No
Yes, for apps that are related to security and have this implementation too.