Wakelock for shorts is broken on android

[mulundapm]

For shorts that are opened from sections in homepage

[sifferhans]

https://github.com/bcc-code/bcc-media-app/pull/465

[mulundapm]

Short reloads in the middle of the short and wakelock is disabled after that. This happen often on the first short on launch.

[sifferhans]

The current logic checks each render if the active route is the short_scroll_view screen

• if the current route is the short_scroll_view, enable wake-lock
• if the current route is not the short_scroll_view, and the previous route was, disable wake-lock.
  This is to make sure we disable wake-lock when navigating away from shorts screen

The bug happens when you navigate from the shorts screen on the homepage, to the shorts screen tab; you technically navigate away from a shorts screen, so it disables wake-lock

There is basically a race condition as both shorts screens enable/disable wake-lock at the same time

The solution here is probably to share some state or something

[sifferhans]

I ended up using a simple counter to keep track of screens requiring the wakelock to be enabled

[sifferhans]

Should be tested in version 5.6.37

[KillerX]

Not fixed for me on 5.6.37+2300197

[sifferhans]

@KillerX Do you have reproduction steps to trigger the bug?

[KillerX]

Just reproduced in the most straingforward manner:

Open app, Scroll down, Open short 🤷

[sifferhans]

The quick "flash" we see before the wakelock turns off seems to be because the short is buffering. Need to validate that to be 100% sure, but we only show the loading spinner either when the video initializes or buffers.

If that is the case, the buffering somehow disables the wakelock

[sifferhans]

The stretched image appearing could be because the player stops, but the current MediaItem is not removed from the player. I can reproduce the stretched state by calling the stop method on the player:

shortController.player.stop(reset: false)

It could also be caused by this bug: https://github.com/androidx/media/issues/1237