Bot releases are visible (Hide)
Published by MaikuB about 1 year ago
requestPermission()
method 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
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 was also released as part of the 15.1.1 and 14.1.3 hotfix releasesgetNotificationChannels()
reports the wrong importance level or result in an exception if the importance level was unspecified. This was also released as part of the 15.1.2 and 14.1.4 hotfix releasespresentSound
and defaultPresentSound
properties that belong to the DarwinNotificationDetails
and DarwinInitializationSettings
classes respectively to clarify the background behaviour and how have a sound play even when app is the background yet these properties are set to falseDarwinNotificationDetails
class where this This
was being repeated. Thanks to the PR from Adrian Jagielak
Published by MaikuB about 1 year ago
getNotificationChannels()
reports the wrong importance level or result in an exception if the importance level was unspecified. This hotfix has been taken from the 16.0.0-dev.3 prerelease and included in the 14.1.4 hotfix releasePublished by MaikuB about 1 year ago
getNotificationChannels()
reports the wrong importance level or result in an exception if the importance level was unspecified. This hotfix has been taken from the 16.0.0-dev.3 prereleasePublished by MaikuB about 1 year ago
getNotificationChannels()
reports the wrong importance level or result in an exception if the importance level was unspecifiedPublished by MaikuB about 1 year ago
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 prerelease and has also been applied to the 14.1.3 hotfix release as wellPublished by MaikuB about 1 year ago
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 prereleasePublished by MaikuB about 1 year ago
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 addedDarwinNotificationDetails
class where this This
was being repeated. Thanks to the PR from Adrian Jagielak
Published by MaikuB over 1 year ago
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
Published by MaikuB over 1 year ago
Published by MaikuB over 1 year ago
Published by MaikuB over 1 year ago
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 addedPublished by MaikuB over 1 year ago
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 addedPublished by MaikuB over 1 year ago
schedule()
, 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()
methodPublished by MaikuB over 1 year ago
zonedSchedule()
on Linux will now throw an UnimplementedError
to align with how their is a Linux implementation but the method hasn't been implementedinitialize()
methodPublished by MaikuB over 1 year ago
schedule
, showDailyAtTime
and showWeeklyAtDayAndTime
methods. Notifications that were scheduled prior to this release should still workTime
classScheduledNotifReceiver
instead of ScheduledNotifReceiver
. When logging that exact alarm permissions have been revoked the the tag is now FLTLocalNotifPlugin
instead of notification
Published by MaikuB over 1 year ago
showDailyAtTime()
method. Thanks to the PR from Yuichiro Kawano
System.out.println()
Published by MaikuB over 1 year ago
alarmClock
as one of the AndroidScheduleMode
options. This is useful for cases where a notification functions as an alarm and may show an alarm icon on the status bar depending on the device Thanks to the PR from Muhammed Ballan
Published by MaikuB over 1 year ago
showUserInterface
set to true whilst app is terminated wouldn't dismiss/cancel notificationPublished by MaikuB over 1 year ago