About this tool
Plug an Android phone into a Chromium browser over USB and this page reads its sensors: the full table of what the hardware offers, live values from the accelerometer, gyroscope, magnetometer, barometer and the ambient light sensor, the temperature of every thermal zone, and a live picture of your fingers on the touch panel drawn from the digitiser's own event stream. Nothing is installed on the phone and nothing is uploaded — this page is a static file with no server behind it, and the readings stop existing when you close the tab.
Why your browser cannot read the ambient light sensor
The Generic Sensor API gives a web page the accelerometer, the gyroscope and the magnetometer after a permission prompt. Ambient light is the one it does not give you: AmbientLightSensor shipped behind a Chrome flag and has never been on by default, and neither Safari nor Firefox implements it — the privacy argument being that a light reading leaks where you are and, at a high enough rate, roughly what is on a screen nearby. So on the open web, lux is unavailable. Over ADB it is simply a line in a system dump, because the debugging channel was never meant to be the same kind of boundary: the shell that reads it is one you enabled by hand, over a cable, on a phone you are holding. That gap is why this page exists in this shape at all.
A polled snapshot is not a high-rate capture
The live values here come from dumpsys sensorservice, which prints the last few dozen events each sensor produced into a ring buffer. This page reads that buffer once or twice a second and merges the new events into the traces, each placed at the timestamp the hardware gave it — which is why one read per second can draw a dozen points. What it cannot do is guarantee that nothing was missed: a sensor running at 200 Hz overruns its buffer between reads, and the events that fell out are gone. So the traces show shape and drift, not a waveform. If you need every sample, you need an app on the phone registering a listener, and no amount of shell access substitutes for that. The page also prints the cost of each read, because that dump is tens of kilobytes of text and pulling it once a second is real work for the phone.
Why your sensor list has no range, resolution or power
The spec table shows what the platform prints, and the platform stopped printing three of the interesting fields a long time ago. maxRange, resolution and power exist on the platform's sensor object and appear in the protobuf form of the same dump, but the text dump has not carried them since around Android 8.1, so on a Pixel those columns are empty for every sensor. Rather than fill a column with dashes — which reads as "this accelerometer has no measurement range" — the page removes the columns and says why underneath. Some manufacturers add them back: Samsung builds often print range, resolution and a power figure in milliamps, and when they do the columns reappear. Everything else is what the sensor HAL enumerated: handle, vendor part name, Android type, reporting mode, minimum delay, maximum rate, FIFO depth, and whether the sensor can wake the phone from sleep.
Pressure and contact area are what the web does not give you
The touch panel section streams getevent from the phone's digitiser and reassembles it into fingers. What arrives is more than coordinates: ABS_MT_TRACKING_ID is the identity the kernel assigns each contact, so a finger can be followed across the screen; ABS_MT_PRESSURE is how hard the panel thinks you are pressing, in units it invents for itself; and ABS_MT_TOUCH_MAJOR is the width of the contact ellipse, which is how a phone tells a fingertip from a palm. A browser's touch events carry none of that reliably — force is unimplemented or synthetic almost everywhere, and radiusX is a rough guess. Not every panel provides them either: plenty of capacitive screens report no pressure at all, and this page says so rather than shading every touch identically and letting you believe it measured something.
This is a diagnostic view, not a calibration tool. It cannot change how the panel behaves, and a jump in the coordinates is not proof of a broken digitiser — a dirty screen, a cheap charger injecting noise, or a case pressing on the edges all produce the same picture. What it is good for is seeing the raw truth quickly: whether a dead patch reports nothing at all, whether a ghost touch carries a tracking id, whether the gyroscope drifts while the phone sits still. From here, the Web ADB hub has the whole device dashboard, the battery page reads capacity and cycle count, and the browser's own Screen Test checks the display itself.