I observed that in Android 12/13, when utilizing the .cancel() method, it fails to cancel the event within the alarm manager. As a result, the pending event persists and will be broadcasted as initially scheduled. Consequently, during broadcasting, if it coincides with another scheduled notification item (with the same id), it gets captured and gives the impression of triggering earlier than intended. However, in reality, this pertains to the old notification which hasn't been effectively cleared from the alarm manager.
How to reproduce:
schedule a notification e.g.
cordova.plugins.notification.local.schedule({
id: 110,
title: 'Foo ',
text: 'Bar',
foreground: true,
priority: 2,
vibrate: true,
trigger: {at: new Date(2023,7,15,11,51,0)}, // somewhere in a future
})
check that the record exists as something with tag=walarm:NOTIFICATION_ID110-2 as RTC_WAKEUP record
try to cancel it via cordova.plugins.notification.local.cancel(110)
dump alarm again and you will see that the record is still there
Therefore, the solution is to depend on the requestCode of the PendingIntent.getBroadcast which is assigned to each scheduled item so the pending intent can be correctly found.
I observed that in Android 12/13, when utilizing the .cancel() method, it fails to cancel the event within the alarm manager. As a result, the pending event persists and will be broadcasted as initially scheduled. Consequently, during broadcasting, if it coincides with another scheduled notification item (with the same id), it gets captured and gives the impression of triggering earlier than intended. However, in reality, this pertains to the old notification which hasn't been effectively cleared from the alarm manager.
How to reproduce:
schedule a notification e.g.
dump alarm via adb:
adb shell dumpsys alarm PACKAGE_NAME > alarm.logcheck that the record exists as something with tag=walarm:NOTIFICATION_ID110-2 as RTC_WAKEUP record
try to cancel it via
cordova.plugins.notification.local.cancel(110)dump alarm again and you will see that the record is still there
Therefore, the solution is to depend on the requestCode of the PendingIntent.getBroadcast which is assigned to each scheduled item so the pending intent can be correctly found.
P.S. related also to https://github.com/katzer/cordova-plugin-local-notifications/issues/1701 (SamsungAlarmManager: !@too many alarms (500) registered from uid)