A device can lie still on a table while its accelerometer reports a reading close to one g. That looks like a contradiction if “acceleration” means only a change in the device's speed or direction across the room. The reading answers a different question. An accelerometer responds to the support and other non-gravitational forces acting on it, expressed as force per unit mass. The table keeps the device from falling. With the upward sensor axis correctly identified, that support produces an upward reading even though the device stays in one place. Android and Chrome documentation both describe this stationary-table behavior. [2][3]

The letter g here names the approximate strength of gravity near Earth's surface, commonly about 9.8 metres per second squared. It is not a gram. To make the arithmetic easy to inspect, our imaginary examples use a gravitational magnitude of exactly 10 m/s². Every numerical record below is constructed for explanation, not collected from a phone. We will follow a stationary device, a tilted one and an accelerating one, then ask what their numbers can actually tell us. Free fall appears only as a thought example; there is no reason to drop or throw a device to understand the distinction.

The apparent contradiction comes from conflating world-frame kinematic acceleration with an accelerometer's specific-force output. In the ideal local model used here, a supported stationary sensor has zero kinematic acceleration but nonzero specific force. A freely falling, non-rotating sensor following the gravitational acceleration has zero specific force. The platform documentation gives these limiting cases explicitly, including the positive upward reading for a device supported on a table. [2][3] They are useful sign checks before interpreting any three-axis record.

We use a uniform local gravitational vector of magnitude 10 m/s², a deliberately rounded model value rather than a statement about local gravity or a device's calibration reference. The numerical examples describe an ideal point sensor with known axis conventions. Offsets are absent until the separate calibration example. There are no recorded sensor traces, executed applications or device accuracy results. The aim is to distinguish the observed vector from the assumptions needed to infer tilt or translational acceleration, including a counterexample in which two different physical states produce exactly the same three components.

Picture a fixed set of room axes with the positive vertical direction pointing upward. In our model, gravity points downward and has a vertical value of −10. A stationary device has a room acceleration of zero. The ideal accelerometer reading is the device's acceleration minus gravitational acceleration, with both expressed along the same axes. In the vertical direction, zero minus −10 gives +10. The two minus signs explain the positive reading without claiming that the device is moving upward. It is being supported against the fall that gravity would otherwise produce. [2][3]

Now consider ideal free fall without rotation or other forces. The device's downward acceleration is −10 in this model, matching gravity. Subtracting −10 from −10 gives zero. Zero on the accelerometer therefore does not necessarily mean that the device's velocity is unchanging. Conversely, a nonzero reading does not necessarily mean that it is moving across the room. The sensor is useful because it reports this particular physical quantity; the difficulty begins when a label such as “acceleration” hides which quantity is meant. A later software estimate can try to separate motion from the gravity-related part, but that is another step.

Let a be kinematic acceleration in world coordinates and g the gravitational acceleration vector in those coordinates. Let T be an orthogonal transformation mapping world-vector components into sensor-vector components. Define the ideal accelerometer output as f=T(a−g). In this convention g=(0,0,−10) m/s². When T is the identity and a=0, f=(0,0,10). For ideal non-rotating free fall, a=g and f=0. These relationships reproduce the signs in the platform examples. [2][3]

It is useful to define a_s=Ta and q=−Tg, so that f=a_s+q. Here q is the gravity-related contribution to the accelerometer output at rest. It points opposite to physical gravitational acceleration expressed in sensor coordinates. This definition avoids using the same “gravity vector” label for two vectors with opposite signs. All quantities have acceleration units, even when documentation informally describes an acceleration force. The decomposition also shows the information problem: observing f does not independently supply both a_s and q. Assigning the whole observation to q already imposes a condition on motion.

Keep the first explanation of (6, 0, 8): a tilted device resting still. Now consider a second device whose axes remain upright in our room frame. Let its room acceleration be 6 sideways, zero along y and 2 downward, written (6, 0, −2). Subtract gravity, (0, 0, −10), from that room acceleration. The accelerometer output becomes (6, 0, 8), exactly the same three numbers as before. Both calculations use the same units and the same gravity strength. Neither depends on measurement noise.

The second device is not tilted by 36.87 degrees. Its sideways and downward motion changes account for the reading. If the stated acceleration is sustained over a finite interval while the axes remain upright, its output stays constant over that interval. A steady record can therefore have either explanation. The manufacturer's warning about additional constant acceleration is visible here as an exact numerical counterexample. [1] An algorithm that sees only this record must return the same result for both cases, unless it has extra information. It cannot recover a distinction that is absent from its input simply by using a more confident label.

Case A has a=0 and the tilted T defined earlier, giving f=(6,0,8). Case B has T=I and a=(6,0,−2) m/s², so f=a−g=(6,0,8). In A, q=(6,0,8) and a_s=0. In B, q=(0,0,10) and a_s=(6,0,−2). The decomposition changes while the observable vector is identical. Both are valid states of the same ideal model, and the second can persist with fixed orientation and constant acceleration over a finite interval. Over an illustrative two-second interval, Case B changes its world velocity by (12,0,−4) m/s, whereas Case A remains stationary. That difference in velocity history is physically meaningful even though the sensor output is unchanged.

