I found this issue when I tried to re-use a view in RecyclerView.
And it looks similar to this issue - #1278

disable release/initialize player on stop/start the activity (from sample)

First of all, this particular step is not something you should do in a real app because keeping the player (and the codec in particular) while the app is in background may cause unexpected side effects. I understand that you originally reproduced this in RecyclerView, so I appreciate this is just a test setup.

progress of the still screen appears to change in milliseconds

I was not able to reproduce this on my device by using the pause button in the UI, but I think I can reproduce it by calling player.pause() from within Activity.onStop().

The problem may be caused by two different effects:

1. The video surface is disconnected and reconnected. When the new surface is connected, it cannot receive any previously decoded frames and will instead receive the next available frame.
2. Depending on the timing of the pause operation, you may also see one or two scheduled frame releases that can't be cancelled even during a pause operation. So when you come back, the preview (a kind of screenshot taken by the system when you left) may be slightly different from the one when coming back to it.

Thanks for your explanation.
And I totally understand your concern( keeping the player (and the codec in particular) while the app is in background may cause unexpected side effects)
I think, this is not a practical problem, as users typically do not perform the same action repeatedly.

But my service has a requirement which is focused on visibility not on performance.
Because there is flicker of screen when I release and initialize the player.
(The screen is black while the player load media file.)
So isn't this supposed to be fixed? I mean, should I explain to my team member that this is not a problem.

So isn't this supposed to be fixed?

Could you highlight what exactly you are trying to achieve? There may be alternatives to your current usage pattern.

But generally, the way codecs work is that they release frames to a surface and there is no way to get the last released frame back again. To avoid this, you need to either recreate the codec or not destroy the surface:

• New codec, new (or same) surface -> some initial delay during set up, but can start with the previous frame precisely. This is what the Media3 demo is doing by default.
• Same codec, new surface -> current test setup as described above, can only release the next frame
• Same codec, same surface -> keeps content, but there is no guarantee you can keep the surface. Surfaces are automatically destroyed when the Activity is stopped or they are no longer connected to the view hierarchy. If you handle them in RecyclerView, you may be able to move an existing Surface to an out-of-screen position while you don't need it, or you try SurfaceControl to reparent an exiting Surface in another View.

The screen is black while the player load media file

The typical solution to this is to show a placeholder image. You may be able to achieve this by using TextureView and then call getBitmap when the surface is destroyed. Or preferably, you can start preparing the output early enough so that it's already ready when it comes into view.

Thank you, you already suggested alternative solution for me.
Actually I wanted to keep the surface even if it was disconnected from the view hierarchy.
I used "TextureView" and the "TextureView" was destroyed when detached from window (as you mentioned)
I think "SurfaceControl" or "Placeholder image"(from "getBitmap") can be a solution.