New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Backward compatibility issue since version 2.5.x #3680

EvanHong1 opened this Issue Jan 8, 2018 · 2 comments


None yet
2 participants
Copy link

EvanHong1 commented Jan 8, 2018

My app has dependency of my own library module published in maven repo, which includes Exoplayer r2.4.3 dependency.
And when I try to update version to r2.5.0, Error occurs as below:

java.lang.NoSuchMethodError: No virtual method addListener(Lcom/google/android/exoplayer2/ExoPlayer$EventListener;)V in class Lcom/google/android/exoplayer2/SimpleExoPlayer; or its super classes (declaration of ''

So It means there is backward compatibility issue since 2.5.x.

And I need to add another dependency which has Exoplayer r2.0.3 dependency.(ex:Facebook Audience Network SDK)
So I want to resolve dependency conflict by forcing every module to use r2.4.3.
But how can I assure that r2.4.3 I'm using currently is backward compatible with r2.0.3
when it is not in r2.5.0??

Is there any way to know which version is the latest version that can assure backward compatibility??

@EvanHong1 EvanHong1 changed the title Exoplayer2 backward compatibility issue since version 2.5.x Backward compatibility issue since version 2.5.x Jan 8, 2018


This comment has been minimized.

Copy link

EvanHong1 commented Jan 11, 2018

Could anyone answer this?

@ojw28 ojw28 self-assigned this Jan 11, 2018

@ojw28 ojw28 added the question label Jan 15, 2018


This comment has been minimized.

Copy link

ojw28 commented Jan 15, 2018

We don't have a great answer for this, unfortunately, since we do not currently guarantee API stability even between minor versions.

In most cases ExoPlayer is intended to be used by apps directly, in which case this isn't a problem because the app developer can simply pick their preferred version. The problem arises when libraries depend on ExoPlayer. This forces an app using such a library to use the same version of ExoPlayer as the library uses. If an app wants to use two libraries, both of which depend on different versions of ExoPlayer, then that becomes tricky to resolve.

We recommend that library developers who wish to use ExoPlayer do so by building it directly into their library with an obfuscated package name, rather than having a dependency. This allows both the library and app to keep their own separate versions at the cost of increased binary size, but since ExoPlayer is small (particularly after proguarding) the increase isn't particularly large. The Google VR SDK is an example of a library that internalizes ExoPlayer in this way. The Facebook Audience Network SDK should probably do the same thing, so I'd suggest you raise an issue with the developers at Facebook requesting that they do this.

Whether we revisit this in the future depends largely on how many libraries are using ExoPlayer, since this is the problematic case. We're aware that the solution isn't ideal, and so if we start seeing widespread usage by libraries we'll probably reconsider.

@ojw28 ojw28 closed this Feb 26, 2018

@google google locked and limited conversation to collaborators Jun 29, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.