fix(Android): Keep screen awake after returning to video playback from background - #1047
Merged
PartyDonut merged 2 commits intoAug 9, 2026
Conversation
On Android the keep-screen-on window flag (FLAG_KEEP_SCREEN_ON) is dropped across a background→foreground cycle, so the screen would sleep after the idle timeout while a video kept playing. The wakelock was only set in play() and cleared in pause() (set-and-forget), and the lifecycle resume handler meant to re-apply it was dead code: its `playing` flag was never set to true. Route the wakelock through a single idempotent path in MediaControlsWrapper driven by the actual player state (on when playing and not an AudioModel), and add reassertWakelock() which force re-applies it. Call it from AppLifecycleState.resumed so the flag is restored whenever the app returns to the foreground while playback continues.
aviadlevy
force-pushed
the
fix/android-screen-sleep-during-playback
branch
from
August 9, 2026 13:49
a3c8545 to
46ea3ff
Compare
PartyDonut
previously approved these changes
Aug 9, 2026
PartyDonut
left a comment
Collaborator
There was a problem hiding this comment.
Looks good to me and works fine. One small request to remove some comments.
Review feedback on DonutWare#1047: the helper names already say what they do, so the doc comments on _wakelockEnabled, _shouldKeepScreenOn and reassertWakelock were noise. Keeps only the note on _applyWakelock's force flag, since "re-apply even though the cached state matches" is not derivable from the code.
PartyDonut
approved these changes
Aug 9, 2026
PartyDonut
left a comment
Collaborator
There was a problem hiding this comment.
Thanks for the quick changes 👍
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.
Pull Request Description
Fixes the screen sleeping mid-playback on Android (see #1046 for the full repro and on-device evidence).
Root cause: screen-on relied on the
FLAG_KEEP_SCREEN_ONwindow flag toggled once inplay()/pause(). Android drops that flag across a background→foreground cycle and nothing re-applied it — the resume handler meant to recover it (if (playing) play()) was dead code, sinceplayingwas never settrue.Fix
media_control_wrapper.dart: route the wakelock through one idempotent path —_shouldKeepScreenOn(playing)(on when playing and not anAudioModel) applied via_applyWakelock(...), re-evaluated on every player state change instead of the scatteredWakelockPluscalls.reassertWakelock()which force-re-applies the flag (our cached state reads "on" after the OS clears it, so a plain reconcile would skip the re-apply).video_player.dart: removed the deadplayingflag; callreassertWakelock()onAppLifecycleState.resumed. Desktop/web stay excluded, as before.The same handler also had a dead
pause()-on-background branch (also gated on the never-trueplaying), which is removed too — behavior is unchanged, since playback already continued in the background. Wiring up actual background-pause would be a separate change.Scope
Native ExoPlayer path (Android TV) manages the flag separately in
ExoPlayer.ktand is out of scope. No new packages.AI assistance
Root-cause investigation and the patch were done with Claude Code; diagnosis, fix design, and on-device validation were human-reviewed and -owned.
Issue Being Fixed
Resolves #1046
Screenshots / Recordings
Tested On
LibMPV/WakelockPluspath as Android; not separately re-tested.Checklist