Fixed
Status Update
No update yet.
Comments
uc...@google.com
sn...@google.com
Further testing shows 11.0.0 works in this setup and 11.2.0 is the first version this appears.
uc...@google.com
je...@google.com
hu...@google.com
This is expected. Both libraries have a java resource called 'protobuf.meta', which either the library authors need to stop shipping or the build author needs to pick one. See https://google.github.io/android-gradle-dsl/current/com.android.build.gradle.internal.dsl.PackagingOptions.html
However, if both libraries actually depend on that java resource you are in trouble.
However, if both libraries actually depend on that java resource you are in trouble.
ja...@gmail.com
I can confirm that specifying exclude or pick-first on protobuf.meta results in a successful build and no *immediate* problems. However, the contents of these two files are completely different and without understanding the purpose of these files (I assume related to protocol buffer data structure) it feels very treacherous to remove them.
ja...@gmail.com
Stephan, do you know what that file does and what changed that meant that it has started being bundled as a java resource in the testing support library?
ja...@gmail.com
I see the same issue in a module referencing com.google.android.gms:play-services-location and com.google.android.gms:play-services-maps after integrating com.google.firebase:firebase-core and com.google.firebase:firebase-perf in the app.
I am running `11.6.2` of all libraries as well as Gradle 4.3.1-all and support lib 26.1.0
I am running `11.6.2` of all libraries as well as Gradle 4.3.1-all and support lib 26.1.0
hu...@google.com
Experiencing the same issue. Any verdict on how to fix this?
hu...@google.com
This will be fixed in the next release of Espresso v3.0.2.
We will be stripping off protobuf.meta file from the release binaries since they are not actually needed at run time.
We will be stripping off protobuf.meta file from the release binaries since they are not actually needed at run time.
ja...@gmail.com
Yes, you are right. I was demonstrating that upgrading from 3.0.0 to 3.0.1 did not work and that they both have problems.
Ideally a 3.0.2 release with the POM file containing Guava(add as implementation/compile dependency) is needed. I am not sure about the duplicated R.class.
Ideally a 3.0.2 release with the POM file containing Guava(add as implementation/compile dependency) is needed. I am not sure about the duplicated R.class.
sl...@google.com
Both issues have been fixed and will be included in the 3.0.2-alpha2 release
ja...@gmail.com
Thanks for the quick fix!
ve...@gmail.com
HI All, Any working sample project for accessibility please share the github link.
Description
all required information.
Studio Build:
Version of Gradle Plugin: 162.2228.14
Version of Gradle: 3.3
Version of Java: 1.8.0_73 (Oracle Corporation 25.73-b02)
OS: Mac OS X 10.12.6 x86_64
Steps to Reproduce:
1. Make an Android project
2. Install Espresso
3. Add the following to build.gradle:
androidTestCompile 'com.android.support.test.espresso:espresso-core:3.0.1', {
exclude group: 'com.android.support', module: 'support-annotations'
}
androidTestCompile 'com.android.support.test.uiautomator:uiautomator-v18:2.1.1'
androidTestCompile 'com.android.support.test.espresso:espresso-web:3.0.1'
androidTestCompile 'com.android.support.test.espresso:espresso-accessibility:3.0.1'
androidTestCompile 'com.android.support.test.espresso:espresso-contrib:3.0.1'
androidTestCompile 'com.android.support.test:runner:1.0.0'
androidTestCompile 'com.android.support.test:rules:1.0.0'
androidTestCompile "org.jetbrains.kotlin:kotlin-stdlib-jre7:$kotlin_version"
androidTestCompile "org.jetbrains.kotlin:kotlin-test-junit:$kotlin_version"
4. Create espresso test
5. Enable AccessibilityChecks by
Example (in kotlin):
companion object {
@BeforeClass @JvmStatic
fun enableAccessibilityChecks() {
AccessibilityChecks.enable()
}
}
6. Run Tests
It will say: "Empty test suite."
See:
To Fix:
I had to add androidTestCompile 'com.google.guava:guava:20.0' to the app gradle file.