I swapped audio tracks mid-movie without a rebuffer. Here is how my 1.17 MB player does it

Indian releases now ship four or five audio languages on the same stream. Telugu original, Hindi dub, Tamil dub, sometimes Kannada and Malayalam too. The stock players pick one at start, and if you switch, half the time the video re-seeks and re-buffers. So people just stay on the wrong dub.

My player is 1.17 MB on Android and runs on the system MediaPlayer, so there was no library to lean on. The trick turned out to be boring: never tear the player down.

What I actually do:

1. After prepare, I read player.getTrackInfo() once. It returns every track with its type and language, so I filter TRACK_TYPE_AUDIO and build a small picker from getLanguage().
2. Switching is just selectTrack(index) on the same player instance. The video track stays selected, the decoder never restarts, and there is no rebuffer. On a 2 GB Moto G Play the swap lands in under 300 ms with no seek-bar jump.
3. The catch: some OEM players still stall briefly when the audio renderer re-inits. So I keep the old audio track selected until the new one is live, then deselect it. Ugly, but it hides the hiccup.
4. UI is a bottom sheet listing the languages with the active one ticked. No settings maze.

I measured cold start to first frame against audio-switch latency on the same file. The switch is consistently 5-10x faster than a re-seek, and RAM stays flat because nothing new gets allocated.

The whole audio layer is maybe 200 lines. That is the point of keeping the APK at 1.17 MB: every feature has to justify its bytes, and track switching earns its keep because multi-audio releases are the norm now, not the exception.

Disclosure: I build RKMovies, an ultra-lightweight 4K player client for Android and Windows (1.17 MB APK, 29.5 MB installer, hardware decode, multi-audio, WebVTT subs, no account, zero telemetry). More here: the project homepage, the sideload apk page, the windows download page.