The Traffic Jam Nobody Talks About

You open a fitness app, then navigation, then flip to the camera. Each one is quietly shouting at your phone's hardware: give me the accelerometer, give me the GPS, give me the gyroscope. The phone doesn't freeze. It doesn't flip a coin. It runs a small, mostly invisible negotiation, and the rules of that negotiation are stranger and more interesting than most people expect.

So: how does it actually work?

Your phone almost never ignores sensor data outright. Instead, it batches, throttles, and prioritizes it, using a combination of the OS scheduler, declared app priorities, and the sensor hardware's own internal buffer. The foreground app usually wins. Not always, though, and the reasons why tell you something useful about how your device is actually spending its energy.

One River, Many Buckets

Think of a phone's accelerometer as a single river flowing at a fixed rate. Every app that wants data doesn't get its own private stream. They're all dipping buckets into the same water.

On Android, the SensorManager API lets each app request a specific sampling rate: SENSOR_DELAY_NORMAL (about 5 Hz), SENSOR_DELAY_GAME (roughly 50 Hz), or SENSOR_DELAY_FASTEST (as fast as the hardware goes, sometimes 400-800 Hz on modern chips). When two apps request different rates, the OS delivers at the highest requested rate to both. Nobody gets throttled down against their will. The cost lands on the battery.

On iOS, CoreMotion works similarly but with tighter guardrails. Background apps are automatically capped at lower update rates, and Apple's system will silently reduce GPS accuracy from full GPS to cell-tower triangulation for background processes, dropping positional accuracy from roughly 5 meters to somewhere between 50 and 300 meters. You probably never noticed. Your navigation app running in the background was essentially guessing.

That's the first real mechanism: the foreground/background split. It's not about ignoring apps. It's about degrading what they receive.

The Scenario That Makes It Click

Two people buy the same mid-range Android phone on the same day. Priya and Daniel.

Priya runs a single cycling app during her morning ride. Exclusive access to GPS and accelerometer at full rate. Her route logs are clean, her cadence data is accurate, and her battery drops about 12% over 45 minutes.

Daniel runs the same cycling app but leaves a podcast streaming in the background, plus a sleep-tracking app that declared a persistent foreground service to keep its accelerometer access alive. His cycling app still gets its data, but the sleep tracker's persistent service has elevated its own process priority, which means the OS scheduler treats it almost like a foreground app. GPS still works. The accelerometer, though, is now being polled by two high-priority processes simultaneously. His battery drops 19% over the same 45 minutes, and the sleep tracker logs a 45-minute "walking" session.

Same hardware. Very different outcomes.

The sensor data wasn't ignored; it was shared, and sharing has a cost.

What Actually Gets Cut (and When)

There are conditions where the OS genuinely does start dropping or delaying sensor events.

First: buffer overflow. Most sensors have a small hardware FIFO buffer, typically holding between 100 and 10,000 events depending on the chip. If an app isn't reading fast enough and the buffer fills, old events are overwritten. The app never sees them. This matters most for step counters and sleep trackers that batch data overnight. A poorly written app that wakes up too infrequently will find its buffer has looped and the data is simply gone.

Second: Doze mode on Android, now standard across modern versions. When the phone sits idle and unplugged, Doze progressively restricts background sensor access. In the deepest Doze state, only significant-motion events break through. An app polling for subtle orientation changes every 20ms will receive nothing. Not degraded data. Nothing.

Third: iOS's suspension model. Apps that don't declare a background mode are fully suspended after a few seconds off-screen. Their sensor subscriptions aren't throttled; they're severed. The app simply stops existing, from the sensor's perspective, until the user brings it forward again.

The pattern worth holding onto: the system isn't making judgments about which app deserves data. It's enforcing energy budgets, and sensor access is one of the biggest line items.

What People Consistently Misread

The common assumption is that apps compete and one loses. That's not quite right, and it's worth being direct about it.

A more accurate picture: apps declare their needs, the OS delivers to the highest common denominator, and the battery pays the tab for everyone. The whole thing runs less like a referee and more like a city power grid during a heat wave, where every AC unit gets juice right up until the moment the transformer doesn't.

Where things do get genuinely competitive is in exclusive resources. The camera sensor is a real mutex: only one app can hold it at a time. If your QR scanner has the camera open and another app requests it, that second app gets an error, not degraded access. Full stop.

GPS is similar in spirit but not in implementation. Multiple apps can receive location updates simultaneously, but only one can hold a high-accuracy lock that keeps the GPS radio fully powered. The others can register for updates at lower accuracy tiers without spinning up the hardware independently. The OS fuses their requests.

The accelerometer, gyroscope, and barometer work differently. Passive sensors, no moving parts, no exclusive lock. Sharing them costs almost nothing in terms of the sensor itself. The cost is purely computational: waking the CPU to process and route the data stream.

So the real scarcity isn't the sensor. It's the CPU cycles and radio power needed to serve the sensor's output. That distinction matters, and most coverage of this topic ignores it entirely.

What You Can Actually Do With This

If you're a user rather than a developer, the practical upshot is simpler than the mechanics suggest. Kill apps you aren't using before a long GPS session. Not because the phone can't technically handle them, but because persistent services can quietly elevate their own scheduling priority and pull more from the shared budget than their background status implies.

Check which apps have declared "always on" location permissions. On both Android and iOS, this is visible in settings. An app with always-on GPS access isn't just sitting there politely. It's maintaining a position subscription that keeps the location stack at least partially awake.

And if you're debugging a fitness app that's logging nonsense data, ask yourself: is it really the sensor, or is it the buffer, the Doze window, or a competing high-priority service that starved your app's read loop? Nine times out of ten, it's one of those three.

Your phone isn't choosing winners. It's managing a shared pool with rules that reward whoever shouts loudest about their own importance. Knowing the rules at least tells you who's doing the shouting, and what it's costing you.