Can you add possibility to Stream SDK to NOT FORCE me to request permission on app start?

[Miara]

Current Stream SDK forces me on Android > 13 to ask about POST_NOTIFICATION permission after I log in to GetStream. I have business case that I don't want to force users to grant permission at the start of the app. 

I guess it is FEATURE, not BUG, so I report it as a feature to do. 

Where the problem comes from:

There is class: NotificationPermissionManager in this repo: https://github.com/GetStream/stream-android-push. in method start() it requests POST_NOTIFICATION permission from user, and show system dialog.

That method above is called in method registerPushDevice in StreamNotificationManager

and registerPushDevice() is called by build() method inside StreamVideoBuilder. There is no way to avoid it in case when I have NotificationConfig configured with non empty list in parameter pushDeviceGenerators

Note that NotificationConfig has parameter requestPermissionOnAppLaunch but it covers only asking for permission on app start, but not right after building StreamVideo client.

I could make some hacks, so to postpone StreamVideo building after POST_NOTIFICATION is granted, but I want to avoid that.

This issue is business blocker and I cannot integrate your SDK. Besides that, I found many bugs that I already reported in your repo. I look forward to your assistance with resolving these blockers.

Solution proposal

Imo there should be separate flag in NotificationConfig, such as requestNotificationPermissionOnStreamLogin or requestPermissionOnAppLaunch could be renamed for requestNotificationPermission - and cover both cases: App start, and StreamVideo built

Acceptance criteria

I am not forced to ask users about granting POST_NOTIFICATION_PERMISSION at app start. I want to decide when I will prompt users to grant it.

[aleksandar-apostolov]

Hey @Miara
Thanks for the report. I think it is actually a bug in the StreamNotificationManager which should not call the permission notificationPermissionManager.start() at all or do it per configuration.

We will update this along with some of the other bugs you opened. Look for our release next week.

[aleksandar-apostolov]

Hey @Miara
Would you check this PR -> #1186 would this suffice as a solution for you?
I didn't want to change the name of the existing parameter because its a breaking change.

[Miara]

Thank you so much for addressing this issue! Yes, it is fine for me!