java.lang.AbstractMethodError with gradle version 3.5.3
See original GitHub issueI am using exoplayer version 2.11.1 with androidX ,java1.8 and gradle version 3.5.3. The crash appears after updating the gradle version to 3.5+. I am getting runtime crash below:
====================
E/AndroidRuntime: FATAL EXCEPTION: main
java.lang.AbstractMethodError: abstract method "void com.google.android.exoplayer2.Player$EventListener.onTimelineChanged(com.google.android.exoplayer2.Timeline, int)"
at com.google.android.exoplayer2.ExoPlayerImpl$PlaybackInfoUpdate.lambda$run$0$ExoPlayerImpl$PlaybackInfoUpdate(ExoPlayerImpl.java:804)
at com.google.android.exoplayer2.-$$Lambda$ExoPlayerImpl$PlaybackInfoUpdate$N_S5kRfhaRTAkH28P5luFgKnFjQ.invokeListener(Unknown Source:2)
at com.google.android.exoplayer2.BasePlayer$ListenerHolder.invoke(BasePlayer.java:182)
at com.google.android.exoplayer2.ExoPlayerImpl.invokeAll(ExoPlayerImpl.java:845)
at com.google.android.exoplayer2.ExoPlayerImpl.access$000(ExoPlayerImpl.java:43)
at com.google.android.exoplayer2.ExoPlayerImpl$PlaybackInfoUpdate.run(ExoPlayerImpl.java:802)
at com.google.android.exoplayer2.ExoPlayerImpl.notifyListeners(ExoPlayerImpl.java:736)
at com.google.android.exoplayer2.ExoPlayerImpl.updatePlaybackInfo(ExoPlayerImpl.java:710)
at com.google.android.exoplayer2.ExoPlayerImpl.handlePlaybackInfo(ExoPlayerImpl.java:652)
at com.google.android.exoplayer2.ExoPlayerImpl.handleEvent(ExoPlayerImpl.java:595)
at com.google.android.exoplayer2.ExoPlayerImpl$1.handleMessage(ExoPlayerImpl.java:127)
at android.os.Handler.dispatchMessage(Handler.java:107)
at android.os.Looper.loop(Looper.java:228)
at android.app.ActivityThread.main(ActivityThread.java:7726)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:492)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:993)
Issue Analytics
- State:
- Created 4 years ago
- Comments:15 (7 by maintainers)
Top Results From Across the Web
Gradle plugin 3.5.0 causes AbstractMethodError for release ...
lang.AbstractMethodError: abstract method "...." The error happens in combination with a java interface which has also a default method. With ...
Read more >Using default method raises AbstractMethorError in Android ...
FATAL EXCEPTION: main Process: my.package.name, PID: 4096 java.lang.AbstractMethodError: abstract method "void android.text.TextWatcher.
Read more >AbstractMethodError when calling interface provided as Java ...
I'm getting a java.lang.AbstractMethodError at runtime after updating to Android Gradle Plugin 3.4.1 (from 3.3.2). If I disable R8 via "android.
Read more >Gradle User Manual
Gradle is an open-source build automation tool focused on flexibility and performance. Gradle build scripts are written using a Groovy or Kotlin DSL....
Read more >Past releases - Android Developers
The Android Studio build system is based on Gradle, and the Android Gradle plugin adds several features that are specific to building Android...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I can reliably reproduce the problem with your setup. I think it still works as intended because you directly depend on the aar file and the problem goes away once you change the dependency to
implementation project(path: ':exolibrary-debug')
The underlying issue is that the aar file doesn’t contain any dependency declaration and that’s why the dexing step can’t resolve the methods successfully. According to the post linked above, full dependency declarations are required from 3.5.3 onwards.
To tell gradle about the dependencies, you need a pom file as published by Maven for example. If you were publishing your library to Maven and then include it directly from there (i.e. using the aar + the pom file), it probably works again. You could also try to use a local Maven repository including pom files, following the instructions here. I haven’t tried it because it’s no longer ExoPlayer related and we can’t provide support for generic gradle issues. Might be worth a try though.
Based on the above, I’ll close this issue as working as intended. It only occurs if you depend on an aar directly without full dependency declaration, so anyone depending on ExoPlayer through the normal way will not see any issues.
@tonihei Actually the issue persists. I finally found the cause. It’s a bug in Gradle Plugin and it has something to do with Dexing Artifact Transformations. Steps to reproduce:
You will see the crash:
The crash doesn’t happen if I create a maven repo that includes the Exo Player dependencies automatically by using transitive true. If not using transitive true and providing the Exo Player dependencies inside the app’s build.gradle file it crashes. There is a workaround that fixes this issue by using: android.enableDexingArtifactTransform=false This however is not a solution for me as I can’t force users to do this in their App.
Please refer to https://issuetracker.google.com/issues/139821726 and https://www.reddit.com/r/androiddev/comments/d0e1mi/gradle_plugin_350_causes_abstractmethoderror_for/
Edit: The min API level needs to be below 21.