How Touch Events Distinguish Real Phones
A device claiming to be a phone can be asked to demonstrate it. Touch input on real hardware carries physical detail that synthetic input reproduces only approximately, and the gap is measurable.
Touch is reported as an area, not a point
A finger contacts a screen across a region, and the digitiser reports the size and shape of that region alongside a computed centre point.
The reported area varies with pressure, finger angle and which finger is used. It changes continuously through a single touch as the contact settles and lifts.
Emulated touch typically reports a fixed nominal area or none at all, because there is no physical contact to measure and the emulator supplies a placeholder.
Coordinates carry sensor noise
Real digitisers produce slightly noisy readings, so a stationary finger yields coordinates that jitter within a small range rather than staying perfectly still.
Movement traces show smooth acceleration and deceleration governed by arm and finger mechanics, with characteristic overshoot when a target is approached quickly.
Synthetic traces tend to be geometrically clean: straight lines, constant velocity, exact endpoints. The cleanliness is what stands out, since no hand produces it.
Multi-touch is difficult to synthesise well
Pinch and rotate gestures involve multiple contacts whose movements are physically constrained by being attached to the same hand.
The relationship between the contacts, their relative timing on touch-down and lift-off, and the way one lags the other are all consequences of anatomy rather than of the gesture's logical definition.
Scripted multi-touch usually moves both points symmetrically and simultaneously, which is the one thing a real hand almost never does.
Event sequences follow hardware ordering
Real touch produces a strict sequence of start, move and end events with timing determined by the digitiser's sampling rate, which is a fixed property of the device.
Sampling rates cluster at standard values per device family, so the interval between move events is itself a check on whether the reported device is plausible.
Injected events often arrive at intervals set by a script's loop rather than by any hardware clock, producing rates that no shipped device uses.
Consistency with the rest of the profile matters most
The strongest check is not any single touch property but whether touch behaviour agrees with everything else the client claims. A device reporting phone characteristics should produce phone-shaped input.
Mismatches are informative in both directions, and they are also where false positives concentrate: assistive input devices, styluses and desktop machines with touchscreens all produce combinations that naive rules treat as impossible.