Re-write conditional checks for animation When they were extracted into a separate method and split by type of check, we lost some behavior that was guaranteed to be prevented by the short-circuiting. This CL makes sure that the checks do not depend on short circuiting by removing side effect methods from the checks. If the checks pass (we can animate) we do one last check that will try to enable fakeDrag. Test: manual Fixes: 297488363 (cherry picked from commit 9bc94e9c25cb27432071951dced62aeb8cd761a9) (cherry picked from https://googleplex-android-review.googlesource.com/q/commit:77bb4deb7487bf0737b3465b2cdb5a3553c0d10a) Merged-In: Iebda8c9acfbf75a49522887687702b2e8c0158de Change-Id: Iebda8c9acfbf75a49522887687702b2e8c0158de
diff --git a/packages/SystemUI/src/com/android/systemui/qs/PagedTileLayout.java b/packages/SystemUI/src/com/android/systemui/qs/PagedTileLayout.java index ddd9463..9a5f43b 100644 --- a/packages/SystemUI/src/com/android/systemui/qs/PagedTileLayout.java +++ b/packages/SystemUI/src/com/android/systemui/qs/PagedTileLayout.java
@@ -554,6 +554,12 @@ if (shouldNotRunAnimation(tilesToReveal)) { return; } + // This method has side effects (beings the fake drag, if it returns true). If we have + // decided that we want to do a tile reveal, we do a last check to verify that we can + // actually perform a fake drag. + if (!beginFakeDrag()) { + return; + } final int lastPageNumber = mPages.size() - 1; final TileLayout lastPage = mPages.get(lastPageNumber); @@ -588,8 +594,10 @@ } private boolean shouldNotRunAnimation(Set<String> tilesToReveal) { + // None of these have side effects. That way, we don't need to rely on short-circuiting + // behavior boolean noAnimationNeeded = tilesToReveal.isEmpty() || mPages.size() < 2; - boolean scrollingInProgress = getScrollX() != 0 || !beginFakeDrag(); + boolean scrollingInProgress = getScrollX() != 0 || !isFakeDragging(); // isRunningInTestHarness() to disable animation in functional testing as it caused // flakiness and is not needed there. Alternative solutions were more complex and would // still be either potentially flaky or modify internal data.