ExoPlayer vs Native MediaCodec Buffer Management on Low-Memory Android TV Devices

Working on media streaming pipelines across budget Android TV hardware (such as Amlogic S905W2/Y4 and Realtek RTD SoCs with 1.5GB to 2GB RAM commonly found in Indian smart TVs like Xiaomi, Realme, and Thomson) reveals a consistent architectural challenge: buffer allocation spikes causing Android LowMemoryKiller (LMK) to drop background tasks or trigger micro-stutter during high-bitrate 4K HEVC/AV1 playback.

When analyzing media playback pipelines:

1. Google ExoPlayer / AndroidX Media3: Excellent adaptive bitrate (HLS / DASH) switching and chunk-based caching, but the default DefaultLoadControl allocates significant heap headroom unless explicitly tuned with tight buffer constraints (minBufferMs, maxBufferMs, and low bufferForPlaybackMs).

2. Direct MediaCodec Surface Rendering: Pipes hardware decoder output directly to the display HAL surface, bypassing Java heap overhead and keeping the memory footprint consistently below 120MB.

3. Client Architecture Impact: Players that rely on lean, native layouts (such as SmartTube, Nova Video Player, or VelaTV) manage to sustain smooth 4K 60fps streaming on low-RAM devices by relying strictly on hardware-accelerated decoders and avoiding heavyweight web-view wrappers.

For engineers optimizing video streaming clients for low-RAM connected TVs in India: what strategies do you implement for tuning socket buffers and read timeouts to mitigate last-mile ISP jitter without triggering heap exhaustion?