Android java lang abstractmethoderror

Abstract Method Error Class

Definition

Some information relates to prerelease product that may be substantially modified before it’s released. Microsoft makes no warranties, express or implied, with respect to the information provided here.

Thrown when an application tries to call an abstract method.

Remarks

Portions of this page are modifications based on work created and shared by the Android Open Source Project and used according to terms described in the Creative Commons 2.5 Attribution License.

Constructors

Constructs an AbstractMethodError with no detail message.

A constructor used when creating managed representations of JNI objects; called by the runtime.

Constructs an AbstractMethodError with no detail message.

Fields

Properties

Returns the cause of this throwable or null if the cause is nonexistent or unknown.

(Inherited from Throwable) Class (Inherited from Throwable) Handle

The handle to the underlying Android instance.

(Inherited from Throwable) JniIdentityHashCode (Inherited from Throwable) JniPeerMembers LocalizedMessage

Creates a localized description of this throwable.

(Inherited from Throwable) Message

Returns the detail message string of this throwable.

(Inherited from Throwable) PeerReference (Inherited from Throwable) StackTrace (Inherited from Throwable) ThresholdClass

This API supports the Mono for Android infrastructure and is not intended to be used directly from your code.

This API supports the Mono for Android infrastructure and is not intended to be used directly from your code.

Methods

Appends the specified exception to the exceptions that were suppressed in order to deliver this exception.

(Inherited from Throwable) Dispose() (Inherited from Throwable) Dispose(Boolean) (Inherited from Throwable) FillInStackTrace()

Fills in the execution stack trace.

(Inherited from Throwable) GetStackTrace()

Provides programmatic access to the stack trace information printed by #printStackTrace() .

(Inherited from Throwable) GetSuppressed()

Returns an array containing all of the exceptions that were suppressed, typically by the try -with-resources statement, in order to deliver this exception.

(Inherited from Throwable) InitCause(Throwable)

Initializes the cause of this throwable to the specified value.

(Inherited from Throwable) PrintStackTrace()

Prints this throwable and its backtrace to the standard error stream.

(Inherited from Throwable) PrintStackTrace(PrintStream)

Prints this throwable and its backtrace to the standard error stream.

(Inherited from Throwable) PrintStackTrace(PrintWriter)

Prints this throwable and its backtrace to the standard error stream.

(Inherited from Throwable) SetHandle(IntPtr, JniHandleOwnership)

Sets the Handle property.

(Inherited from Throwable) SetStackTrace(StackTraceElement[])

Sets the stack trace elements that will be returned by #getStackTrace() and printed by #printStackTrace() and related methods.

(Inherited from Throwable) ToString() (Inherited from Throwable) UnregisterFromRuntime() (Inherited from Throwable)

Explicit Interface Implementations

IJavaPeerable.Disposed()	(Inherited from Throwable)
IJavaPeerable.DisposeUnlessReferenced()	(Inherited from Throwable)
IJavaPeerable.Finalized()	(Inherited from Throwable)
IJavaPeerable.JniManagedPeerState	(Inherited from Throwable)
IJavaPeerable.SetJniIdentityHashCode(Int32)	(Inherited from Throwable)
IJavaPeerable.SetJniManagedPeerState(JniManagedPeerStates)	(Inherited from Throwable)
IJavaPeerable.SetPeerReference(JniObjectReference)	(Inherited from Throwable)

Extension Methods

Performs an Android runtime-checked type conversion.

Источник

java.lang.AbstractMethodError – How to resolve Abstract Method Error

Posted by: Aldo Ziflaj in exceptions August 20th, 2014 0 Views

In this example we will discuss about AbstractMethodError . As you may have figured out, this is thrown when the application calls an abstract method. Normally, this error is caught by the compiler, it can only occur at run time if the definition of some class has incompatibly changed since the currently executing method was last compiled.

The AbstractMethodError extends the IncompatibleClassChangeError class, which occurs when an incompatible class change has occurred to some class definition.

The structure of AbstractMethodError

Constructor:

AbstractMethodError()

Creates an instance of the AbstractMethodError class, setting null as its message.

AbstractMethodError(String s)

Creates an instance of the AbstractMethodError class, using the specified string as message. The string argument indicates the name of the class that threw the error.

The AbstractMethodError in Java

To make an example of AbstractMethodError , I will use the javac compiler from the command-line. This error is thrown when the classes are separately-compiled, and most of IDEs don’t allow this.

Create a java class called AbsClass with the following source code:

To compile this class, execute this on the command-line:

Now that the first class is compiled, create the second class, called MainClass , with this source code:

The output of compiling and running this would be:

Things are actually OK, but what would happen if we change the hello() method to abstract and then recompile AbsClass without changing MainClass ? Let’s try it, by changing AbsClass to this:

Now, I can recompile this class without any problem, but when I run the MainClass , I get this:

More about the AbstractMethodError in Java

AbstractMethodError is thrown when the programmer calls an abstract method without firstly overriding it. Of course, this would resolve in a compile-time error and the compilation would fail, but it doesn’t always go this way.

AbstractMethodError would happen if a method of the base class changes to abstract, hence changing the base class to abstract, and all this happens without the proper changes in the child class (i.e. overriding the abstract methods). So, just as in the example above, the programmer calls an abstract, not implemented method (without knowledge of its abstractness), and he is not informed of this error since only the base class gets changed and compiled.

How to deal with AbstractMethodError

What you need to do in this case, is just implement the abstract method of the AbsClass in the MainClass . This would solve the problem you have with the AbstractMethodError .

Источник

