fix(deps): update dependency flutter_local_notifications to v16 #46

Merged

hernik merged 2 commits from renovate/flutter_local_notifications-16.x into main

2023-11-28 19:12:59 +01:00

renovator commented

2023-10-05 16:00:52 +02:00

Collaborator

This PR contains the following updates:

Package	Type	Update	Change
flutter_local_notifications (source)	dependencies	major	`^12.0.3+1` -> `^16.0.0`

Release Notes

MaikuB/flutter_local_notifications (flutter_local_notifications)

`v16.2.0`

Compare Source

Android] added the `silent` property to the `AndroidNotificationDetails` 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-euclidk](https://github.com/aa-euclidk)

`v16.1.0`

Compare Source

Android] calling the `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 [ShunMc](https://github.com/ShunMc)

Android] fixed conflict with other plugins when it comes to handling permission requests. Thanks to the PR from [Patrick](https://github.com/Eimji)

Fixed grammar issue and iOS/macOS specific code snippet in the notification actions section of the readme. Thanks to the PRs from Md. Touhidul Islam

`v16.0.0`

Compare Source

Android] **Breaking change** renamed the `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).

Android] **Breaking change** the plugin now only declares the bare minimum in its `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](https://pub.dev/packages/flutter_local_notifications#androidmanifestxml-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](https://github.com/MaikuB/flutter_local_notifications/issues/1687)

Android] added the ability to request permission to schedule exact alarms via the `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](https://developer.android.com/about/versions/14/changes/schedule-exact-alarms). This change addresses issue [1906](https://github.com/MaikuB/flutter_local_notifications/issues/1906)

Android] bumped Java desugaring dependency and updated readme accordingly to also mention Gradle version that is used by plugin

Android] fixed issue an issue similar to [2033](https://github.com/MaikuB/flutter_local_notifications/issues/2033) that was addressed in 15.0.1 where notifications on scheduled using older version of the plugin via the `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 releases

Android] fixed issue [2106](https://github.com/MaikuB/flutter_local_notifications/issues/2106) where calling `getNotificationChannels()` 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 releases

iOS]\[macOS] addresses issue [2097](https://github.com/MaikuB/flutter_local_notifications/issues/2097) by updating API docs for the `presentSound` 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 false

Updated example app so that the Android side specifies minimum SDK version version that aligns with what's specified by the Flutter SDK
Fixed Dart API docs for DarwinNotificationDetails class where this This was being repeated. Thanks to the PR from Adrian Jagielak
Fixed example code shown at the "Handling notifications whilst the app is in the foreground" section of the readme. Thanks to the PR from Tinh Huynh

`v15.1.2`

Compare Source

Android] fixed issue [2106](https://github.com/MaikuB/flutter_local_notifications/issues/2106) where calling `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 release

`v15.1.1`

Compare Source

Android] fixed issue an issue similar to [2033](https://github.com/MaikuB/flutter_local_notifications/issues/2033) that was addressed in 15.0.1 where notifications on scheduled using older version of the plugin via the `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 well

Updated example app so that the Android side specifies minimum SDK version version that aligns with what's specified by the Flutter SDK. This has been taken from the 16.0.0-dev.2 prerelease to allow the example app to build using recent versions where the minimum Android SDK version has changed from 16 to 19

`v15.1.0`

Compare Source

iOS]\[macOS] added the ability to request provisional permissions. On iOS, this is only applicable to iOS 12 or newer. On macOS, this property is only applicable to macOS 10.14 or newer. Thanks to the PR from [Tokenyet](https://github.com/MaikuB/flutter_local_notifications/pull/2022)

`v15.0.1`

Compare Source

Android] Fixed issue [2033](https://github.com/MaikuB/flutter_local_notifications/issues/2033) where notifications on scheduled using older version of the plugin 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

`v15.0.0`

Compare Source

Breaking change removed deprecated schedule(), showDailyAtTime() and showWeeklyAtDayAndTime() methods. Notifications that were scheduled prior to this release should still work
Breaking change removed Time class

Linux] **Breaking change** calling `zonedSchedule()` on Linux will now throw an `UnimplementedError` to align with how their is a Linux implementation but the method hasn't been implemented

