Accessibility-Test-Framework-for-Android
Accessibility-Test-Framework-for-Android copied to clipboard
Migrate to protobuf-javalite
I have firebase-perf and espresso-contrib (which has dependency on this library) in same classpath so gradle cannot build my project because of duplicate classes from com.google.protobuf:protobuf-lite (from this lib) and com.google.protobuf:protobuf-javalite (from firebase-perf)
Here is the issue why firebase-perf migrated to javalite
So after u update this lib espresso team also need post a new version with updated deps And after all @Sloy(or someone else from barista team) should update barista and then I'll can assemble my project :) (@Sloy I mention you because latest update(4.1.0) with updating espresso became breaking)
I would like to understand if this is something that will be prioritized, and when it will be prioritized with a fix released that Espresso can pull in, as I am facing a similar issue.
While I can build my project, my espresso tests fail:
java.lang.ExceptionInInitializerError
at java.lang.Class.classForName(Native Method)
at java.lang.Class.forName(Class.java:453)
at java.lang.Class.forName(Class.java:378)
at com.google.android.gms.internal.cast.zzlu.zzje(com.google.android.gms:play-services-cast@@19.0.0:1)
at com.google.android.gms.internal.cast.zzlu.<clinit>(com.google.android.gms:play-services-cast@@19.0.0:10)
at com.google.android.gms.internal.cast.zzlu.zzjf(com.google.android.gms:play-services-cast@@19.0.0:5)
at com.google.android.gms.internal.cast.zznb.zzd(com.google.android.gms:play-services-cast@@19.0.0:28)
at com.google.android.gms.internal.cast.zzoa.zze(com.google.android.gms:play-services-cast@@19.0.0:5)
at com.google.android.gms.internal.cast.zzoa.zzp(com.google.android.gms:play-services-cast@@19.0.0:14)
at com.google.android.gms.internal.cast.zzmc$zzb.zzjw(com.google.android.gms:play-services-cast@@19.0.0:18)
at com.google.android.gms.internal.cast.zzmc$zzb.zzjy(com.google.android.gms:play-services-cast@@19.0.0:39)
at com.google.android.gms.internal.cast.zzmc$zzb.zzjx(com.google.android.gms:play-services-cast@@19.0.0:21)
at com.google.android.gms.internal.cast.zzmc$zzb.zzjz(com.google.android.gms:play-services-cast@@19.0.0:40)
at com.google.android.gms.internal.cast.zzo.zzbd(com.google.android.gms:play-services-cast-framework@@19.0.0:103)
at com.google.android.gms.internal.cast.zzn.run(Unknown Source:2)
at android.os.Handler.handleCallback(Handler.java:873)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:193)
at android.app.ActivityThread.main(ActivityThread.java:6669)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:493)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:858)
Caused by: java.lang.IllegalStateException: Unable to lookup extension field offset
at com.google.protobuf.ExtensionSchemaFull.getExtensionsFieldOffset(ExtensionSchemaFull.java:52)
at com.google.protobuf.ExtensionSchemaFull.<clinit>(ExtensionSchemaFull.java:45)
... 22 more
I can get around the test startup failures by adding
configurations {
forEach { configuration ->
configuration.exclude(group = "com.google.protobuf", module = "protobuf-lite")
}
}
However, with this startup workaround, we are uncertain of whether or not our checks will be broken.
Using Espresso to validate accessibility checks are important to us, so it would be good for us to feel confident in our "fix". We are also very much interested in updating to Espresso 3.4 since version 3.3 has a dependency on android.support, which requires us to continue using jetifier, and is not ideal.
The real fix here is for this library to ship a jarjared version of protobuf (whichever version you choose) inside of this library. Adding it as a direct dependency directly without jarjaring causes classpath collisions through various flavors of protobuf available, additionally version upgrades are not safe because protobuf is not binary safe from version to version. All in all, having it as a dependencies causes a huge problem for any client that use protobuf or include a library that does.
@caseyburkhardt can you help us, please?
Closed issue because now all dependencies are correct