Same here, I get the exception:

Fatal Exception: java.lang.NoClassDefFoundError
android/os/PersistableBundle

on specific mobile devices

This looks like some kind of Android bug. If you have time and know how to do it, you could test if that occurs with the annotations branch. This code is not present anymore here.

It is an issue with reflection in Event Bus, because of proguard Event Bus
is not able to find some classes which it is trying to get via reflection.

Solution that worked for me -

Only required if you use AsyncExecutor

-keepclassmembers class * extends
de.greenrobot.event.util.ThrowableFailureEvent {
*;
}

add this to proguard-project.txt

Pankaj
Co-Founder, EnglishDost
B.Tech, Comp Sci & Engg,
IIT Madras, Class of 2008
9886259533

On Wed, Feb 25, 2015 at 1:32 PM, greenrobot notifications@github.com
wrote:

This looks like some kind of Android bug. If you have time and know how to
do it, you could test if that occurs with the annotations branch. This code
is not present anymore here.

—
Reply to this email directly or view it on GitHub
#149 (comment).

So, this can be closed?

I'm seeing this issue too. I did a little digging into the code and found the issue.

It does seem to be an Android quirk (specifically in java.lang.Class), but I think it was introduced into EventBus at e47442b.

SubscriberMethodFinder#findSubscriberMethods used to use Class#getMethods(), which doesn't check method signatures (for things such as argument types that don't exist). This was changed to use Class#getDeclaredMethods(), which does check, and throws an exception if something goes wrong.

See lines 763, 770, and 822 in https://android.googlesource.com/platform/libcore/+/a8a489492749b845cc2a85d67c664449d7b0b019/libart/src/main/java/java/lang/Class.java.

The current workaround is to use version 2.3.0, which is what I'm doing for my project. I lied, this change happened before 2.3.0.

Yes that is correct.

Pankaj
Co-Founder, EnglishDost
B.Tech, Comp Sci & Engg,
IIT Madras, Class of 2008
9886259533

On Fri, Feb 27, 2015 at 7:21 AM, Dan Huang notifications@github.com wrote:

I'm seeing this issue too. I did a little digging into the code and found
the issue.

It does seem to be an Android quirk (specifically in java.lang.Class), but
I think it was introduced into EventBus at e47442b
e47442b
.

SubscriberMethodFinder#findSubscriberMethods used to use
Class#getMethods(), which doesn't check method signatures (for things
such as argument types that don't exist). This was changed to use
Class#getDeclaredMethods(), which does check, and throws an exception if
nothing goes wrong.

See lines 763, 770, and 822 in
https://android.googlesource.com/platform/libcore/+/a8a489492749b845cc2a85d67c664449d7b0b019/libart/src/main/java/java/lang/Class.java
.

—
Reply to this email directly or view it on GitHub
#149 (comment).

Thanks for investigating. getMethods is much slower than getDeclaredMethods. Maybe in combination with try/catch...

You only need to call getMethods once, not for each superclass, so it might
be faster if we add that optimization.

On Fri, Feb 27, 2015 at 12:09 AM, greenrobot notifications@github.com
wrote:

Thanks for investigating. getMethods is much slower than
getDeclaredMethods. Maybe in combination with try/catch...

—
Reply to this email directly or view it on GitHub
#149 (comment).

Could someone confirm that be04a2d fixed the issue? Will do a 2.4.1 release once confirmed.

@yuzeh Thanks so much for investigating! Decided to do it as plan B only, because it's not so common and getDeclaredMethods is much faster last time I checked.

removed onRestoreInstanceState from my activity and problem solved

I am still seeing this in EventBus 3.0.0 when a class I'm using EventBus in has some method which references a higher API than the device I am running on.

Please see this tiny sample project:
https://gist.github.com/skyler-b/2bfea0b0bbb4ebdb5080

Which crashes on launch:

java.lang.NoClassDefFoundError: android/webkit/PermissionRequest
at java.lang.Class.getDeclaredMethods(Native Method)
at java.lang.Class.getPublicMethodsRecursive(Class.java:894)
at java.lang.Class.getMethods(Class.java:877)
at org.greenrobot.eventbus.SubscriberMethodFinder.findUsingReflectionInSingleClass(SubscriberMethodFinder.java:157)
at org.greenrobot.eventbus.SubscriberMethodFinder.findUsingInfo(SubscriberMethodFinder.java:88)
at org.greenrobot.eventbus.SubscriberMethodFinder.findSubscriberMethods(SubscriberMethodFinder.java:64)
at org.greenrobot.eventbus.EventBus.register(EventBus.java:136)

This crash is seen when running on a 4.4.2 emulator.

@greenrobot can we re-open this?

@skyler-b are you using an index for eventbus 3? it might help to work around this because it avoids reflection.

I hadn't heard of the subscriber index, but yes, after adding it to my project the crash does go away. Great work around, thanks for the tip!

@skyler-b great.

If it's reproducible for you without the index, would you be available to pinpoint the issue, so we can add a FAQ entry? In #182 it was suggested to remove Activity#onSaveInstanceState(Bundle, PersistableBundle) in favor of Activity#onSaveInstanceState(Bundle).

Which is the subscriber class that is triggering the issue for you? Did you override any methods having a PermissionRequest param? PermissionRequest is API level 21 - what does the affected device have?

@greenrobot if you refer to the gist I posted (https://gist.github.com/skyler-b/2bfea0b0bbb4ebdb5080), it pinpoints the issue pretty concisely. The crash posted occurs on a 4.4.2 emulator.

@skyler-b Does it help to make the "offending" method private?

@greenrobot Yes - a private method with an advanced API does not cause a crash. For example, in my sample project, making someMethod private does prevent the crash.

Awesome! I added a rather long FAQ entry for this: http://greenrobot.org/eventbus/documentation/faq/
Let me know if the FAQ can be improved.

Thanks for your help!

Document looks great, thanks for the explanation!

getMethods also occur NoClassDefFoundError on some devices,maybe add catch around getMethods

Method[] methods; 
try { 
	// This is faster than getMethods, especially when subscribers are fat classes like Activities 
	methods = findState.clazz.getDeclaredMethods(); 
} catch (Throwable th) { 
	try { 
		methods = findState.clazz.getMethods();
	}catch (Throwable th2){
		return;
	}finally { 
		findState.skipSuperClasses = true;
	}
}