ANR when stopping stream on some devices due to blocking codec/camera/GL teardown

[anilateapp]

Describe the bug
On some devices, stopping an active stream can block long enough to freeze the UI and trigger ANR.

This does not appear to be related to stream connection or encoder selection. The issue seems to happen during the stop/release path, when the library is tearing down codec, camera, and GL resources.

In practice:

• stream starts and runs normally
• user presses Stop
• UI may freeze for several seconds
• in some cases this results in ANR

This looks like a lifecycle / teardown problem rather than a connection problem.

To Reproduce

1. Start an RTMP stream on the affected device (Tecno spark 30c - HiOS v14.5.0)
2. Wait until the stream is running normally
3. Stop the stream
4. Observe that the app may freeze during stop
5. In some cases Android reports ANR

Expected behavior
Stopping a stream should return control to the UI quickly and should not block long enough to trigger ANR.

Screenshots
N/A

Smartphone (please complete the following information):

• Library version: 2.7.1
• Device: [your device model here]
• OS: [your Android version here]
• Media server: [your RTMP server here]
• Class used: GenericStream

Additional context
From local investigation, the freeze seems to be caused by blocking operations during teardown, including one or more of:

• MediaCodec.start()/flush()/stop()/release()
• camera open/close callbacks
• encoder EGL surface add/remove
• stream stop being executed from the UI path

What helped locally:

• moving stream operations off the main thread
• adding timeout protection around blocking MediaCodec operations
• running encoder EGL surface add/remove on the GL executor thread
• guarding Camera2 open/close flow against stale or delayed callbacks

So far I am reporting this separately from the secure AVC encoder issue, because this seems to be a broader stop/lifecycle robustness problem.

[pedroSG94]

Hello,

I was looking in the code but I already have code to avoid block the thread forever in GlStreamInterface/OpenGlView, VideoEncoder, AudioEncoder and stream start/stop methods.
If you find an ANR and you can share the log error I will investigate in that way further.

You already can use the library using a background thread without problems to avoid block the UI thread like this:

• Using executors:

private val executor = Executors.newSingleThreadExecutor()

    executor.submit {
      //Use library code here. This guarantee use always the same thread with the library
    }

• Using coroutines:

  private val dispatcher = Executors.newSingleThreadExecutor().asCoroutineDispatcher()

    CoroutineScope(dispatcher).launch {
      //Use library code here. This guarantee use always the same thread with the library
    }

[anilateapp]

It's good that I saved it

anr.txt

[pedroSG94]

I think that this ANR was caused because removeMediaCodecSurface was called while a frame is rendering.
I did a fix to avoid that here:
01007e3

[anilateapp]

I can't say for sure
Since initially I decided to ANR but the stream did not start
Afterwards the *.secure order was corrected and everything worked
Therefore, I cannot know for sure whether *.secure could issue or influence ANR

Or just so unique Tecno

[anilateapp]

@pedroSG94 What time will the new release be published?

[pedroSG94]

Hello,

I uploaded a new release today with the fixes included. Try version 2.7.2