Repository navigation
[BUG]: MediaPlayer can block the main thread (cause of ANR) #5650
Description
Activity
Note that this seems likely to be a bug in
MediaPlayeritself (or some very complex interaction I'm not sure I fully understand) since it's a deadlock produce across the main thread (during fragment exit) and the media player's thread that's trying to download the audio source. It's quite possible we're doing something wrong in a callback (I haven't analyzed the code in detail to see if that's the case).- added this to the 0.15 Release Blockers (Beta "Early Access") milestone
on Jan 16, 2025 - modified the milestones: 0.15 Release Blockers (Beta "Early Access"), 0.16 Release Blockers (Beta "Early Access")
on Mar 13, 2025 - modified the milestones: 0.16 Release Blockers (Beta "Early Access"), 0.17 Release Blockers (Beta "Early Access")
on Sep 9, 2025 - removed this from the 0.17 Release Blockers (Beta "Early Access") milestone
on Nov 12, 2025 This isn't really a release blocker until GA (since we keep bumping it), but it is a priority issue so upping the impact given that it makes up a large number of ANR crashes (most).
Hii @BenHenning ,
I investigated the ANR described in this issue and considered an approach to ensure that potentially blocking MediaPlayer operations do not run on the main thread.The idea is to move MediaPlayer interactions in
AudioPlayerController(such asrelease(),reset(),start(),pause(), andseekTo()) to the injected@BackgroundDispatcher. Since this change affects core playback behavior, the new behavior could be gated behind a feature flag (BACKGROUND_MEDIA_PLAYER) so the existing synchronous implementation remains the default.When the feature flag is enabled:
- MediaPlayer operations would be dispatched to the background dispatcher to avoid blocking the main thread.
- Existing synchronization (
audioLock) would be preserved to maintain thread safety.
When the flag is disabled:
- The current synchronous behavior would remain unchanged.
This would also require adding the corresponding feature flag wiring (proto definition, bindings, constants, and configuration) following the existing feature flag patterns used in the project.
Does this approach align with the intended direction for fixing the ANR? If so, could I please be assigned to work on this issue?
@harshsomankar123-tech the current assumption is that #2430 will need to be addressed to fix this. The idea of pushing this to a background thread could work (and may be ideal), but there are some gotchas to ensure that the threads actually are set up the way the player expects. We were assuming that we'd need to use a coroutine
actorto synchronize access to the player (since technically using a lock with the background dispatchers is likely to cause other problems).However, it seems like it may be possible to use
ExoPlayer(haven't looked into this, and I'm not sure if @adhiamboperes has either).@adhiamboperes I defer to you on whether this issue should be available to work on since I'm assuming this will be covered as part of your planned audio work.
Reacted by Harsh SomankarI recently filed #6446 which I now realize is a duplicate of this one. I will keep the newer issue open since it has more information, but I have added a link to this issue so that context isn't lost.
From the investigations into #6446, this issues is quite complex as reviewing #6464 has shown. It is not easy to fix this without doing a full refactor of the audio player architecture.
Describe the bug
It seems that Android's
MediaPlayerperforms some blocking operations that, when interacted with on the main thread, can cause ANRs in certain conditions.Sample from the Play Console:
(Note that other thread stack traces have been removed for brevity since the main thread's stack trace seems sufficiently detailed to figure out what's going on here).
Steps To Reproduce
Unknown since this is an ANR reported by Android.
Expected Behavior
We should avoid avoidable ANRs.
Screenshots/Videos
No response
What device/emulator are you using?
Redmi Fire (Redmi 12)
Which Android version is your device/emulator running?
SDK 33
Which version of the Oppia Android app are you using?
0.14-beta-17f2ef3044
Additional Context
Note that this probably relates to #2430. It seems that per
MediaPlayer's documentation that it doesn't require use on the main thread (though it's important to realize that its callbacks default to the main thread unless specifically configured to use a different handler/looper). I suspect that an ideal solution here may be to move all media player interactions to a background controller and have it liaise with the frontend using data providers (much in the same way that we do for other controllers in the app). We may need a mixin configuration (similar to that use for app language) to ensure that the controller is properly notified of lifecycle events for pausing/resuming/starting/stopping the media.Note that this solution also will allow other classes of issues to be fixed (including preserving play location across configuration changes).
Due to the sensitivity of media player, we should gate this fix behind a feature flag for thorough testing.