A Flutter plugin for displaying local notifications on Android, iOS, macOS and Linux
periodicallyShow()
method would fail to have the next subsequent ones scheduled. This issue started occuring in 14.0 where support for inexact notifications was added using the ScheduleMode
enum that was added and resulted in the deprecation of androidAllowWhileIdle
. A mechanism was added to help "migrate" old notifications that had androidAllowWhileIdle
specified but didn't account for how there are recurring notifications that were scheduled using older versions of the plugin prior to androidAllowWhile
being added. This hotfix has been taken from the 16.0.0-dev.2 prereleaseperiodicallyShow()
method would fail to have the next subsequent ones scheduled. This issue started occuring in 14.0 where support for inexact notifications was added using the ScheduleMode
enum that was added and resulted in the deprecation of androidAllowWhileIdle
. A mechanism was added to help "migrate" old notifications that had androidAllowWhileIdle
specified but didn't account for how there are recurring notifications that were scheduled using older versions of the plugin prior to androidAllowWhile
being addedDarwinNotificationDetails
class where this This
was being repeated. Thanks to the PR from Adrian Jagielak
requestPermission()
associated with the AndroidFlutterLocalNotificationsPlugin
class to requestNotificationsPermission()
. This was done to be more explicit given another method (requestExactAlarmsPermission()
) has been added that also requests a permission (more details below).AndroidManifest.xml
. This means applications making use of either scheduled notifications, full-screen intent notifications or notification actions will now require changes in the application's own AndroidManifest.xml
file. Please check the AndroidManifest.xml setup section of the readme for more details. The reason this was done was because not all applications will leverage all of the plugin's features. Doing this will now allow applications to only request the appropriate permissions needed for their application. This addresses issue 1687
requestExactAlarmsPermission()
method that has been added to the AndroidFlutterLocalNotificationsPlugin
class that represents the Android implementation of the plugin. This has been done in response to behaviour changes introduced in Android 14 (API level 34) when comes to using exact alarms. See the official documentation about these changes here. This change addresses issue 1906
ScheduleMode
enum that was added and resulted in the deprecation of androidAllowWhileIdle
. A mechanism was added to help "migrate" old notifications that had androidAllowWhileIdle
specified but didn't account for how there are recurring notifications that were scheduled using older versions of the plugin prior to androidAllowWhile
being addedScheduleMode
enum that was added and resulted in the deprecation of androidAllowWhileIdle
. A mechanism was added to help "migrate" old notifications that had androidAllowWhileIdle
specified but didn't account for how there are recurring notifications that were scheduled using older versions of the plugin prior to androidAllowWhile
being addedschedule()
, showDailyAtTime()
and showWeeklyAtDayAndTime()
methods. Notifications that were scheduled prior to this release should still workTime
classzonedSchedule()
on Linux will now throw an UnimplementedError
to align with how their is a Linux implementation but the method hasn't been implementedScheduledNotifReceiver
instead of ScheduledNotifReceiver
. When logging that exact alarm permissions have been revoked the the tag is now FLTLocalNotifPlugin
instead of notification
initialize()
methodzonedSchedule()
on Linux will now throw an UnimplementedError
to align with how their is a Linux implementation but the method hasn't been implementedinitialize()
method