Fixed
Status Update
Comments
sl...@google.com <sl...@google.com>
sl...@google.com <sl...@google.com>
nk...@google.com <nk...@google.com>
nk...@google.com <nk...@google.com> #2
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.
Description
Version used: 3.0.0
According to the release notes, Guava classes have been moved to the "internal" package, and the use of those classes in application test code is discouraged. However, AdapterViewProtocol has the getDataRenderedByView() method that returns android.support.test.espresso.core.internal.deps.guava.base.Optional, so the test code implementing AdapterViewProtocol is forced to import that class. This makes Optional a part of the API, hence it should be moved out of the "internal" package.