Fixed
Status Update
No update yet.
Comments
ap...@google.com
Further testing shows 11.0.0 works in this setup and 11.2.0 is the first version this appears.
hu...@google.com
ap...@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.
ap...@google.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.
ap...@google.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?
ap...@google.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
an...@google.com
Experiencing the same issue. Any verdict on how to fix this?
ap...@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.
Description
When the user specifies a destination to store the result of an image capture (with the use of
outputFileOptions), theImageCaptureuse case should verify whether this destination is valid before triggering the image capture request to the camera. If the destination is not valid, the operation should fail fast and the user should be notified about it.