fix(deps): update dependency flutter_local_notifications to v16 #46
No reviewers
Labels
No labels
bug
dokumentace
dotaz
duplikát
good first issue
help wanted
knihovna
lowprio
pr: funkce
pr: okno
pr: pubspec
vylepšení
wontfix
No milestone
No project
No assignees
2 participants
Due date
No due date set.
Dependencies
No dependencies set.
Reference: hernik/opencanteen#46
Loading…
Reference in a new issue
No description provided.
Delete branch "renovate/flutter_local_notifications-16.x"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This PR contains the following updates:
^12.0.3+1
->^16.0.0
Release Notes
MaikuB/flutter_local_notifications (flutter_local_notifications)
v16.2.0
Compare Source
silent
property to theAndroidNotificationDetails
that allows specifying a notification on Android to be silent even if associated the notification channel allows for sounds to be played. Thanks to the PR from aa-euclidkv16.1.0
Compare Source
requestExactAlarmsPermission()
method will now go directly to the alarm settings screen specific to the app instead the general alarm settings screen where users needed to pick the app they wanted to change the settings for. Thanks to the PR from ShunMcv16.0.0+1
Compare Source
v16.0.0
Compare Source
requestPermission()
method associated with theAndroidFlutterLocalNotificationsPlugin
class torequestNotificationsPermission()
. 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 ownAndroidManifest.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 1687requestExactAlarmsPermission()
method that has been added to theAndroidFlutterLocalNotificationsPlugin
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 1906periodicallyShow()
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 theScheduleMode
enum that was added and resulted in the deprecation ofandroidAllowWhileIdle
. A mechanism was added to help "migrate" old notifications that hadandroidAllowWhileIdle
specified but didn't account for how there are recurring notifications that were scheduled using older versions of the plugin prior toandroidAllowWhile
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
anddefaultPresentSound
properties that belong to theDarwinNotificationDetails
andDarwinInitializationSettings
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 wherethis This
was being repeated. Thanks to the PR from Adrian Jagielakv15.1.2
Compare Source
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 releasev15.1.1
Compare Source
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 theScheduleMode
enum that was added and resulted in the deprecation ofandroidAllowWhileIdle
. A mechanism was added to help "migrate" old notifications that hadandroidAllowWhileIdle
specified but didn't account for how there are recurring notifications that were scheduled using older versions of the plugin prior toandroidAllowWhile
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 wellv15.1.0+1
Compare Source
v15.1.0
Compare Source
v15.0.1
Compare Source
ScheduleMode
enum that was added and resulted in the deprecation ofandroidAllowWhileIdle
. A mechanism was added to help "migrate" old notifications that hadandroidAllowWhileIdle
specified but didn't account for how there are recurring notifications that were scheduled using older versions of the plugin prior toandroidAllowWhile
being addedv15.0.0
Compare Source
schedule()
,showDailyAtTime()
andshowWeeklyAtDayAndTime()
methods. Notifications that were scheduled prior to this release should still workTime
classzonedSchedule()
on Linux will now throw anUnimplementedError
to align with how their is a Linux implementation but the method hasn't been implementedScheduledNotifReceiver
instead ofScheduledNotifReceiver
. When logging that exact alarm permissions have been revoked the the tag is nowFLTLocalNotifPlugin
instead ofnotification
initialize()
methodv14.1.4
Compare Source
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 prereleasev14.1.3+1
Compare Source
v14.1.3
Compare Source
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 theScheduleMode
enum that was added and resulted in the deprecation ofandroidAllowWhileIdle
. A mechanism was added to help "migrate" old notifications that hadandroidAllowWhileIdle
specified but didn't account for how there are recurring notifications that were scheduled using older versions of the plugin prior toandroidAllowWhile
being added. This hotfix has been taken from the 16.0.0-dev.2 prereleasev14.1.2
Compare Source
ScheduleMode
enum that was added and resulted in the deprecation ofandroidAllowWhileIdle
. A mechanism was added to help "migrate" old notifications that hadandroidAllowWhileIdle
specified but didn't account for how there are recurring notifications that were scheduled using older versions of the plugin prior toandroidAllowWhile
being addedv14.1.1
Compare Source
showDailyAtTime()
method. Thanks to the PR from Yuichiro KawanoSystem.out.println()
v14.1.0
Compare Source
alarmClock
as one of theAndroidScheduleMode
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 Ballanv14.0.1
Compare Source
showUserInterface
set to true whilst app is terminated wouldn't dismiss/cancel notificationv14.0.0+2
Compare Source
v14.0.0+1
Compare Source
v14.0.0
Compare Source
id
property of theActiveNotification
class is now nullable to help indicate that the notification may not have been created by the plugin e.g. it was from Firebase Cloud Messaging. Thanks to the PR from frankvollebregtAndroidNotificationCategory
AndroidServiceForegroundType
AndroidServiceStartType
AudioAttributesUsage
Day
InterruptionLevel
LinuxNotificationCategory
LinuxNotificationUrgency
Priority
AndroidScheduleMode
to allow for configuring this if required. TheandroidAllowWhileIdle
argument is now deprecated when using the APIs available for scheduling notifications via theFlutterLocalNotificationsPlugin
APIs and will be removed in the future. Thanks to the PR from Joachim Böhmer. Note that if if a notification was scheduled with exact timing via theAndroidScheduleMode
but the exact alarm permissions had been revoked, an error log message will be written and notification will no longer be scheduled. Do note that theandroidScheduleMode
parameter has a default value ofAndroidScheduleMode.exact
to align with what was the default value ofandroidAllowWhileIdle
before (i.e.false
) where that meant exact timing was to be used but the device being a low-powered idle may cause it to be delayed. When theandroidAllowWhileIdle
parameter is removed in the future,androidScheduleMode
will become a required named parameter to ensure developers explicitly specify the value they wantandroidAllowWhileIdle
is deprecated via theFlutterLocalNotificationsPlugin
APIs,allowWhileIdle
has been removed and completely replaced by ascheduleMode
parameter when whe directly using theAndroidFlutterLocalNotificationsPlugin
APIszonedSchedule()
with a date/time value that is exactly when daylight savings occurs and the APIs from Apple weren't able to resolve what the actual date/time is meant to beAndroidServiceForegroundType
values to align with new additions that are part of Android 14. Thanks to the PR from Rexiosmockito
dev dependencyIOS
as part of the name instead of the newer classes that have theDarwin
prefixv13.0.0
Compare Source
flutter_local_notifications_linux
2.0.0 asffi
2.0.0 requires Dart 2.17 at a minimum and that shipped with Flutter 3.0.0ffi
dependency that Linux implementation of the plugin was already using@mipmap/ic_launcher
resource requires additional release build configuration. Thanks to the PR from Daniel ArndtConfiguration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻️ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR has been generated by Renovate Bot.
1cc047868d
tob284d25063