-1

I'm experiencing this issue when updating to the installreferrer library v2.0. LINK So when I call to the library's startConnection method it throws:

Process: com.tomatedigital.lottogram, PID: 13424
java.lang.NoClassDefFoundError: Failed resolution of: Lcom/google/android/aidl/BaseStub;
    at com.android.installreferrer.api.InstallReferrerClientImpl.startConnection(InstallReferrerClientImpl.java:36)
    at com.tomatedigital.lottogram.app.App.saveReferralInfo(App.java:221)
    at com.tomatedigital.lottogram.app.App.onCreate(App.java:102)
    at android.app.Instrumentation.callApplicationOnCreate(Instrumentation.java:1182)
    at android.app.ActivityThread.handleBindApplication(ActivityThread.java:6460)
    at android.app.ActivityThread.access$1300(ActivityThread.java:219)
    at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1859)
    at android.os.Handler.dispatchMessage(Handler.java:107)
    at android.os.Looper.loop(Looper.java:214)
    at android.app.ActivityThread.main(ActivityThread.java:7356)
    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:930)

I think it is a bug in the library, since if you downgrade to previous versions it works great. I'd like to avoid this crash.

I've tried wrapping the code with a :

catch(Throwable ignore){}

But it keeps crashing. How can I gracefully handle this error?

Addev
  • 31,819
  • 51
  • 183
  • 302

1 Answers1

-1

Short answer: You cannot really gracefully handle this error. Why? You are still trying to use some stuff out of this library, so it makes no sense in handling this error. Either you remove this library (because you don't need it) or the error itself (classpath issues) must be resolved. Typically, exceptions like this are critical and you should not try to handle it, because you have a serious error.

Clemens
  • 1
  • I don't say he should not use the library, I just say that if he wants to use the library, then the classpath issues must be resolved. And that is the reason why there is no point in catching this exception, because if this exception rises, then the library he wants to use can obviously not be used due to those issues... So, the question was "how to gracefully handle this error?". And my answer is, that it is not really possible and reasonable to handle this error. Sure, it does not resolve the lib problem (I don't know the lib), but I wouldn't consider my answer "totally useless".... – Clemens Jul 07 '20 at 17:15
  • I can't fix the classpath since it is a transitive dependency of the library :( – Addev Jul 08 '20 at 08:56