0

I have guava as an application dependency and using Espresso in the Instrumentation tests. Since Espresso comes with com.google.guava:guava:16.0, and I have guava in the application dependency, I have to handle a duplicated dependency issue.

Jake Wharton noted in Double Espresso that I can resolve a duplicated dependency issue by doing something like:

compile 'com.google.guava:guava:17.0'
androidTestCompile('com.jakewharton.espresso:espresso:1.1-r3') {
  exclude group: 'com.squareup.dagger'
  exclude group: 'com.google.guava'
}

with that line though, I am getting bunch of the following errors:

java.lang.NoSuchMethodError: com.google.common.base.Optional.get
    at com.google.android.apps.common.testing.ui.espresso.base.ThreadPoolExecutorExtractor.getAsyncTaskThreadPool(ThreadPoolExecutorExtractor.java:50)

which seems like Espresso is not finding the guava dependency. When I try with

compile 'com.google.guava:guava:17.0'
androidTestCompile ('com.jakewharton.espresso:espresso:1.1-r2') {
  exclude group: 'com.squareup.dagger'
  exclude group: 'com.google.guava'
}
androidTestCompile('com.google.guava:guava:17.0')

Now that java.lang.NoSuchMethodError: com.google.common.base.Optional.get is gone from the espresso code, but I am still getting the following error when an Instrumentation test hits the application code which use one of guava's methods: java.lang.NoClassDefFoundError

This error occurs when I get rid of androidTestCompile('com.google.guava:guava:17.0') as well.

I tried with AndroidTestProvided with guava, no luck.

And I am running out of ideas to why it can't find guava's path when instrumentation tests hit application code with guava methods.

here is a stacktrace

Caused by: java.lang.NoClassDefFoundError: com/themis/clioAndroid/activity/calendar/calendarEntry/CalendarEntryListAdapter$1
at com.themis.clioAndroid.activity.calendar.calendarEntry.CalendarEntryListAdapter.<clinit>(CalendarEntryListAdapter.java:112)
... 34 more
Caused by: java.lang.IllegalAccessError: Class ref in pre-verified class resolved to unexpected implementation
at dalvik.system.DexFile.defineClass(Native Method)
at dalvik.system.DexFile.loadClassBinaryName(DexFile.java:211)
at dalvik.system.DexPathList.findClass(DexPathList.java:315)
at dalvik.system.BaseDexClassLoader.findClass(BaseDexClassLoader.java:58)
at java.lang.ClassLoader.loadClass(ClassLoader.java:501)
at java.lang.ClassLoader.loadClass(ClassLoader.java:461)
... 35 more

where it hits new Ordering<SomeClass>() which uses com.google.common.collect.Ordering.

Any feedback is appreciated.

Naoya Makino
  • 557
  • 2
  • 8
  • 24

1 Answers1

1

Looks like Proguard being a pain.

Proguard or the way the Android gradle plugin is set up does not lead to very intelligent about handeling the espresso libraries. Add

-keep class com.google.common.** { *; }

to your proguard-rules.txt

Or if you're using proguard to get around the 65K method limit consider switching to the MultiDex support package.

thoutbeckers
  • 2,599
  • 22
  • 24