iOS]\[macOS] **Breaking change** added supported for banner and list presentation options for iOS and macOS that is applicable for iOS 14.0 or newer and macOS 11 or newer. This is a breaking change as the values default to true and the alert presentation option is no longer applicable on these OS versions as Apple has deprecated it to be replaced by the banner and list presentations. Please ensure that if you target these OS versions that you configure the options appropriately for your application.

Android] updated tags used when writing error logs. For corrupt scheduled notifications and error is logged the tag is now `ScheduledNotifReceiver` instead of `ScheduledNotifReceiver`. When logging that exact alarm permissions have been revoked the the tag is now `FLTLocalNotifPlugin` instead of `notification`

Updated API documentation related to the iOS/macOS notification presentation options to include links to Apple's documentations to show what they correspond to
Fixed typo in API docs for initialize() method

`v14.1.4`

Compare Source

Android] fixed issue [2106](https://github.com/MaikuB/flutter_local_notifications/issues/2106) where calling `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

`v14.1.3`

Compare Source

Android] fixed issue an issue similar to [2033](https://github.com/MaikuB/flutter_local_notifications/issues/2033) that was addressed in 15.0.1 where notifications on scheduled using older version of the plugin via the `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

Updated example app so that the Android side specifies minimum SDK version version that aligns with what's specified by the Flutter SDK. This has been taken from the 16.0.0-dev.2 prerelease to allow the example app to build using recent versions where the minimum Android SDK version has changed from 16 to 19

`v14.1.2`

Compare Source

Android] Fixed issue [2033](https://github.com/MaikuB/flutter_local_notifications/issues/2033) where notifications on scheduled using older version of the plugin 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

`v14.1.1`

Compare Source

Fixed typo in API docs for the deprecated showDailyAtTime() method. Thanks to the PR from Yuichiro Kawano

Android] removed a call to standard output via `System.out.println()`

`v14.1.0`

Compare Source

