You're mid-sentence on a call, phone pressed to your ear, and somehow your cheek just liked a photo from three years ago. Congratulations. Your face has opinions.
The fix for this is running constantly, invisibly, in about 100 milliseconds, deep inside every app you've ever opened.
The filter under every finger press
When your fingertip hits a capacitive touchscreen, the digitizer doesn't see a point. It sees a pressure blob, typically 8 to 12 millimetres across, because your skin is soft and conductive and spreads on contact. Messy by nature. The operating system's touch pipeline collapses that blob into one coordinate, then passes it up to the app layer with a timestamp and a touch ID.
The app runs that event through a gauntlet of gesture recognizers. On both iOS and Android, these are formal objects built into the framework, not ad-hoc code each developer cobbles together from scratch. A tap recognizer watches for three things in sequence: a touch-down event, minimal movement (under about 10 logical pixels on most configurations), and a touch-up event within a window of roughly 300 to 500 milliseconds. Miss any one of those conditions and the recognizer fires nothing. As far as the app is concerned, the tap never happened.
That 300-millisecond window is doing serious work. A deliberate tap from a focused adult lands in the 150 to 250 millisecond range, tight and confident, a period at the end of a sentence. An accidental graze from a pocket or a drifting palm tends to be either too brief (under 80ms, dismissed as noise) or too prolonged and wandering, which triggers a scroll or long-press recognizer instead. That gap between intentional and unintentional touch is narrow. But it's consistent enough to exploit.
Movement thresholds matter just as much. Android's ViewConfiguration class defines the "touch slop" constant at 8 density-independent pixels. Cross that distance between touch-down and touch-up and the system reclassifies the gesture as a scroll candidate, not a tap. iOS uses a similar internal tolerance. Developers can adjust these thresholds, but most leave them at defaults, because those defaults were tuned against years of real-world usage data and honestly, fighting them is a bad idea.
What people get wrong about this
The common assumption is that pressure sensitivity sorts intentional from accidental.
That assumption is wrong. Not on most consumer phones. Standard capacitive screens measure contact area, not force. A light deliberate tap and a firm accidental palm-graze produce similar raw signals. Force Touch (on older iPhones) and pressure-sensitive stylus input are the exceptions, built for specific interactions, not general tap disambiguation. This surprises people. It surprised me.
A second misconception is that the OS handles everything and developers just receive clean events. Here's where it gets interesting. Take two developers building a map app. Priya adds a tap recognizer and a pan recognizer to the view without configuring any dependency between them. On a slow scroll, both fire, and the map occasionally drops a spurious pin in the middle of nowhere. Marcus adds one line specifying that the tap recognizer should fail if the pan recognizer succeeds. His users never see phantom pins. Identical OS, identical raw touch events, completely opposite experience. The framework gives you the tools. Wiring them correctly is still on you.
So what about calls, specifically? Proximity sensors handle that layer. When the earpiece is against your face, the screen goes dark and the digitizer is disabled entirely. That's why cheek-tapping during a call usually does nothing on a modern phone. Usually.
There's also a context-aware layer that apps increasingly lean on. Keyboard apps track typing rhythm: if you've been typing at 60 words per minute and a tap lands 3 pixels from your last keypress within 80 milliseconds, the statistical likelihood of an adjacent-key error is high, so the autocorrect engine overrides the raw input. You pressed Q. The system decides you meant W. This isn't classical gesture recognition. It's probabilistic intent modeling, running silently on every keystroke.
Is your phone misfiring constantly despite all of this? Check the screen protector. A thick tempered-glass protector can shift the contact centroid enough to push taps outside the touch-slop tolerance for small UI elements, creating false contact points right at the edges. Swap it out before you blame the software.
This is ultimately a negotiation between three layers: physics (blurry, imprecise contact), statistics (what does a 200ms press usually mean), and context (what were you just doing a moment ago). No layer solves the problem alone. Together, they get it right often enough that you forget the problem exists.
Right up until your cheek sends a voice message to your entire team.