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 9bc94e9c)
(cherry picked from https://googleplex-android-review.googlesource.com/q/commit:77bb4deb7487bf0737b3465b2cdb5a3553c0d10a)
Merged-In: Iebda8c9acfbf75a49522887687702b2e8c0158de
Change-Id: Iebda8c9acfbf75a49522887687702b2e8c0158de

packages/SystemUI/src/com/android/systemui/qs/PagedTileLayout.java

@@ -554,6 +554,12 @@ public class PagedTileLayout extends ViewPager implements QSTileLayout {
         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 @@ public class PagedTileLayout extends ViewPager implements QSTileLayout {
     }
 
     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.