Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Remove the main thread restriction of `AdsMediaSource`

Open
  • Is something wrong?
#3,380 1 comment 0 reactions 1 assignee View on GitHub

Maintainers usually reply within 4 days

@marcbaechinger is already working on this.

Since Aug 18, 2026.

Assessment

This issue has not been assessed yet.

Description

enhancement
Version

Media3 1.11.0

Description

AdsMediaSource drives its AdsLoader callbacks (start(), stop(), handlePrepareComplete(), handlePrepareError()) through a Handler hardcoded to Looper.getMainLooper():

// AdsMediaSource constructor
mainHandler = new Handler(Looper.getMainLooper());
// releaseSourceInternal()
mainHandler.post(() -> adsLoader.stop(/* adsMediaSource= */ this, componentListener));

But ExoPlayer.Builder.setLooper(Looper) documents a different thread as the one the player expects to be used for all calls:

Sets the Looper that must be used for all calls to the player and that is used to call listeners on.

and ExoPlayerImpl's public API enforces exactly that looper via verifyApplicationThread(), e.g. in removeListener():

public void removeListener(Listener listener) {
  verifyApplicationThread(); // throws if Thread.currentThread() != getApplicationLooper().getThread()
  listeners.remove(checkNotNull(listener));
}

When an app builds its player with a non-default looper via setLooper(...) — a documented, supported way to keep player calls off the main thread — these two "the thread you're supposed to touch the player on" notions diverge. Any AdsLoader whose stop() calls player.removeListener(...) (the natural, symmetric counterpart to an addListener() in start()) will crash:

java.lang.IllegalStateException: Player is accessed on the wrong thread.
Current thread: 'main'
Expected thread: ''

Root cause
AdsMediaSource.mainHandler is unconditionally new Handler(Looper.getMainLooper()) — both in the current release and on main, unchanged across multiple major versions.
addListener() is documented and implemented to be safe from any thread (no verifyApplicationThread() call), which hides the mismatch during start().
removeListener() does call verifyApplicationThread(), so it's the first place the mismatch surfaces — but it's a symptom, not the cause: any thread-checked Player/ExoPlayer method called from code AdsMediaSource dispatches (start, stop, handlePrepareComplete, handlePrepareError) has the same exposure.

Devices that reproduce the issue

Was reproduced on a proprietary Android device.

Reproducible in the demo app?

No

Reproduction steps
  1. Build a player with a non-default looper: new ExoPlayer.Builder(context, ...).setLooper(customLooper).build(), where customLooper belongs to a dedicated thread, not the main thread.
  2. Wrap a MediaSource with HlsInterstitialsAdsLoader.AdsMediaSourceFactory (or any other AdsMediaSource-based AdsLoader) and play an HLS stream containing #EXT-X-DATERANGE interstitials.
  3. Once at least one ad group has started — AdsMediaSource has called adsLoader.start(), which calls player.addListener(...); this succeeds silently because addListener isn't thread-checked — stop playback, release the source, or switch media items, so AdsMediaSource.releaseSourceInternal() runs.
  4. Observe the crash when HlsInterstitialsAdsLoader.stop() calls player.removeListener(...).
Expected result

AdsMediaSource should dispatch to the player's actual getApplicationLooper() rather than a hardcoded Looper.getMainLooper(), so AdsLoader callbacks are safe to call any Player method from — matching the contract setLooper() establishes everywhere else in the library.

Actual result

An exception in HlsInterstitialsAdsLoader.stop()

Dominant language
Java
Stars
3.1k
Forks
998
Avg merge
6d 8h
Merged PRs (30d)
2

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from androidx/media

All issues in androidx/media

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.