From 9a984a26a04e1cd49296e4f6bc1b8a117d6deb2c Mon Sep 17 00:00:00 2001
From: Dave Mankoff <mankoff@google.com>
Date: Tue, 20 Apr 2021 11:32:58 -0400
Subject: [PATCH] Increase gesture completion delay for falsing.

The FalsingManager was hitting a race condition with View click
listeners, where clicks would still, somtimes come in after the
FalsingManager had already marked the gesture as un-analyzed.
Increasing the delay from 50ms to 100ms should all but prevent that
from happening.

I have also decreased the penalty for unalayzed taps since
accidentally tapping on the wrong part of the screen is not unlikely.

Fixes: 185212498
Test: manual
Change-Id: I91e1e9152536a36eda74b5fd60051acc78434761
---
 .../classifier/BrightLineFalsingManager.java       |  8 +++++++-
 .../systemui/classifier/FalsingCollectorImpl.java  | 14 +++++++++++++-
 2 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/packages/SystemUI/src/com/android/systemui/classifier/BrightLineFalsingManager.java b/packages/SystemUI/src/com/android/systemui/classifier/BrightLineFalsingManager.java
index e2c62ed55eb21..01d59597197ce 100644
--- a/packages/SystemUI/src/com/android/systemui/classifier/BrightLineFalsingManager.java
+++ b/packages/SystemUI/src/com/android/systemui/classifier/BrightLineFalsingManager.java
@@ -147,10 +147,16 @@ public class BrightLineFalsingManager implements FalsingManager {
                         mPriorInteractionType = Classifier.GENERIC;
                     } else {
                         // Gestures that were not classified get treated as a false.
+                        // Gestures that look like simple taps are less likely to be false
+                        // than swipes. They may simply be mis-clicks.
+                        double penalty = mSingleTapClassifier.isTap(
+                                mDataProvider.getRecentMotionEvents(), 0).isFalse()
+                                ? 0.7 : 0.8;
                         mHistoryTracker.addResults(
                                 Collections.singleton(
                                         FalsingClassifier.Result.falsed(
-                                                .8, getClass().getSimpleName(), "unclassified")),
+                                                penalty, getClass().getSimpleName(),
+                                                "unclassified")),
                                 completionTimeMs);
                     }
                 }
diff --git a/packages/SystemUI/src/com/android/systemui/classifier/FalsingCollectorImpl.java b/packages/SystemUI/src/com/android/systemui/classifier/FalsingCollectorImpl.java
index 88748f9eaac48..206af314d40e0 100644
--- a/packages/SystemUI/src/com/android/systemui/classifier/FalsingCollectorImpl.java
+++ b/packages/SystemUI/src/com/android/systemui/classifier/FalsingCollectorImpl.java
@@ -44,6 +44,7 @@ class FalsingCollectorImpl implements FalsingCollector {
     private static final boolean DEBUG = false;
     private static final String TAG = "FalsingManager";
     private static final String PROXIMITY_SENSOR_TAG = "FalsingManager";
+    private static final long GESTURE_PROCESSING_DELAY_MS = 100;
 
     private final FalsingDataProvider mFalsingDataProvider;
     private final FalsingManager mFalsingManager;
@@ -281,7 +282,18 @@ class FalsingCollectorImpl implements FalsingCollector {
 
     @Override
     public void onMotionEventComplete() {
-        mMainExecutor.executeDelayed(mFalsingDataProvider::onMotionEventComplete , 50);
+        // We must delay processing the completion because of the way Android handles click events.
+        // It generally delays executing them immediately, instead choosing to give the UI a chance
+        // to respond to touch events before acknowledging the click. As such, we must also delay,
+        // giving click handlers a chance to analyze it.
+        // You might think we could do something clever to remove this delay - adding non-committed
+        // results that can later be changed - but this won't help. Calling the code
+        // below can eventually end up in a "Falsing Event" being fired. If we remove the delay
+        // here, we would still have to add the delay to the event, but we'd also have to make all
+        // the intervening code more complicated in the process. This is the simplest insertion
+        // point for the delay.
+        mMainExecutor.executeDelayed(
+                mFalsingDataProvider::onMotionEventComplete, GESTURE_PROCESSING_DELAY_MS);
     }
 
     @Override