Fixed
Status Update
No update yet.
Comments
sl...@google.com
This is a terrible oversight on our part but unfortunately there is no clean way to revert this API in order to break Guava dependency.
As a result, there will be a breaking public API change in the next release to address this issue. We introduced an ugly wrapper around Guava Optional class, named EspressoOptional which will live under "android.support.test.espresso.util" namespace. Developers that were using the leaked Guava Optional API will need to change their imports and references to use EspressoOptional during the update to the new version.
Sorry for the inconvenience this may cause. We'll make sure to add a note for this in the next release announcement and change-logs.
As a result, there will be a breaking public API change in the next release to address this issue. We introduced an ugly wrapper around Guava Optional class, named EspressoOptional which will live under "android.support.test.espresso.util" namespace. Developers that were using the leaked Guava Optional API will need to change their imports and references to use EspressoOptional during the update to the new version.
Sorry for the inconvenience this may cause. We'll make sure to add a note for this in the next release announcement and change-logs.
sl...@google.com
su...@twofortyfouram.com
On FTL the Build.HARDWARE is "gce_x86". For this test I used NexusLowRes API 26.
If I change the version of espresso to 3.0.0 the problem does not occur. If I change it to 3.0.0-alpha-1, then the problem does occur consistently. Something seems to have changed between these versions.
If I change the version of espresso to 3.0.0 the problem does not occur. If I change it to 3.0.0-alpha-1, then the problem does occur consistently. Something seems to have changed between these versions.
sl...@google.com
Thanks! In that case @RequiresDevice will not filter out the test, because we only check for "goldfish" and "ranchu" emulator hardware. I will add "gce_x86" for FTL to the list of supported emulators in 1.0.1. The reason why the test was filtered in 1.0.1 is because of a bug in sharding filter which was fixed in 1.0.1-alpha-1
Description
Version used: 3.0.0-alpha-1
What steps will reproduce the problem?
1. Create a test that requires a physical device
2. Annotate the test with @RequiresDevice
3. Run the test on a virtual device on Firebase Test Lab
How are you running your tests (via Android Studio, Gradle, adb, etc.)?
Build APK ./gradlew assembleDebugAndroidTest then invoking gcloud by the command line.
What is the expected output? What do you see instead?
Expected: the test is skipped.
Actual: The test is executed. Note that this works correctly on an AVD running locally; it just doesn't correctly detect the FTL virtual device as being virtual.
This appears to be a regression in alpha-1.