The ambiguity is therefore stronger than a comparison of equal magnitudes or one matching channel. All three components and their constant time histories can agree. An estimator taking only those histories, with the same initial assumptions, has no input feature that separates the two cases. Extra constraints, motion knowledge or another independently informative signal are required for that separation. This is a concrete expression of the application note's warning about DC acceleration contaminating gravity-based inclination. [1] It does not claim that every real motion sequence is indistinguishable, only that accelerometer-only inference cannot be universally unique.

It is tempting to check the overall reading and say, “It is close to one g, so this must be gravity only.” Our two cases show why that shortcut fails. Both give a size of 10 in a model where gravity also has size 10. The tilted stationary case fits the rule, but so does the upright accelerating case. The test accepts a state that violates its intended assumption. A useful check can catch some problems without proving that every accepted record has the desired explanation.

There is a similar problem with treating a constant reading as proof of rest. A constant vector can contain a constant motion-related contribution. A varying vector, meanwhile, might come from changing tilt, changing room acceleration, or both. Analog Devices notes that turning through gravity changes the projections and that filtering affects how quickly the output settles to a new static value. [1] Magnitude, stability and smoothness are useful descriptions of the data. To turn those descriptions into a claim about movement, state the conditions and the additional evidence used. Our example's exact numbers make the logical gap visible before noise complicates it.

The condition |f|≈|g| is not sufficient for a≈0. Our exact counterexample has |f|²=6²+8²=100=|g|² while |a|²=6²+(−2)²=40. In world coordinates, |a−g|²=|g|² implies |a|²−2a·g=0, which admits nonzero a. For Case B, a·g=20 and |a|²=40, so the equality holds exactly. This derived identity explains why the failure is not an artifact of rounding the angle.

A magnitude gate may still be one element of an estimator's decision logic, but it cannot certify the gravity-only condition by itself. Likewise, low variation in f does not establish low translational acceleration. Changing orientation redistributes the gravity contribution, and constant translational acceleration can resemble a changed static orientation. [1] The distinction between a necessary consistency check and a sufficient physical explanation is practical: an accepted sample should retain the assumptions under which it will be used. No threshold or confidence score can turn this particular single-signal counterexample into independent evidence of rest.

A device or app may offer an accelerometer value, a gravity estimate and a linear-acceleration value. Those names should lead you to different expectations. Android describes the accelerometer output as including the gravity-related contribution, and linear acceleration as excluding it. At rest, its gravity output should match its accelerometer output. [2] Chrome documentation likewise distinguishes an accelerometer's supported one-g reading from the near-zero linear-acceleration reading expected at rest. [3] Three numbers labelled “acceleration” therefore need more context than their units alone.

In our sign convention, an upright stationary accelerometer reads upward +10, and the gravity-related part to subtract is also upward +10. The physical gravitational acceleration in the room is downward −10. Mixing those two meanings of “gravity” would produce the wrong subtraction. A software estimate can use information beyond a single accelerometer, and some exposed sensor quantities are calculated or fused rather than direct hardware outputs. [2][3] Its documentation should explain what it represents. Neither the output name nor the presence of three decimal places guarantees a particular accuracy, availability or motion-separation method on every device.

Android's documented conceptual relation is linear acceleration equals accelerometer acceleration minus its gravity contribution. Its gravity output uses the accelerometer coordinate system and should match the accelerometer at rest. [2] In our notation that subtraction is a_s=f−q, where q=−Tg. It is not f−Tg. The latter would add the downward physical-gravity vector's opposite a second time and yield 20 m/s² vertically for the upright stationary toy case. Explicitly naming the vector convention prevents an API label from reversing the physical sign.

Reported gravity and linear acceleration may involve software estimation or sensor fusion, while the underlying accelerometer measures a different physical signal. The platform sources distinguish low-level and derived sensor interfaces. [2][3] This article does not infer a specific fusion algorithm from an API name, nor assume identical implementations across hardware. Interpret units, frame, calibration state, timestamps and quantity definition together. If a supplied linear-acceleration signal already has a gravity contribution removed, subtracting that contribution again is a different operation. The provenance of the value matters as much as the numerical transformation applied to it.

Here, “raw accelerometer” is shorthand for the gravity-inclusive accelerometer quantity, not a promise of untouched electrical samples or absent factory correction. Android separately documents an uncalibrated accelerometer type without bias compensation. [2] Those are different distinctions: whether gravity is included describes the physical quantity, while whether bias compensation is applied describes processing of that quantity. A gravity-inclusive output can still be calibrated, and a gravity-removed output can still have estimation errors. Keeping those two labels independent makes an exported record much easier to interpret than using “raw” as a catch-all description.