This issue is duplicated from ID 318288736 due to no further response, so we raise same issue again to try to get any answer.

Dear Google development teams,

Platform: Android 14 AOSP (android-14.0.0_r11) at TV platform, kernel version: 5.15

What happened:
Device composition may be triggered by SurfaceFlinger under the media tunneling flow, hence hwcomposer is confused with the layer composition change from sideband composition to device composition.

How to reproduce:
Please refer to this commit: https://cs.android.com/android/_/android/platform/frameworks/native/+/9691b9c07fe135b3bd1ea5375daf9aa57ec3b797
This issue can be reproduced after switching playback from non-tunneling mode to tunneling mode with same SurfaceView.
For non-tunneling mode, each buffer to be rendered is sent from MediaCodec to SurfaceFlinger, then would be kept in Layer of SurfaceFlinger (https://cs.android.com/android/_/android/platform/frameworks/native/+/main:services/surfaceflinger/Layer.cpp;l=3145) and be transferred to hwcomposer to be displayed.
After switching to tunneling mode with same SurfaceView, Layer still exists and is added with a sideband stream, but the last buffer of the previous playback of device composition remains at Layer. The commit above would lead to a change of composition type of Layer from sideband to device during the playback of media tunneling. We're in doubt with this flow and cannot accurately judge the current playback shall be tunneling or not from hwcomposer.

Expected behavior: As the playback of device composition is ended or to be switched to media tunneling, Layer of SurfaceFlinger shall not keep the buffer after disconnectFromSurface() is called from MediaCodec. Therefore if Layer is re-used for the subsequent tunneling playback, the flow with sidebandStreamHasFrame would not be entered, and the playback of media tunneling would not go into device composition.

Issue 380913918

Links (2)

Issue metadata