java.lang.AbstractMethodError with gradle version 3.5.3 #6801

Comments

TsmileAssassin commented Dec 24, 2019 •

I 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:

The text was updated successfully, but these errors were encountered:

tonihei commented Dec 31, 2019

Previous reports of similar issues mostly forgot to enable Java 8 support (for example: #5600). Can you check that your gradle config includes the following lines?

You could also try to clean all Android Studio caches («File -> Invalidate Caches / Restart») and then also clean and rebuild your project to exclude unwanted side effects from previous versions of ExoPlayer.

zvonkokemperle commented Jan 6, 2020 •

I experience exactly the same issue. I have targetCompatibility JavaVersion.VERSION_1_8 included. This issue is only visible if generating signed builds, it doesn’t matter if it’s debug or release.

The only solution I have found is to disable D8 desugaring by adding the following line to gradle.properties:
android.enableD8.desugaring=false

This solution however is not ok. I am developing a library and I can’t force the users to use this workaround.

TsmileAssassin commented Jan 9, 2020

I have targetCompatibility JavaVersion.VERSION_1_8 included

tonihei commented Jan 9, 2020

I can’t reproduce this in my setup. Have you tried the suggested cleaning and rebuilding steps?

If you did and the problem persists, could you also tell us the Android Studio version and gradle version you are using? And also how you depend on ExoPlayer and other noteworthy build setting that may help us to reproduce the issue.

zvonkokemperle commented Jan 10, 2020

@tonihei
Please note that this is only reproducible when a signed builds (it doesn’t matter if you use debug or release).

Android Studio 3.5.3
Gradle 5.4.1

Nothing helps other than android.enableD8.desugaring=false This could maybe also be a bug in D8.

tonihei commented Jan 10, 2020

There must be something else.

I just did the following:

• Downloaded a fresh install for Android Studio 3.5.3 for Linux
• Created a new project with an empty activity with Java code and using AndroidX, minSdk 16.
• Ensured that gradle 5.4.1 and gradle plugin 3.5.3 are used.
• Enabled Java 8 support by adding compileOptions < targetCompatibility JavaVersion.VERSION_1_8 >to the apps’ build.gradle
• Enabled R8 by setting minifyEnabled true and shrinkResources true
• Added dependency on ExoPlayer 2.11.1: implementation ‘com.google.android.exoplayer:exoplayer:2.11.1’
• Ensured by builds are signed (with the Android debug key):

• Enabled INTERNET permission in the manifest:
• Added a very basic ExoPlayer playback to the acitivity and made sure that the method in your stack trace is used in my code and the code imported by ExoPlayer:

Running this application on a Nexus 6P works without any crashes. And I can see both the signing and the R8 step happening during the build.

Could try to some up with a similar basic setup that reproduces the problem? This would help to find the offending part and whether there is something we can do about it.

zvonkokemperle commented Jan 10, 2020

It really looks like that this is some kind of Android Studio or Gradle caching bug. Invalidate caches and restart did the trick, It’s strange as I did this before and it didn’t help. Currently I can’t reproduce this anymore. I really hope that this is the solution.

Thank you for your help.

tonihei commented Jan 10, 2020

Good to know. We had this before that ExoPlayer updates with subtle API changes caused Android Studio to build something wrong, possible based on cached data. Invalidating the caches helped in almost all cases so far 🙂

tonihei commented Jan 10, 2020

@TsmileAssassin Can you also try to do invalidate caches and restart again to see if it works?

zvonkokemperle commented Jan 14, 2020 •

@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:

1. Create a library that is using Exo Player, e.g. init the player add EventListener and return it
2. Create App that uses the generated aar from step 1.
3. In the App call the library method that returns the player

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.

Edit: The min API level needs to be below 21.

Koster35 commented Jan 15, 2020 •

I am also having a similar AbstractMethodError issue using ExoPlayer 2.10.6. This occurs when we call SimpleExoPlayer#setVideoSurfaceHolder() in our ExoPlayer implementation:

My project is also using Mux 1.0.0-r2.10.6 (https://github.com/muxinc/mux-stats-sdk-exoplayer). Mux listens to Exoplayer’s AnalyticsListener interface. When we disable Mux, the issue does not seem to occur.

Also, this issue only consistently occurs on devices running Android API 22 and below.

My solution was to downgrade our project’s Gradle plugin 3.5.2 -> 3.4.2, as described in the previous posts about this issue. After downgrading the Gradle plugin, the issue no longer reproduces on any API level, even with Mux enabled.

tonihei commented Jan 27, 2020

@zvonkokemperle @Koster35 Thanks for updating the reproduction steps.

It seems this is may actually be working as intended according to the issue you’ve linked, in particular this post: https://issuetracker.google.com/139821726#comment5
«The dexing and desugaring pipeline has changed in 3.5, and by default, we assume all Maven dependencies are fully declared. In your case, «[library1, e.g. your library]» depends on «[library2, e.g. ExoPlayer]» which you are explicitly excluding.»

Can you provide more details on how the app, your test lib and ExoPlayer depend upon each other in gradle? I think directly depending on an aar without context means you may not automatically get all dependencies needed for correct dexing. Mux is also doing some aar rewriting that may be related.

To further debug this, it may be helpful to upload your test setup somewhere so we can verify ourselves.

zvonkokemperle commented Jan 28, 2020

Here is my implementation.

build.gradle

MyPlayer.kt

build.gradle

activity_main.xml

MainActivity.kt

For dependencies I have tried both api and implementation and it crashes in both cases.

tonihei commented Jan 28, 2020

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.

Источник