Repository navigation
fix(android): defer wakelock toggle when no activity is attached W… - #134
Merged
Merged
Conversation
…lock.toggle()/isEnabled() threw NoActivityException whenever they were called with no foreground activity attached (e.g. the app is backgrounded or mid lifecycle transition), surfacing as non-fatal crashes in apps that toggle the wakelock off the foreground path. Instead of throwing, the requested wakelock state is now tracked in Kotlin and re-applied once an activity (re)attaches — matching how the Windows/Linux/web implementations track state. The activity setter only re-asserts FLAG_KEEP_SCREEN_ON when wakelock was actually enabled, so it won't clear the flag for apps that set it on their own window. The now-unused NoActivityException class is removed. Bumps wakelock_plus to 1.6.2 and updates the CHANGELOG. Fixes fluttercommunity#131, fluttercommunity#102, fluttercommunity#6. fix(android): defer wakelock toggle when no activity is attached Wakelock.toggle()/isEnabled() threw NoActivityException whenever they were called with no foreground activity attached (e.g. the app is backgrounded or mid lifecycle transition), surfacing as non-fatal crashes in apps that toggle the wakelock off the foreground path. Instead of throwing, the requested wakelock state is now tracked in Kotlin and re-applied once an activity (re)attaches — matching how the Windows/Linux/web implementations track state. The activity setter only re-asserts FLAG_KEEP_SCREEN_ON when wakelock was actually enabled, so it won't clear the flag for apps that set it on their own window. The now-unused NoActivityException class is removed. Bumps wakelock_plus to 1.6.2 and updates the CHANGELOG. Fixes fluttercommunity#131, fluttercommunity#102, fluttercommunity#6.
diegotori
requested changes
Jun 8, 2026
| @@ -1,3 +1,6 @@ | |||
| ## [1.6.2] | |||
Collaborator
There was a problem hiding this comment.
Do not eagerly increment the changelog.
I'll handle deploying the app when the PR is merged.
| Plugin that allows you to keep the device screen awake, i.e. prevent the screen from sleeping on | ||
| Android, iOS, macOS, Windows, Linux, and web. | ||
| version: 1.6.1 | ||
| version: 1.6.2 |
Collaborator
There was a problem hiding this comment.
Do not eagerly increment the pubspec.
I'll handle deploying the app when the PR is merged.
The deferred-wakelock fix (2fb30ca) moved the activity-attach logic into Kotlin, but that branch had no JVM test coverage — its behaviour was only exercised by the example app's on-device integration tests. Add a Robolectric suite that asserts the FLAG_KEEP_SCREEN_ON window flag directly, without a device: - toggle()/isEnabled() no longer throw when no activity is attached - isEnabled() defaults to false with no activity - enabling before an activity attaches applies the flag once it does - attaching an activity while disabled leaves the flag untouched - disabling clears the flag on the attached activity - enabled state is re-applied to a new activity after detach/reattach Wire the JUnit4/Robolectric/vintage-engine test dependencies into the plugin's build.gradle and run :wakelock_plus:testDebugUnitTest as a new CI step (reusing the Gradle wrapper generated by the example APK build). No version bump or CHANGELOG entry — test/CI-only, no change to the published plugin surface.
Collaborator
|
@sadaqatdev any updates on this PR, since there are still outliers outstanding that need to be addressed. Also, please re-sync your branch to the latest changes. Thanks. |
chrisbobbe
added a commit
to chrisbobbe/zulip-flutter
that referenced
this pull request
Oct 20, 2026
Fixes zulip#2490 (see "Behavior changes, iOS, elsewhere", below). Fixes zulip#2495 (see the "Attach images or videos" behavior changes, below). file_picker 11's Android code doesn't get compiled under Android Gradle Plugin 9 with our `android.builtInKotlin=false`, so the build fails with "cannot find symbol: FilePickerPlugin". That blocks upgrading AGP, which the Flutter tool now requires: https://github.com/flutter/flutter/pull/ 193813 file_picker 13 builds fine. file_picker 13 depends (through windows_file_picker) on version 6 of package:win32, the Dart bindings for Windows APIs. So package_info_plus, share_plus, and device_info_plus move to their win32-6 majors too (and share_plus_platform_interface with share_plus), and wakelock_plus from 1.5.2 to 1.8.0. Those releases require newer versions of Flutter and Dart than before. For example, share_plus 13.3.1 requires Flutter 3.38.1 or later, up from 3.22.0 for share_plus 12.0.2. We're already on new enough versions. Their changelogs list no other breaking changes. Each package goes to its latest version, not just to the first one that works with win32 6. The exceptions are wakelock_plus 1.8.1 and file_picker_linux 2.0.1 and later: they need package:dbus 0.8, and our connectivity_plus 7.3.1 holds dbus at 0.7 (through package:nm). Both matter only on Linux: wakelock_plus 1.8.1 changes only its dbus dependency, and file_picker_linux is file_picker's Linux implementation. Changelogs: file_picker, 11.0.3 to 13.1.0: https://pub.dev/packages/file_picker/changelog#1310 file_picker_darwin, new dependency at 2.3.2: https://pub.dev/packages/file_picker_darwin/changelog android_file_picker, new dependency at 2.1.1: https://pub.dev/packages/android_file_picker/changelog file_picker_platform_interface, new dependency at 4.2.0: https://pub.dev/packages/file_picker_platform_interface/changelog share_plus, 12.0.2 to 13.3.1: https://pub.dev/packages/share_plus/changelog#1331 share_plus_platform_interface, 6.1.0 to 7.2.0: https://pub.dev/packages/share_plus_platform_interface/changelog#720 package_info_plus, 9.0.1 to 10.2.2: https://pub.dev/packages/package_info_plus/changelog#1022 device_info_plus, 12.4.0 to 13.3.0: https://pub.dev/packages/device_info_plus/changelog#1330 wakelock_plus, 1.5.2 to 1.8.0: https://pub.dev/packages/wakelock_plus/changelog#180 The list leaves out the other plugins' platform-interface packages, and packages used only on web, Windows, or Linux: file_picker_web, windows_file_picker, file_picker_linux, and win32 and what it uses. Behavior changes, iOS, "Attach files" button: - When none of the picked files can be loaded, we now show an error dialog, with the message "PlatformException(load_failed, None of the picked items could be loaded., null, null)". file_picker 11 returned an empty list then, so nothing happened. (The next commit gives the dialog a translated message, without the "PlatformException(...)" clutter.) Behavior changes, iOS, "Attach images or videos" button: - When none of the picked photos or videos can be loaded, the error dialog's message changes: - Old: "PlatformException(file_picker_error, Failed to process any images/video, <a line per picked item>, null)" - New: "PlatformException(load_failed, None of the picked items could be loaded., null, null)" (The next commit replaces that with a translated message, without the "PlatformException(...)" clutter.) - When the user picks multiple photos or videos, they're inserted in the order of the photo picker's result list. file_picker 11 inserted them in whatever order they finished loading. - Picked photos and videos keep the file name iOS gives them, such as `IMG_9329.heic`, instead of file_picker 11's `image_<UUID>_<timestamp>.heic` (zulip#2495). - file_picker 11 copied each picked photo or video into the app's Documents folder (`Documents/picked_images`), and never deleted the copies. file_picker 13 copies to the app's temporary folder instead. Copies left by file_picker 11 stay where they are. We should file an issue to get those cleaned up. Behavior changes, iOS, elsewhere: - On an iPad, the message action sheet's "Share" button now opens the share sheet, anchored at the center of the screen. With share_plus 12, it did nothing (zulip#2490). A later commit in this series updates the share_plus iPad TODO. Behavior changes, Android: - With the "Attach files" button, when the user picks several files and none of them can be read, we now show an error dialog, with the message "PlatformException(unknown_path, Failed to retrieve path., null, null)". file_picker 11 returned an empty list then, so nothing happened. (The next commit gives the dialog a translated message, without the "PlatformException(...)" clutter.) - If Android destroys the app's activity while the system file picker is open, android_file_picker now copies the picked files and saves them for `retrieveLostData()`. We don't call that, so the pick is still lost, as with file_picker 11, but the copies stay in the app's cache folder. (From reading the code.) - Otherwise, we found no changes in file_picker on our path (the "Attach files" button), from reading the code and a quick manual test on a device. - wakelock_plus changed what happens in an edge case, when the app has no Android activity attached (as while it's being destroyed): fluttercommunity/wakelock_plus#134 We're fairly sure that makes no noticeable difference for us. Code changes: - Our `pickFiles` binding follows file_picker 13's `pickFiles`: it returns a list, empty if the user cancelled, and always allows several files. Its `allowMultiple` and `withReadStream` parameters are removed, as file_picker 13 removed them. (Single-file selection now goes through a separate method, `pickFile`.) The binding also takes `darwinOptions`, so the compose box can pass the two options below, and tests can check them. - Pass `assetRepresentationMode: current` and `orderedSelection: false` (see code comments), to keep some iOS photo picker settings unchanged from file_picker 11. These are done mainly to avoid changing behavior in this upgrade; they aren't settled product decisions. - List file_picker_darwin and android_file_picker in pubspec.yaml, for their minimum versions; see the comments there. Upstream fixes: while preparing this upgrade, we found these regressions from file_picker 11 and reported them, and the maintainers fixed them. This commit takes the fixed versions, so the upgrade doesn't bring them: vicajilau/flutter_file_picker#2243 vicajilau/flutter_file_picker#2248 vicajilau/flutter_file_picker#2259 vicajilau/flutter_file_picker#2260 vicajilau/flutter_file_picker#2261 We also reported a bug in `AndroidSAFOptions`, an API new since file_picker 11 that we don't use. It's fixed too: vicajilau/flutter_file_picker#2257 And we suggested Pigeon, as well as typed, documented error codes: vicajilau/flutter_file_picker#2258 vicajilau/flutter_file_picker#2262 Related: zulip#855 Co-Authored-By: Claude Sonnet 5.5 <[email protected]> Co-Authored-By: Claude Opus 5.5 <[email protected]>
chrisbobbe
added a commit
to chrisbobbe/zulip-flutter
that referenced
this pull request
Oct 20, 2026
Fixes zulip#2490 (see "Behavior changes, iOS, elsewhere", below). Fixes zulip#2495 (see the "Attach images or videos" behavior changes, below). file_picker 11's Android code doesn't get compiled under Android Gradle Plugin 9 with our `android.builtInKotlin=false`, so the build fails with "cannot find symbol: FilePickerPlugin". That blocks upgrading AGP, which the Flutter tool now requires: https://github.com/flutter/flutter/pull/ 193813 file_picker 13 builds fine. file_picker 13 depends (through windows_file_picker) on version 6 of package:win32, the Dart bindings for Windows APIs. So package_info_plus, share_plus, and device_info_plus move to their win32-6 majors too (and share_plus_platform_interface with share_plus), and wakelock_plus from 1.5.2 to 1.8.0. Those releases require newer versions of Flutter and Dart than before. For example, share_plus 13.3.1 requires Flutter 3.38.1 or later, up from 3.22.0 for share_plus 12.0.2. We're already on new enough versions. Their changelogs list no other breaking changes. Each package goes to its latest version, not just to the first one that works with win32 6. The exceptions are wakelock_plus 1.8.1 and file_picker_linux 2.0.1 and later: they need package:dbus 0.8, and our connectivity_plus 7.3.1 holds dbus at 0.7 (through package:nm). Both matter only on Linux: wakelock_plus 1.8.1 changes only its dbus dependency, and file_picker_linux is file_picker's Linux implementation. Changelogs: file_picker, 11.0.3 to 13.1.0: https://pub.dev/packages/file_picker/changelog#1310 file_picker_darwin, new dependency at 2.3.2: https://pub.dev/packages/file_picker_darwin/changelog android_file_picker, new dependency at 2.1.1: https://pub.dev/packages/android_file_picker/changelog file_picker_platform_interface, new dependency at 4.2.0: https://pub.dev/packages/file_picker_platform_interface/changelog share_plus, 12.0.2 to 13.3.1: https://pub.dev/packages/share_plus/changelog#1331 share_plus_platform_interface, 6.1.0 to 7.2.0: https://pub.dev/packages/share_plus_platform_interface/changelog#720 package_info_plus, 9.0.1 to 10.2.2: https://pub.dev/packages/package_info_plus/changelog#1022 device_info_plus, 12.4.0 to 13.3.0: https://pub.dev/packages/device_info_plus/changelog#1330 wakelock_plus, 1.5.2 to 1.8.0: https://pub.dev/packages/wakelock_plus/changelog#180 The list leaves out the other plugins' platform-interface packages, and packages used only on web, Windows, or Linux: file_picker_web, windows_file_picker, file_picker_linux, and win32 and what it uses. Behavior changes, iOS, "Attach files" button: - When none of the picked files can be loaded, we now show an error dialog, with the message "PlatformException(load_failed, None of the picked items could be loaded., null, null)". file_picker 11 returned an empty list then, so nothing happened. (The next commit gives the dialog a translated message, without the "PlatformException(...)" clutter.) Behavior changes, iOS, "Attach images or videos" button: - When none of the picked photos or videos can be loaded, the error dialog's message changes: - Old: "PlatformException(file_picker_error, Failed to process any images/video, <a line per picked item>, null)" - New: "PlatformException(load_failed, None of the picked items could be loaded., null, null)" (The next commit replaces that with a translated message, without the "PlatformException(...)" clutter.) - When the user picks multiple photos or videos, they're inserted in the order of the photo picker's result list. file_picker 11 inserted them in whatever order they finished loading. - Picked photos and videos keep the file name iOS gives them, such as `IMG_9329.heic`, instead of file_picker 11's `image_<UUID>_<timestamp>.heic` (zulip#2495). - file_picker 11 copied each picked photo or video into the app's Documents folder (`Documents/picked_images`), and never deleted the copies. file_picker 13 copies to the app's temporary folder instead. Copies left by file_picker 11 stay where they are. We should file an issue to get those cleaned up. Behavior changes, iOS, elsewhere: - On an iPad, the message action sheet's "Share" button now opens the share sheet, anchored at the center of the screen. With share_plus 12, it did nothing (zulip#2490). A later commit in this series updates the share_plus iPad TODO. Behavior changes, Android: - With the "Attach files" button, when the user picks several files and none of them can be read, we now show an error dialog, with the message "PlatformException(unknown_path, Failed to retrieve path., null, null)". file_picker 11 returned an empty list then, so nothing happened. (The next commit gives the dialog a translated message, without the "PlatformException(...)" clutter.) - If Android destroys the app's activity while the system file picker is open, android_file_picker now copies the picked files and saves them for `retrieveLostData()`. We don't call that, so the pick is still lost, as with file_picker 11, but the copies stay in the app's cache folder. (From reading the code.) - Otherwise, we found no changes in file_picker on our path (the "Attach files" button), from reading the code and a quick manual test on a device. - wakelock_plus changed what happens in an edge case, when the app has no Android activity attached (as while it's being destroyed): fluttercommunity/wakelock_plus#134 We're fairly sure that makes no noticeable difference for us. Code changes: - Our `pickFiles` binding follows file_picker 13's `pickFiles`: it returns a list, empty if the user cancelled, and always allows several files. Its `allowMultiple` and `withReadStream` parameters are removed, as file_picker 13 removed them. (Single-file selection now goes through a separate method, `pickFile`.) The binding also takes `darwinOptions`, so the compose box can pass the two options below, and tests can check them. - Pass `assetRepresentationMode: current` and `orderedSelection: false` (see code comments), to keep some iOS photo picker settings unchanged from file_picker 11. These are done mainly to avoid changing behavior in this upgrade; they aren't settled product decisions. - List file_picker_darwin and android_file_picker in pubspec.yaml, for their minimum versions; see the comments there. Upstream fixes: while preparing this upgrade, we found these regressions from file_picker 11 and reported them, and the maintainers fixed them. This commit takes the fixed versions, so the upgrade doesn't bring them: vicajilau/flutter_file_picker#2243 vicajilau/flutter_file_picker#2248 vicajilau/flutter_file_picker#2259 vicajilau/flutter_file_picker#2260 vicajilau/flutter_file_picker#2261 We also reported a bug in `AndroidSAFOptions`, an API new since file_picker 11 that we don't use. It's fixed too: vicajilau/flutter_file_picker#2257 And we suggested Pigeon, as well as typed, documented error codes: vicajilau/flutter_file_picker#2258 vicajilau/flutter_file_picker#2262 Related: zulip#855 Co-Authored-By: Claude Sonnet 5.5 <[email protected]> Co-Authored-By: Claude Opus 5.5 <[email protected]>
chrisbobbe
added a commit
to chrisbobbe/zulip-flutter
that referenced
this pull request
Oct 21, 2026
Fixes zulip#2490 (see "Behavior changes, iOS, elsewhere", below). Fixes zulip#2495 (see the "Attach images or videos" behavior changes, below). file_picker 11's Android code doesn't get compiled under Android Gradle Plugin 9 with our `android.builtInKotlin=false`, so the build fails with "cannot find symbol: FilePickerPlugin". That blocks upgrading AGP, which the Flutter tool now requires: flutter/flutter#193813 file_picker 13 builds fine. file_picker 13 depends (through windows_file_picker) on version 6 of package:win32, the Dart bindings for Windows APIs. So package_info_plus, share_plus, and device_info_plus move to their win32-6 majors too (and share_plus_platform_interface with share_plus), and wakelock_plus from 1.5.2 to 1.8.0. Those releases require newer versions of Flutter and Dart than before. For example, share_plus 13.3.1 requires Flutter 3.38.1 or later, up from 3.22.0 for share_plus 12.0.2. We're already on new enough versions. Their changelogs list no other breaking changes. Each package goes to its latest version, not just to the first one that works with win32 6. The exceptions are wakelock_plus 1.8.1 and file_picker_linux 2.0.1 and later: they need package:dbus 0.8, and our connectivity_plus 7.3.1 holds dbus at 0.7 (through package:nm). Both matter only on Linux: wakelock_plus 1.8.1 changes only its dbus dependency, and file_picker_linux is file_picker's Linux implementation. Changelogs: file_picker, 11.0.3 to 13.1.0: https://pub.dev/packages/file_picker/changelog#1310 file_picker_darwin, new dependency at 2.3.2: https://pub.dev/packages/file_picker_darwin/changelog android_file_picker, new dependency at 2.1.1: https://pub.dev/packages/android_file_picker/changelog file_picker_platform_interface, new dependency at 4.2.0: https://pub.dev/packages/file_picker_platform_interface/changelog share_plus, 12.0.2 to 13.3.1: https://pub.dev/packages/share_plus/changelog#1331 share_plus_platform_interface, 6.1.0 to 7.2.0: https://pub.dev/packages/share_plus_platform_interface/changelog#720 package_info_plus, 9.0.1 to 10.2.2: https://pub.dev/packages/package_info_plus/changelog#1022 device_info_plus, 12.4.0 to 13.3.0: https://pub.dev/packages/device_info_plus/changelog#1330 wakelock_plus, 1.5.2 to 1.8.0: https://pub.dev/packages/wakelock_plus/changelog#180 The list leaves out the other plugins' platform-interface packages, and packages used only on web, Windows, or Linux: file_picker_web, windows_file_picker, file_picker_linux, and win32 and what it uses. Behavior changes, iOS, "Attach files" button: - When none of the picked files can be loaded, we now show an error dialog, with the message "PlatformException(load_failed, None of the picked items could be loaded., null, null)". file_picker 11 returned an empty list then, so nothing happened. (The next commit gives the dialog a translated message, without the "PlatformException(...)" clutter.) Behavior changes, iOS, "Attach images or videos" button: - When none of the picked photos or videos can be loaded, the error dialog's message changes: - Old: "PlatformException(file_picker_error, Failed to process any images/video, <a line per picked item>, null)" - New: "PlatformException(load_failed, None of the picked items could be loaded., null, null)" (The next commit replaces that with a translated message, without the "PlatformException(...)" clutter.) - When the user picks multiple photos or videos, they're inserted in the order of the photo picker's result list. file_picker 11 inserted them in whatever order they finished loading. - Picked photos and videos keep the file name iOS gives them, such as `IMG_9329.heic`, instead of file_picker 11's `image_<UUID>_<timestamp>.heic` (zulip#2495). - file_picker 11 copied each picked photo or video into the app's Documents folder (`Documents/picked_images`), and never deleted the copies. file_picker 13 copies to the app's temporary folder instead. Copies left by file_picker 11 stay where they are. We should file an issue to get those cleaned up. Behavior changes, iOS, elsewhere: - On an iPad, the message action sheet's "Share" button now opens the share sheet, anchored at the center of the screen. With share_plus 12, it did nothing (zulip#2490). A later commit in this series updates the share_plus iPad TODO. Behavior changes, Android: - With the "Attach files" button, when the user picks several files and none of them can be read, we now show an error dialog, with the message "PlatformException(unknown_path, Failed to retrieve path., null, null)". file_picker 11 returned an empty list then, so nothing happened. (The next commit gives the dialog a translated message, without the "PlatformException(...)" clutter.) - If Android destroys the app's activity while the system file picker is open, android_file_picker now copies the picked files and saves them for `retrieveLostData()`. We don't call that, so the pick is still lost, as with file_picker 11, but the copies stay in the app's cache folder. (From reading the code.) - Otherwise, we found no changes in file_picker on our path (the "Attach files" button), from reading the code and a quick manual test on a device. - wakelock_plus changed what happens in an edge case, when the app has no Android activity attached (as while it's being destroyed): fluttercommunity/wakelock_plus#134 We're fairly sure that makes no noticeable difference for us. Code changes: - Our `pickFiles` binding follows file_picker 13's `pickFiles`: it returns a list, empty if the user cancelled, and always allows several files. Its `allowMultiple` and `withReadStream` parameters are removed, as file_picker 13 removed them. (Single-file selection now goes through a separate method, `pickFile`.) The binding also takes `darwinOptions`, so the compose box can pass the two options below, and tests can check them. - Pass `assetRepresentationMode: current` and `orderedSelection: false` (see code comments), to keep some iOS photo picker settings unchanged from file_picker 11. These are done mainly to avoid changing behavior in this upgrade; they aren't settled product decisions. - List file_picker_darwin and android_file_picker in pubspec.yaml, for their minimum versions; see the comments there. Upstream fixes: while preparing this upgrade, we found these regressions from file_picker 11 and reported them, and the maintainers fixed them. This commit takes the fixed versions, so the upgrade doesn't bring them: vicajilau/flutter_file_picker#2243 vicajilau/flutter_file_picker#2248 vicajilau/flutter_file_picker#2259 vicajilau/flutter_file_picker#2260 vicajilau/flutter_file_picker#2261 We also reported a bug in `AndroidSAFOptions`, an API new since file_picker 11 that we don't use. It's fixed too: vicajilau/flutter_file_picker#2257 And we suggested Pigeon, as well as typed, documented error codes: vicajilau/flutter_file_picker#2258 vicajilau/flutter_file_picker#2262 Related: zulip#855 Co-Authored-By: Claude Sonnet 5.5 <[email protected]> Co-Authored-By: Claude Opus 5.5 <[email protected]>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
…akelock.toggle()/isEnabled() threw NoActivityException whenever they were called with no foreground activity attached (e.g. the app is backgrounded or mid lifecycle transition), surfacing as non-fatal crashes in apps that toggle the wakelock off the foreground path. Instead of throwing, the requested wakelock state is now tracked in Kotlin and re-applied once an activity (re)attaches — matching how the Windows/Linux/web implementations track state. The activity setter only re-asserts FLAG_KEEP_SCREEN_ON when wakelock was actually enabled, so it won't clear the flag for apps that set it on their own window. The now-unused NoActivityException class is removed. Bumps wakelock_plus to 1.6.2 and updates the CHANGELOG. Fixes #131, #102, #6.
fix(android): defer wakelock toggle when no activity is attached
Wakelock.toggle()/isEnabled() threw NoActivityException whenever they
were called with no foreground activity attached (e.g. the app is
backgrounded or mid lifecycle transition), surfacing as non-fatal
crashes in apps that toggle the wakelock off the foreground path.
Instead of throwing, the requested wakelock state is now tracked in
Kotlin and re-applied once an activity (re)attaches — matching how the
Windows/Linux/web implementations track state. The activity setter only
re-asserts FLAG_KEEP_SCREEN_ON when wakelock was actually enabled, so it
won't clear the flag for apps that set it on their own window. The
now-unused NoActivityException class is removed.
Bumps wakelock_plus to 1.6.2 and updates the CHANGELOG.
Fixes #131, #102, #6.