We need to figure out what the desired state is here.  There are valid use cases for audio continuing to play on the lock screen (listening to music for example)

The key issue here is that the device went to sleep and stopped audio and then resumed while the device was still in the lock state leading to surprise audio playback from a locked session.

My thinking is that we should respect Android's on-suspense mechanism and only continue playback on lock screen if app requests playback on visible behind[1]
[1] https://developer.android.com/training/tv/playback/options.html

Similarly to how we're moving Camera to be disabled on screen lock.

As an aside, I noticed the following behavior with the ARC++ Netflix app:

1) Play video, lock screen via systray menu - can continue to hear audio in the background
2) Play video, close lid - no audio when I open the lid, unlocking the device shows the netflix app with a paused video

Definitely would be nice to have similar behavior for audio/video streams in web content as well.

Good point that playing music through the lock screen can be a valid use case.

Thanks Drew for reporting this! I agree that it may be surprising for users that audio starts to play when they open the lid after sleep. Imho the behavior that you describe for ARC++ Netflix would be the desirable one.

(It's probably a different story when the user has disabled the lock screen and opening the lid directly continues the session. In that case I'd say that it would be most natural for audio/video to continue playing.)

Missed this somehow, will investigate desired behavior across web and apps.

Not sure how this is related to OOBE, and let's please keep the bug at a relevant priority. I don't want to keep that issue unresolved forever.

[bulk edit] Moving OOBE/Login bugs to Jesse

Here is some of the privacy team's thoughts on how to approach the problem.
go/lockscreen-audio-problem