summaryrefslogtreecommitdiff
path: root/packages/SystemUI/src/com/android/systemui/classifier/ZigZagClassifier.java
Commit message (Collapse)AuthorAgeFilesLines
* Apply falsing manager on seekbarMichael Mikhail2022-09-281-0/+2
| | | | | | | | | | | Check false taps and touches on seekbar change listener whenever touch is finished. This ensures that all falsing actions are handled besides OnFling events that are handled. Bug: 243040927 Test: manual Test: atest SeekBarViewModelTest Change-Id: I60bcc3196cc2a4b3410c7851f798bfaf87d9e456
* Analyze vertical swipes on QS's Scroll View.Dave Mankoff2022-09-201-2/+2
| | | | | | | | | | | | | | | | | When media controls are shown, the full qs+media controls often takes up more than one full screen. Swiping up on this causes the qs to vertically scroll instead of collapse. Prior to this cl, we weren't analyzing such swipes in the FalsingManager. Now we do. No explicit action is taken in the event of a false swipe. It simply gives us more signal. Enough bad swipes may implicitly cause the lock screen to reset itself. Fixes: 241708312 Test: manual Change-Id: I5adfb3a22b2f0f51efb87d56a6cfc5459cd67006
* Remove ZigZagClassifer from lock-icon longpress falsing algoBeverly2021-08-261-1/+4
| | | | | | | | | | | | | | | | | If the touch leaves the lock icon area, we already drop the touch. Therefore, we don't also need to also take into consideration the ZigZagClassifier for the lock icon. Also, only play the longpress vibration if we will be bringing up the bouncer. If the FalsingManager think we're falsing, there's no reason to play the longpress vibration. Test: manually longpress lock icon on device with udfps capability (after lockdown or reboot) and observe longpress consistently brings up the bouncer Fixes: 197271526 Change-Id: Ic9fa82a549599e48d281b4db69c04627803c6c5a
* Analyze Falsing on Expanded Notif Shade.Dave Mankoff2021-04-081-1/+2
| | | | | | | | | | | | | | Ensure that gestures on the expanded notification shade are picked up properly by the FalsingManager. This adds `SHADE_DRAG` and `QS_COLLAPSE` falsing interaction types to cover these cases. Also, try to limit calling on the FalsingManager until a gesture is actually ready to occur, instead of querying it while deciding what the current gesture is. Fixes: 184042853 Test: manual Change-Id: I1f651614d4d1520bac1a2375319f69fb1017505f
* Add Falsing to the QS BrightnessSliderDave Mankoff2021-03-291-0/+5
| | | | | | | | | This ensures that interactions with the BrightnessSlider are classified as valid gestures by the FalsingManager. Bug: 172655679 Test: manual Change-Id: Ifeb235befc6b1342fc64b671b7704d0fdaa39349
* Add more logging for falsing.Dave Mankoff2021-03-181-2/+4
| | | | | | | | | | | | | | | | | | | | | | Makes the FalsingManager slightly less stateful (passing the interaction type directly to the classifiers as needed). It also includes more logging than we had before, listing all the failed classifiers for a gesture, along with the HistoryTracker's belief and confidence. Logs are now delayed one gesture. Instead of immediately logging when a falsing call is made, it waits until the gesture is marked as complete. This confers two advantages: 1) If multiple calls to #isFalseGesture (and similar) are made, we don't log multiple times. We only log the result once. 2) It allows us to log the effects on the HistoryTracker, as that only updates itself when the gesture is marked as completed. Bug: 172655679 Test: atest SystemUITests && manual Change-Id: I653ac2abb03a91ff000b46075e58137b04226023
* Incorporate Bayes into Falsing.Dave Mankoff2021-03-101-1/+1
| | | | | | | | | | | | | | | | | | This uses the HistoryTracker on pin-based input to determine if a tap outside of an intended region is a false touch, retracting the pin input if we believe pocket dialing is occuring. To do this, the cl properly integrates the HistoryTracker into falsing, at least for single taps. Most importantly, HistoryTracker#falsingBelief now return 0.5 when it is unsure if a tap is false or not, and tends towards 0 when it believes it's valid and 1 when it believes it's false. HistoryTracker#falsingConfidence remains unchanged. Test: atest SystemUITests && manual Bug: 172655679 Change-Id: Ie771b1bf8ac564af7ffb68e190772fff5c562e89
* Make FalsingClassifiers less stateful.Dave Mankoff2020-12-101-4/+4
| | | | | | | | | | Clasifiers now return a Result object on all their classification methods. The Result object now contains the "reason" for falsing instead of asking the Classifier for the reason after the fact. Bug: 172655679 Test: atest SystemUITests Change-Id: I0865f18cbae9367c203936fbbc3923de55c81007
* Add HistoryTracker to FalsingManagerDave Mankoff2020-12-101-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This institutes a HistoryTracker mechanism that will allow the FalsingManager to take recent activity into account when classifying gestures. The HistoryTracker returns a penalty that is pased to each classifier for them to use when making decisions. As of right now, no classifier actually uses the history penalty when making a classification decision. The HistoryTracker keeps records of the last 3 seconds of falsing results, applying a decaying penalty to the results over time. It also assigns a confidence to its results, based on how consistent they are. Each individual classifier is also able to return a confidence score now, such that, if they are not confident in their decision, they don't throw off the score that gets stored in the HistoryTracker. Confidences currently returned by the classifiers are somewhat arbitrary and should be adjusted in future CLs. Everything is currently open for adjustment: - The length of history - The decay function applied to history - The method by which our confidence in the history is calculated - The confidence returned by each individual classfier - How the history penalty is taken into account by each classifier - ... and probably more. Bug: 172655679 Test: atest SystemUITests Change-Id: Ief2a5144a0cda659c7d78ed6e489231d481b6872
* Add Tests for the BrightLineFalsingManager.Dave Mankoff2020-12-011-0/+224
Sets up some more dagger injection and removes all the "new Classifier(...)" from its constructor, allowing them to come from outside. Bug: 172655679 Test: atest SystemUITests Change-Id: I916de7d5ee60ec2183c6401ec222867fc5eff823