feat(local-notifications): Adding permissions for using SCHEDULE_EXACT_ALARM in Android 14 #1840
Conversation
theproducer
requested review from
markemer,
jcesarmobile,
ItsChaceD,
IT-MikeS and
giralte-ionic
There was a problem hiding this comment.
The plugin already handles the exact notifications being optional, the only difference was that on Android 13 is granted by default if the permission is present in the AndroidManifest.xml and on Android 14 is denied by default even if the permission is present, so the two methods for requesting the permission and checking its value are needed, but not the extra exact parameter. If the user adds the permission to the manifest I think that's enough indication that the want to use exact notifications without having to pass an extra parameter.
SCHEDULE_EXACT_ALARM is not a runtime permission, so it shouldn't be added to the alias, having permissions in the alias that are optional will result in errors for users that don't have the permission in the manifest.
Since it's not a runtime permission and the user won't be prompted but will be redirected to the notification settings page, not sure if the naming should be different to not confuse users, something like checkExactNotificationSetting and changeExactNotificationSetting
Don't use android.util.Log class, use our Logger wrapper so it can be disabled globally.
On Android 14 there is a new permission called USE_EXACT_ALARM, I think we should document it as an alternative to SCHEDULE_EXACT_ALARM but making it clear that is not an option for all apps.
https://developer.android.com/reference/android/Manifest.permission#USE_EXACT_ALARM
There was a problem hiding this comment.
The changeExactNotificationSetting() method is opening the general notifications settings page, not the specific app notification settings page, it should open the app page, to do that, the creation of the intent to ACTION_REQUEST_SCHEDULE_EXACT_ALARM should include a param with the app package.
When calling changeExactNotificationSetting() when it's granted and changing it to denied, the app restarts. I don't think the restart can be prevented, but we should document that behavior, and also according to the docs all the notifications that used exact will be deleted (also verified by scheduling a notification and changed the setting and it didn't fire), so we should document that behavior too, and not sure if we should try to re schedule them, or leave that to the developer?
We should probably also provide some listener for the ACTION_SCHEDULE_EXACT_ALARM_PERMISSION_STATE_CHANGED broadcast, but it looks like only fires when changing from disabled to enabled according to the docs, so not sure if it would be very useful as I think it's more important the rejection of the exact than the approval.
...droid/src/main/java/com/capacitorjs/plugins/localnotifications/LocalNotificationsPlugin.java
Outdated
Show resolved
Hide resolved
We could, but there could be scenarios where a developer wouldn't want notifications rescheduled if exact alarms werent available, so it could be argued either way. I'd say for now we just document it. |
# Conflicts: # local-notifications/ios/Plugin/LocalNotificationsPlugin.m # toast/ios/Tests/ToastPluginTests/ToastPluginTests.swift
…nic-team/capacitor-plugins into local-notifications/alarm-permissions
…T_ALARM in Android 14 (ionic-team#1840) Co-authored-by: Mike Summerfeldt <[email protected]> Co-authored-by: jcesarmobile <[email protected]>
As a result of changes in Android 14, this PR makes using exact alarms for scheduling local notifications optional, and provides functions for checking and requesting permissions for using exact alarms.