You can see what is meant by "stability" here in the README and UnstableAPI java doc.

In short: it doesn't have to do with quality or performance. You can assume the functions and classes behave as documented. However, the library is not ready to freeze these APIs and commit to long-term backwards compatibility. So use with caution to avoid breaking changes when upgrading the library version.

Okay so if you are saying those can be removed then can we have stable version of the same example if possible?

Stabilising the API is a lengthy process and the full ExoPlayer/media3 API (everything accessible by an application developer like you) is too large to guarantee this kind of stability. We want to be sure that everything we add to the stable API is worth the long-term investment of the team supporting it. There is a trade-off between freezing the APIs too early and allowing the flexible experimental setup like this to evolve over time to something better.

When ExoPlayer moved to the androidx.media3 package, it went through a stabilising stage. We became a part of AndroidX libraries and hence we now adhere to backward-compatibility guarantees between minor versions.

When we do promote APIs to stable, it is announced in the release notes.

If you think your particular use-case cannot be achieved using the stable API only, you could file an issue about stabilising those components. However, looking at the list of classes you pasted: DemoUtil is utility methods for the main demo, DownloadTracker and TrackSelectionDialog are also just examples of how to achieve certain functionality. You are free to copy it over to your project and customize according to your needs. The library as a whole does not rely on these classes.

Okay the list of features I am trying to achieve are download track, quality control, speed control etc. I copied it over since the same code was used in exoplayer2 to do the same and it used to work fine since many years and even the sample app has the same code as of now

I copied it over since the same code was used in exoplayer2 to do the same and it used to work fine since many years and even the sample app has the same code as of now

To be clear, nothing has got 'less stable' than in exoplayer2. Just some bits of media3 are now marked as 'more stable' than anything ever was in exoplayer2. You can see more info here: https://developer.android.com/media/media3/exoplayer/migration-guide#background

So if you were happy using the symbols in the exoplayer2 package you should be fine to continue using the same symbols in the media3 package, regardless of whether they're annotated @UnstableApi, and adding @OptIn or suppressing the lint.