Skip to content
This repository was archived by the owner on Apr 30, 2019. It is now read-only.

Android: Classes that register with Bus cannot safely use private methods with newer API parameters. #101

Closed
Kusand opened this issue Dec 31, 2013 · 2 comments

Comments

@Kusand
Copy link

Kusand commented Dec 31, 2013

Android apps that safely use new API classes as parameters in a method will still crash due to the following line in AnnotatedMethodHandler:

for (Method method : listenerClass.getDeclaredMethods())

An example set of methods:

@TargetApi(19)
private void doANewThingIfPossible() {
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
         CaptioningManager captioningManager = (CaptioningManager) getActivity().getSystemService(Context.CAPTIONING_SERVICE);
         doANewThingWithCaptioning(captioningManager);
    }

@TargetApi(19)
private void doANewThingWithCaptioning(CaptioningManager mgr) {
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
        // Do something with captioning
    }
}

A class with these methods is safe to run on an older device without Otto, but attempting to register this class to an Otto Bus will cause the class to crash with a java.lang.NoClassDefFoundError: android/view/accessibility/CaptioningManager upon registration.

There are definitely work-arounds and good coding practices that will prevent this, like inlining or moving doANewThingWithCaptioning to a new class, but wanted to bring it up as adding Otto to a pre-existing class can cause this to crop up.

@JakeWharton
Copy link
Collaborator

This is a symptom of older versions of Dalvik doing reflection in bulk. It's not specific to Otto but any reflection-based operation. Something as seemingly innocuous as specifying onClick bindings in XML will trigger this too. See:http://corner.squareup.com/2012/08/getting-to-the-bottom.html

I don't think there's much for us to do here. It's not a problem on modern runtimes and it's doubtful we'll ever do a code-gen version.

@Kusand
Copy link
Author

Kusand commented Dec 31, 2013

Cool, thanks for the link to the reading. Much appreciated. I wasn't positive there would be anything you could do short of returning to getMethods and giving up on the private-method-fast-fail, but wanted to note it.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants