๐จโ๐ฉโ๐ง ๐ธ Parental Control App- For Android ๐This Application use Native plugins to get local data such as Location and AppData to send it to the database. These information are saved in cache. In order to monitor the time spend on screen parent can then send messages and warn kids when itโs time to go to bed or do their homework. ๐ฑ๐๐
Apache License 2.0
119
stars
46
forks
source link
chore(deps): bump flutter_local_notifications from 14.1.1 to 16.1.0 #216
[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
[Android] fixed conflict with other plugins when it comes to handling permission requests. Thanks to the PR from Patrick
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
flutter_local_notifications-v16.0.0
[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 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
[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. This change addresses issue 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 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 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 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
flutter_local_notifications-v16.0.0+1
Updated code snippet in readme to reflect changes done on renaming the requestPermission() method associated with the AndroidFlutterLocalNotificationsPlugin class to requestNotificationsPermission(). Thanks to PR from Rรณger Ninow
Fixed changelog entry in 16.0.0 around renaming the requestPermission() method as the word "method" itself was missing
flutter_local_notifications-v16.0.0-dev.2
[Android] fixed issue an issue similar to 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
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
flutter_local_notifications-v16.0.0-dev.1
[Android] Breaking change renamed the 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).
[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 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
[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. This change addresses issue 1906
[Android] bumped Java desugaring dependency and updated readme accordingly to also mention Gradle version that is used by plugin
flutter_local_notifications-v15.1.2
[Android] fixed issue 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
flutter_local_notifications-v15.1.1
[Android] fixed issue an issue similar to 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
flutter_local_notifications-v15.1.0
[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
flutter_local_notifications-v15.1.0+1
Fixed formatting of 15.1.0 changelog entry
flutter_local_notifications-v15.0.1
[Android] Fixed issue 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
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
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.
Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- `@dependabot show ignore conditions` will show all of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
Bumps flutter_local_notifications from 14.1.1 to 16.1.0.
Release notes
Sourced from flutter_local_notifications's releases.
... (truncated)
Commits
033aea6
prepare for 16.1.0 release (#2122)8192532
Update README.md (#2119)682f2a6
Google Java Format1ce5794
updated requestExactAlarmPermissions to open alarm settings screen specific t...7f92cb0
Update README.md (#2115)eb7a185
Google Java Format48f1d59
Fix conflict with other plugins (onActivityResult) (#2121)ac612d3
prepare for 16.0.0+1 release (#2114)8a77b5f
fix docs for Android notification permission (#2113)f59f7eb
[flutter_local_notifications] updated presentSound and defaultPresentSound AP...Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase
.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show