Labels: bug, reliability, android, priority: high
Summary
The README's "Release Checks" section explicitly lists "repeated player open/close" as a required smoke test:
"Smoke-test startup, profile switching, playback, stream fallback, subtitle/audio switching, IPTV/EPG loading, addon add/remove, search, settings navigation, background sync, and repeated player open/close on the supported device classes."
Calling out "repeated player open/close" specifically — rather than just "playback" — strongly signals that this scenario has historically surfaced bugs, most likely an ExoPlayer/Media3 SimpleExoPlayer or ExoPlayer instance that is not properly released (player.release()) when the hosting Fragment or Activity is destroyed, causing: leaked AudioFocus, WakeLock held after screen-off, SurfaceView still attached to a released player, and eventual OOM on low-memory Android TV devices after repeated navigation.
On Android TV specifically, this is more severe than on phones: the back stack is deeper, users return to the home screen without necessarily destroying activities, and background memory pressure is higher since the launcher, EPG, and system services all compete for the same RAM budget.
Proposed solution
- Add an automated
PlayerLifecycleTest in app/src/androidTest/ using ActivityScenario that: creates the player screen, starts playback, navigates away (simulating back press), navigates back, and asserts: (a) no ExoPlayer instance is retained in memory after navigation away (via WeakReference check), and (b) AudioManager.AUDIOFOCUS_LOSS is correctly handled.
- If a
PlayerViewModel or equivalent holds the player instance, verify it calls player.release() in onCleared() and that this is covered by a unit test.
- Add a
LeakCanary dependency (debug variant only — it's already a standard Android debug tool and adds zero production overhead) to surface any Activity/Fragment leaks automatically during development and CI.
I'd like to be assigned this issue. I'd start by confirming the current player release path in app/ then write the lifecycle test and add LeakCanary to the debug build variant.
Labels: bug, reliability, android, priority: high
Summary
The README's "Release Checks" section explicitly lists "repeated player open/close" as a required smoke test:
Calling out "repeated player open/close" specifically — rather than just "playback" — strongly signals that this scenario has historically surfaced bugs, most likely an
ExoPlayer/Media3SimpleExoPlayerorExoPlayerinstance that is not properly released (player.release()) when the hostingFragmentorActivityis destroyed, causing: leakedAudioFocus,WakeLockheld after screen-off,SurfaceViewstill attached to a released player, and eventual OOM on low-memory Android TV devices after repeated navigation.On Android TV specifically, this is more severe than on phones: the back stack is deeper, users return to the home screen without necessarily destroying activities, and background memory pressure is higher since the launcher, EPG, and system services all compete for the same RAM budget.
Proposed solution
PlayerLifecycleTestinapp/src/androidTest/usingActivityScenariothat: creates the player screen, starts playback, navigates away (simulating back press), navigates back, and asserts: (a) noExoPlayerinstance is retained in memory after navigation away (viaWeakReferencecheck), and (b)AudioManager.AUDIOFOCUS_LOSSis correctly handled.PlayerViewModelor equivalent holds the player instance, verify it callsplayer.release()inonCleared()and that this is covered by a unit test.LeakCanarydependency (debug variant only — it's already a standard Android debug tool and adds zero production overhead) to surface anyActivity/Fragmentleaks automatically during development and CI.I'd like to be assigned this issue. I'd start by confirming the current player release path in
app/then write the lifecycle test and add LeakCanary to the debug build variant.