Skip to content

Fix/cast wake on sleep - #6005

Open
GhaziTrueAlpha wants to merge 2 commits into
yuliskov:masterfrom
GhaziTrueAlpha:fix/cast-wake-on-sleep
Open

Fix/cast wake on sleep#6005
GhaziTrueAlpha wants to merge 2 commits into
yuliskov:masterfrom
GhaziTrueAlpha:fix/cast-wake-on-sleep

Conversation

@GhaziTrueAlpha

Copy link
Copy Markdown

No description provided.

Root cause: Android 14's "Low Power Standby" feature cuts network
access for the app while the TV is asleep unless it's on a small
hardcoded OS allowlist that SmartTube isn't part of. No app-level fix
can override this; it requires disabling the feature at the OS level
(see WAKE_ON_CAST_FIX.md for the exact adb commands and a wireless-adb
setup walkthrough).

Also fixes several real bugs found along the way that are necessary
once network access is restored:
- Utils.turnScreenOn() was a no-op when called with an Application
  context (which ViewManager always did) since it only acted on
  Activity contexts; added wakeUpScreen() (real PowerManager wake lock,
  works from any context) and wakeUpAndOpenActivity() (full-screen-
  intent notification, not subject to background-activity-launch
  grace-period restrictions).
- RemoteControlService now holds a partial wake lock for its lifetime
  so the background cast connection survives screen-off.
- SplashPresenter now actually requests the battery-optimization and
  overlay-permission exemptions at runtime (declaring them in the
  manifest alone doesn't grant them).
- PlaybackActivity.onResume() also dismisses the keyguard with a real
  Activity context as a backup path.

MediaServiceCore submodule (forked, see .gitmodules) also gets a fix
for a tight zero-backoff retry loop in LoungeService's reconnect logic
that would busy-loop retrying DNS every ~10ms after the TV woke up,
instead of giving the network a moment to recover.
RemoteControlReceiver already listens for boot broadcasts to restart
the background cast service; now it also brings the app to the
foreground on genuine boot actions (BOOT_COMPLETED, QUICKBOOT_POWERON,
LOCKED_BOOT_COMPLETED), not on the other actions it listens to like
SCREEN_ON/TIME_SET which would be too aggressive. Relies on the
SYSTEM_ALERT_WINDOW background-activity-start exemption already in
place.
@GhaziTrueAlpha

Copy link
Copy Markdown
Author

done

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant