Open jasoncfpl opened 1 year ago
This is unfortunately something to be expect on some devices or devices with high load.
When the build()
call is made a StreamVolumeManager
will be created that will directly try to read audioManager
to get current volume. Since this requires a bind call that is blocking, this can and will ANR sometimes.
See the Play Store explanation for those kind of issues:
Since ExoPlayer recommend using main thread this is somewhat expected that most will create the player in main thread too.
You can mitigate this by creating the player in a background thread and use setLooper
to set the proper main thread looper.
We're closing this issue because there hasn't been any recent activity.
@rohitjoins This is certainly to be considered a bug of ExoPlayer....
You are doing an IPC blocking call on init of the StreamVolumeManager
this should not be done and is an error that should be addressed. The workaround to init ExoPlayer in the background is a workaround and is not documented anywhere as recommended so people are facing this in prod.
Hi! We are experiencing hundreds of such anrs per month. Are there any plans on it?
Bug
android.os.BinderProxy.transactNative(Native Method) android.os.BinderProxy.transact(BinderProxy.java:610) android.media.IAudioService$Stub$Proxy.getStreamVolume(IAudioService.java:4565) android.media.AudioManager.getStreamVolume(AudioManager.java:1210) com.google.android.exoplayer2.StreamVolumeManager.getVolumeFromManager(StreamVolumeManager.java:1) com.google.android.exoplayer2.StreamVolumeManager.(StreamVolumeManager.java:8)
com.google.android.exoplayer2.SimpleExoPlayer.(SimpleExoPlayer.java:60)
com.google.android.exoplayer2.SimpleExoPlayer$Builder.build(SimpleExoPlayer.java:3)
io.flutter.plugins.videoplayer.VideoPlayer.(VideoPlayer.java:7)
io.flutter.plugins.videoplayer.VideoPlayerPlugin.create(VideoPlayerPlugin.java:16)