Fixed
Status Update
Comments
ma...@gmail.com <ma...@gmail.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.
ma...@gmail.com <ma...@gmail.com> #3
I just came across this issue when I realized I couldn't retrieve fragments after an orientation change. The following works initially, but returns null after an orientation change:
activity.getSupportFragmentManager().findFragmentById(R.id.container);
Also the following demonstrates the leaked activity and view hierarchy (fails on last assert):
activity.setRequestedOrientation(ActivityInfo.SCREEN_ORIENTATION_REVERSE_PORTRAIT);
view = activity.findViewById(R.id.container);
assertNotNull(view);
assertTrue(view.isShown());
activity.setRequestedOrientation(ActivityInfo.SCREEN_ORIENTATION_LANDSCAPE);
view = activity.findViewById(R.id.container);
assertNotNull(view);
assertTrue(view.isShown());
activity.getSupportFragmentManager().findFragmentById(R.id.container);
Also the following demonstrates the leaked activity and view hierarchy (fails on last assert):
activity.setRequestedOrientation(ActivityInfo.SCREEN_ORIENTATION_REVERSE_PORTRAIT);
view = activity.findViewById(R.id.container);
assertNotNull(view);
assertTrue(view.isShown());
activity.setRequestedOrientation(ActivityInfo.SCREEN_ORIENTATION_LANDSCAPE);
view = activity.findViewById(R.id.container);
assertNotNull(view);
assertTrue(view.isShown());
nk...@google.com <nk...@google.com> #4
@maxdownunder76 you should be using Espresso for this type of tests: http://developer.android.com/training/testing/ui-testing/espresso-testing.html
Lowering the priority on this since there is no good way to fix it and the impact is fairly low - the activity will be leaked between orientation change and the end of the test case.
Lowering the priority on this since there is no good way to fix it and the impact is fairly low - the activity will be leaked between orientation change and the end of the test case.
sl...@google.com <sl...@google.com>
nk...@google.com <nk...@google.com> #5
This will be fixed in the next release v1.0.2.
Description
Version used: 0.4.1
What steps will reproduce the problem?
0. enable strict mode (StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder().detectAll().penaltyLog().penaltyDeath().build());)
1. run a test using ActivityTestRule
2. do an orientation change during test
How are you running your tests (via Android Studio, Gradle, adb, etc.)?
android studio and gradle
What is the expected output? What do you see instead?
the problem is that the ActivityTestRule keeps a reference to the first activity and after orientation change a new one is created. this causes a penalty for violation of VmPolicies.