Android] added `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](https://github.com/iballan)

`v14.0.1`

Compare Source

Android] fixed issue [1991](https://github.com/MaikuB/flutter_local_notifications/issues/1991) where tapping on a notification action with `showUserInterface` set to true whilst app is terminated wouldn't dismiss/cancel notification

Android] updated logic when trying to show a scheduled notification so that receiver would remove a corrupt notification to avoid exceptions from occurring over and over again. An message will be written to error log when this occurs as well. Thanks to the PR from \[]

Fixed example app on iOS and macOS so it would play the custom sound as this step was missed in previous released where the iOS and macOS side was recreated

`v14.0.0`

Compare Source

Breaking change the id property of the ActiveNotification 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 frankvollebregt
Breaking change the following classes are now enums
- AndroidNotificationCategory
- AndroidServiceForegroundType
- AndroidServiceStartType
- AudioAttributesUsage
- Day
- InterruptionLevel
- LinuxNotificationCategory
- LinuxNotificationUrgency
- Priority

Android] added support for scheduling inexact notifications. The corresponding APIs for scheduling notifications now have a new `AndroidScheduleMode` to allow for configuring this if required. The `androidAllowWhileIdle` argument is now deprecated when using the APIs available for scheduling notifications via the `FlutterLocalNotificationsPlugin` APIs and will be removed in the future. Thanks to the PR from [Joachim Böhmer](https://github.com/kaptnkoala). Note that if if a notification was scheduled with exact timing via the `AndroidScheduleMode` 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 the `androidScheduleMode` parameter has a default value of `AndroidScheduleMode.exact` to align with what was the default value of `androidAllowWhileIdle` 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 the `androidAllowWhileIdle` parameter is removed in the future, `androidScheduleMode` will become a required named parameter to ensure developers explicitly specify the value they want
-   \[Android] **Breaking change** related to this is whilst `androidAllowWhileIdle` is deprecated via the `FlutterLocalNotificationsPlugin` APIs, `allowWhileIdle` has been removed and completely replaced by a `scheduleMode` parameter when whe directly using the `AndroidFlutterLocalNotificationsPlugin` APIs

Android] adds a namespace for compatibility with AGP (Android Gradle plugin) 8.0. Thanks to the PR from [asaarnak](https://github.com/asaarnak)

iOS]\[macOS] fixed issue [1950](https://github.com/MaikuB/flutter_local_notifications/issues/1950) where plugin would crash when calling `zonedSchedule()` 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 be

Android] updated `AndroidServiceForegroundType` values to align with new additions that are part of Android 14. Thanks to the PR from [Rexios](https://github.com/Rexios80)

macOS] fixed issue [1858](https://github.com/MaikuB/flutter_local_notifications/issues/1858) where macOS app builds were showing deprecation warnings. Thanks to the PR from [Steve Kohls](https://github.com/stevekohls)

Bumped mockito dev dependency
Align Dart SDK constraint with minimum Flutter version (i.e. 3.0)
Fixed readme that was reference old classes with IOS as part of the name instead of the newer classes that have the Darwin prefix
Removed dead link that had archived official documentation around guidance on creating the appropriate Android icons that would help with creating notification icons. Now replaced with a link to using Image Asset Studio to create notification icons

`v13.0.0`

Compare Source

Android] Bumped Android Gradle plugin to 7.3.1. Thanks to the PR from [Rexios](https://github.com/Rexios80)

- Updated minimum Flutter version to 3.0.0. Note that technically this was already a requirement by flutter_local_notifications_linux 2.0.0 as ffi 2.0.0 requires Dart 2.17 at a minimum and that shipped with Flutter 3.0.0
Added explicit ffi dependency that Linux implementation of the plugin was already using
Updated site used by example app to display dummy/placeholder images
Updated readme to warn developers that choose not to follow the official Android guidance around notification icons that using the @mipmap/ic_launcher resource requires additional release build configuration. Thanks to the PR from Daniel Arndt
Updated readme to add note about how Flutter has an issue with apps running with desugaring on Android 12L and above. Thanks to the PR from Mirek Mazel See https://github.com/flutter/flutter/issues/110658. One potential fix added to the readme is for apps to add the WindowManager library as a dependency:

dependencies {
    implementation 'androidx.window:window:1.0.0'
    implementation 'androidx.window:window-java:1.0.0'
    ...
}

Configuration

📅 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.

If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [flutter_local_notifications](https://github.com/MaikuB/flutter_local_notifications/tree/master/flutter_local_notifications) ([source](https://github.com/MaikuB/flutter_local_notifications)) | dependencies | major | `^12.0.3+1` -> `^16.0.0` | --- ### Release Notes <details> <summary>MaikuB/flutter_local_notifications (flutter_local_notifications)</summary> ### [`v16.2.0`](https://github.com/MaikuB/flutter_local_notifications/releases/tag/flutter_local_notifications-v16.2.0) [Compare Source](https://github.com/MaikuB/flutter_local_notifications/compare/flutter_local_notifications-v16.1.0...flutter_local_notifications-v16.2.0) - \[Android] added the `silent` property to the `AndroidNotificationDetails` 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-euclidk](https://github.com/aa-euclidk) ### [`v16.1.0`](https://github.com/MaikuB/flutter_local_notifications/releases/tag/flutter_local_notifications-v16.1.0) [Compare Source](https://github.com/MaikuB/flutter_local_notifications/compare/flutter_local_notifications-v16.0.0+1...flutter_local_notifications-v16.1.0) - \[Android] calling the `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 [ShunMc](https://github.com/ShunMc) - \[Android] fixed conflict with other plugins when it comes to handling permission requests. Thanks to the PR from [Patrick](https://github.com/Eimji) - Fixed grammar issue and iOS/macOS specific code snippet in the notification actions section of the readme. Thanks to the PRs from [Md. Touhidul Islam](https://github.com/udoy-touhid) ### [`v16.0.0+1`](https://github.com/MaikuB/flutter_local_notifications/compare/flutter_local_notifications-v16.0.0+1...flutter_local_notifications-v16.0.0+1) [Compare Source](https://github.com/MaikuB/flutter_local_notifications/compare/flutter_local_notifications-v16.0.0+1...flutter_local_notifications-v16.0.0+1) ### [`v16.0.0`](https://github.com/MaikuB/flutter_local_notifications/releases/tag/flutter_local_notifications-v16.0.0) [Compare Source](https://github.com/MaikuB/flutter_local_notifications/compare/flutter_local_notifications-v15.1.2...flutter_local_notifications-v16.0.0+1) - \[Android] **Breaking change** renamed the `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). - \[Android] **Breaking change** the plugin now only declares the bare minimum in its `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](https://pub.dev/packages/flutter_local_notifications#androidmanifestxml-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](https://github.com/MaikuB/flutter_local_notifications/issues/1687) - \[Android] added the ability to request permission to schedule exact alarms via the `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](https://developer.android.com/about/versions/14/changes/schedule-exact-alarms). This change addresses issue [1906](https://github.com/MaikuB/flutter_local_notifications/issues/1906) - \[Android] bumped Java desugaring dependency and updated readme accordingly to also mention Gradle version that is used by plugin - \[Android] fixed issue an issue similar to [2033](https://github.com/MaikuB/flutter_local_notifications/issues/2033) that was addressed in 15.0.1 where notifications on scheduled using older version of the plugin via the `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 releases - \[Android] fixed issue [2106](https://github.com/MaikuB/flutter_local_notifications/issues/2106) where calling `getNotificationChannels()` 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 releases - \[iOS]\[macOS] addresses issue [2097](https://github.com/MaikuB/flutter_local_notifications/issues/2097) by updating API docs for the `presentSound` 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 false - Updated example app so that the Android side specifies minimum SDK version version that aligns with what's specified by the Flutter SDK - Fixed Dart API docs for `DarwinNotificationDetails` class where `this This` was being repeated. Thanks to the PR from [Adrian Jagielak](https://github.com/adrianjagielak) - Fixed example code shown at the "Handling notifications whilst the app is in the foreground" section of the readme. Thanks to the PR from [Tinh Huynh](https://github.com/TinhHuynh) ### [`v15.1.2`](https://github.com/MaikuB/flutter_local_notifications/releases/tag/flutter_local_notifications-v15.1.2) [Compare Source](https://github.com/MaikuB/flutter_local_notifications/compare/flutter_local_notifications-v15.1.1...flutter_local_notifications-v15.1.2) - \[Android] fixed issue [2106](https://github.com/MaikuB/flutter_local_notifications/issues/2106) where calling `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 release ### [`v15.1.1`](https://github.com/MaikuB/flutter_local_notifications/releases/tag/flutter_local_notifications-v15.1.1) [Compare Source](https://github.com/MaikuB/flutter_local_notifications/compare/flutter_local_notifications-v15.1.0+1...flutter_local_notifications-v15.1.1) - \[Android] fixed issue an issue similar to [2033](https://github.com/MaikuB/flutter_local_notifications/issues/2033) that was addressed in 15.0.1 where notifications on scheduled using older version of the plugin via the `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 well - Updated example app so that the Android side specifies minimum SDK version version that aligns with what's specified by the Flutter SDK. This has been taken from the 16.0.0-dev.2 prerelease to allow the example app to build using recent versions where the minimum Android SDK version has changed from 16 to 19 ### [`v15.1.0+1`](https://github.com/MaikuB/flutter_local_notifications/compare/flutter_local_notifications-v15.1.0+1...flutter_local_notifications-v15.1.0+1) [Compare Source](https://github.com/MaikuB/flutter_local_notifications/compare/flutter_local_notifications-v15.1.0+1...flutter_local_notifications-v15.1.0+1) ### [`v15.1.0`](https://github.com/MaikuB/flutter_local_notifications/releases/tag/flutter_local_notifications-v15.1.0) [Compare Source](https://github.com/MaikuB/flutter_local_notifications/compare/flutter_local_notifications-v15.0.1...flutter_local_notifications-v15.1.0+1) - \[iOS]\[macOS] added the ability to request provisional permissions. On iOS, this is only applicable to iOS 12 or newer. On macOS, this property is only applicable to macOS 10.14 or newer. Thanks to the PR from [Tokenyet](https://github.com/MaikuB/flutter_local_notifications/pull/2022) ### [`v15.0.1`](https://github.com/MaikuB/flutter_local_notifications/releases/tag/flutter_local_notifications-v15.0.1) [Compare Source](https://github.com/MaikuB/flutter_local_notifications/compare/flutter_local_notifications-v15.0.0...flutter_local_notifications-v15.0.1) - \[Android] Fixed issue [2033](https://github.com/MaikuB/flutter_local_notifications/issues/2033) where notifications on scheduled using older version of the plugin 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 ### [`v15.0.0`](https://github.com/MaikuB/flutter_local_notifications/releases/tag/flutter_local_notifications-v15.0.0) [Compare Source](https://github.com/MaikuB/flutter_local_notifications/compare/flutter_local_notifications-v14.1.4...flutter_local_notifications-v15.0.0) - **Breaking change** removed deprecated `schedule()`, `showDailyAtTime()` and `showWeeklyAtDayAndTime()` methods. Notifications that were scheduled prior to this release should still work - **Breaking change** removed `Time` class - \[Linux] **Breaking change** calling `zonedSchedule()` on Linux will now throw an `UnimplementedError` to align with how their is a Linux implementation but the method hasn't been implemented - \[iOS]\[macOS] **Breaking change** added supported for banner and list presentation options for iOS and macOS that is applicable for iOS 14.0 or newer and macOS 11 or newer. This is a breaking change as the values default to true and the alert presentation option is no longer applicable on these OS versions as Apple has deprecated it to be replaced by the banner and list presentations. Please ensure that if you target these OS versions that you configure the options appropriately for your application. - \[Android] updated tags used when writing error logs. For corrupt scheduled notifications and error is logged the tag is now `ScheduledNotifReceiver` instead of `ScheduledNotifReceiver`. When logging that exact alarm permissions have been revoked the the tag is now `FLTLocalNotifPlugin` instead of `notification` - Updated API documentation related to the iOS/macOS notification presentation options to include links to Apple's documentations to show what they correspond to - Fixed typo in API docs for `initialize()` method ### [`v14.1.4`](https://github.com/MaikuB/flutter_local_notifications/releases/tag/flutter_local_notifications-v14.1.4) [Compare Source](https://github.com/MaikuB/flutter_local_notifications/compare/flutter_local_notifications-v14.1.3+1...flutter_local_notifications-v14.1.4) - \[Android] fixed issue [2106](https://github.com/MaikuB/flutter_local_notifications/issues/2106) where calling `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 ### [`v14.1.3+1`](https://github.com/MaikuB/flutter_local_notifications/compare/flutter_local_notifications-v14.1.3+1...flutter_local_notifications-v14.1.3+1) [Compare Source](https://github.com/MaikuB/flutter_local_notifications/compare/flutter_local_notifications-v14.1.3+1...flutter_local_notifications-v14.1.3+1) ### [`v14.1.3`](https://github.com/MaikuB/flutter_local_notifications/releases/tag/flutter_local_notifications-v14.1.3) [Compare Source](https://github.com/MaikuB/flutter_local_notifications/compare/flutter_local_notifications-v14.1.2...flutter_local_notifications-v14.1.3+1) - \[Android] fixed issue an issue similar to [2033](https://github.com/MaikuB/flutter_local_notifications/issues/2033) that was addressed in 15.0.1 where notifications on scheduled using older version of the plugin via the `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 - Updated example app so that the Android side specifies minimum SDK version version that aligns with what's specified by the Flutter SDK. This has been taken from the 16.0.0-dev.2 prerelease to allow the example app to build using recent versions where the minimum Android SDK version has changed from 16 to 19 ### [`v14.1.2`](https://github.com/MaikuB/flutter_local_notifications/releases/tag/flutter_local_notifications-v14.1.2) [Compare Source](https://github.com/MaikuB/flutter_local_notifications/compare/flutter_local_notifications-v14.1.1...flutter_local_notifications-v14.1.2) - \[Android] Fixed issue [2033](https://github.com/MaikuB/flutter_local_notifications/issues/2033) where notifications on scheduled using older version of the plugin 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 ### [`v14.1.1`](https://github.com/MaikuB/flutter_local_notifications/releases/tag/flutter_local_notifications-v14.1.1) [Compare Source](https://github.com/MaikuB/flutter_local_notifications/compare/flutter_local_notifications-v14.1.0...flutter_local_notifications-v14.1.1) - Fixed typo in API docs for the deprecated `showDailyAtTime()` method. Thanks to the PR from [Yuichiro Kawano](https://github.com/yu1ro) - \[Android] removed a call to standard output via `System.out.println()` ### [`v14.1.0`](https://github.com/MaikuB/flutter_local_notifications/releases/tag/flutter_local_notifications-v14.1.0) [Compare Source](https://github.com/MaikuB/flutter_local_notifications/compare/flutter_local_notifications-v14.0.1...flutter_local_notifications-v14.1.0) - \[Android] added `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](https://github.com/iballan) ### [`v14.0.1`](https://github.com/MaikuB/flutter_local_notifications/releases/tag/flutter_local_notifications-v14.0.1) [Compare Source](https://github.com/MaikuB/flutter_local_notifications/compare/flutter_local_notifications-v14.0.0+2...flutter_local_notifications-v14.0.1) - \[Android] fixed issue [1991](https://github.com/MaikuB/flutter_local_notifications/issues/1991) where tapping on a notification action with `showUserInterface` set to true whilst app is terminated wouldn't dismiss/cancel notification - \[Android] updated logic when trying to show a scheduled notification so that receiver would remove a corrupt notification to avoid exceptions from occurring over and over again. An message will be written to error log when this occurs as well. Thanks to the PR from \[] - Fixed example app on iOS and macOS so it would play the custom sound as this step was missed in previous released where the iOS and macOS side was recreated ### [`v14.0.0+2`](https://github.com/MaikuB/flutter_local_notifications/compare/flutter_local_notifications-v14.0.0+2...flutter_local_notifications-v14.0.0+2) [Compare Source](https://github.com/MaikuB/flutter_local_notifications/compare/flutter_local_notifications-v14.0.0+2...flutter_local_notifications-v14.0.0+2) ### [`v14.0.0+1`](https://github.com/MaikuB/flutter_local_notifications/compare/flutter_local_notifications-v14.0.0+2...flutter_local_notifications-v14.0.0+2) [Compare Source](https://github.com/MaikuB/flutter_local_notifications/compare/flutter_local_notifications-v14.0.0+2...flutter_local_notifications-v14.0.0+2) ### [`v14.0.0`](https://github.com/MaikuB/flutter_local_notifications/releases/tag/flutter_local_notifications-v14.0.0) [Compare Source](https://github.com/MaikuB/flutter_local_notifications/compare/flutter_local_notifications-v13.0.0...flutter_local_notifications-v14.0.0+2) - **Breaking change** the `id` property of the `ActiveNotification` 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 [frankvollebregt](https://github.com/frankvollebregt) - **Breaking change** the following classes are now enums - `AndroidNotificationCategory` - `AndroidServiceForegroundType` - `AndroidServiceStartType` - `AudioAttributesUsage` - `Day` - `InterruptionLevel` - `LinuxNotificationCategory` - `LinuxNotificationUrgency` - `Priority` - \[Android] added support for scheduling inexact notifications. The corresponding APIs for scheduling notifications now have a new `AndroidScheduleMode` to allow for configuring this if required. The `androidAllowWhileIdle` argument is now deprecated when using the APIs available for scheduling notifications via the `FlutterLocalNotificationsPlugin` APIs and will be removed in the future. Thanks to the PR from [Joachim Böhmer](https://github.com/kaptnkoala). Note that if if a notification was scheduled with exact timing via the `AndroidScheduleMode` 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 the `androidScheduleMode` parameter has a default value of `AndroidScheduleMode.exact` to align with what was the default value of `androidAllowWhileIdle` 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 the `androidAllowWhileIdle` parameter is removed in the future, `androidScheduleMode` will become a required named parameter to ensure developers explicitly specify the value they want - \[Android] **Breaking change** related to this is whilst `androidAllowWhileIdle` is deprecated via the `FlutterLocalNotificationsPlugin` APIs, `allowWhileIdle` has been removed and completely replaced by a `scheduleMode` parameter when whe directly using the `AndroidFlutterLocalNotificationsPlugin` APIs - \[Android] adds a namespace for compatibility with AGP (Android Gradle plugin) 8.0. Thanks to the PR from [asaarnak](https://github.com/asaarnak) - \[iOS]\[macOS] fixed issue [1950](https://github.com/MaikuB/flutter_local_notifications/issues/1950) where plugin would crash when calling `zonedSchedule()` 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 be - \[Android] updated `AndroidServiceForegroundType` values to align with new additions that are part of Android 14. Thanks to the PR from [Rexios](https://github.com/Rexios80) - \[macOS] fixed issue [1858](https://github.com/MaikuB/flutter_local_notifications/issues/1858) where macOS app builds were showing deprecation warnings. Thanks to the PR from [Steve Kohls](https://github.com/stevekohls) - Bumped `mockito` dev dependency - Align Dart SDK constraint with minimum Flutter version (i.e. 3.0) - Fixed readme that was reference old classes with `IOS` as part of the name instead of the newer classes that have the `Darwin` prefix - Removed dead link that had archived official documentation around guidance on creating the appropriate Android icons that would help with creating notification icons. Now replaced with a link to using [Image Asset Studio](https://developer.android.com/studio/write/create-app-icons#create-notification) to create notification icons ### [`v13.0.0`](https://github.com/MaikuB/flutter_local_notifications/releases/tag/flutter_local_notifications-v13.0.0) [Compare Source](https://github.com/MaikuB/flutter_local_notifications/compare/flutter_local_notifications-v12.0.4...flutter_local_notifications-v13.0.0) - \[Android] Bumped Android Gradle plugin to 7.3.1. Thanks to the PR from [Rexios](https://github.com/Rexios80) - - Updated minimum Flutter version to 3.0.0. Note that technically this was already a requirement by `flutter_local_notifications_linux` 2.0.0 as `ffi` 2.0.0 requires Dart 2.17 at a minimum and that shipped with Flutter 3.0.0 - Added explicit `ffi` dependency that Linux implementation of the plugin was already using - Updated site used by example app to display dummy/placeholder images - Updated readme to warn developers that choose not to follow the official Android guidance around notification icons that using the `@mipmap/ic_launcher` resource requires additional release build configuration. Thanks to the PR from [Daniel Arndt](https://github.com/DanielArndt) - Updated readme to add note about how Flutter has an issue with apps running with desugaring on Android 12L and above. Thanks to the PR from [Mirek Mazel](https://github.com/12people) See https://github.com/flutter/flutter/issues/110658. One potential fix added to the readme is for apps to add the [WindowManager library](https://developer.android.com/jetpack/androidx/releases/window) as a dependency: ```gradle dependencies { implementation 'androidx.window:window:1.0.0' implementation 'androidx.window:window-java:1.0.0' ... } ``` </details> --- ### Configuration :date: **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined). :vertical_traffic_light: **Automerge**: Disabled by config. Please merge this manually once you are satisfied. :recycle: **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. :no_bell: **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] If you want to rebase/retry this PR, check this box --- This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).

renovator added 1 commit 2023-10-05 16:00:53 +02:00