6 Mobile Sensor APIs: Measurements and Evidence

6.1 Overview

This first route maps mobile API families to real sensors and derived values, then checks permission, context, timing, units, frames, and batching.

This is part 1 of 2. Continue with Mobile Sensor APIs: Positioning and Filtering for the second focused route.

6.2 Begin With One Phone Reading

An API means a set of rules that lets one piece of software ask another for data or an action. Picture a phone on a delivery cart. You want its motion reading to mark a rough stop or turn. First ask what the reading must prove. Then choose the smallest phone feature that can answer that question. Note who must grant access. Note the time, unit, and quality field that come back with each value.

Try a simple check before you trust the result. Place the phone still on a table. Change its pose. Deny access once. Lock the screen once. A sound plan records each state instead of filling a gap with made-up data. It also says when a web page is enough and when a native app is needed. More access may give more data, but it also raises privacy, battery, and support costs.

This short story does not prove that the phone is a calibrated field tool. It does not explain every sensor inside the device. Use the Practitioner sections to compare access paths, review data quality, and make a field record. Use the Under the Hood sections to trace gravity, frames, sensor hubs, location fixes, and filters. Those deeper routes test the limits of the first choice; they do not erase the need for a clear measurement question.

Make the first trial easy to audit. Put the phone on a known surface. Record its model and system version. Record the app or page version. Ask for access in front of the tester. Save the answer. Take ten still readings. Turn the phone once. Walk a short path. Stop. Save time and units with every value.

Now try the bad paths. Deny access. Turn the feature off. Move to the back. Lock the screen. Wait for an old value. Start with no network. A clear app should show each state. It should not reuse an old value as if it were new. It should not ask for more access than the task needs.

Read the saved record without the phone in hand. Can another person tell what moved? Can they tell which frame was used? Can they spot a gap? Can they tell how exact the location was? Can they see why a value was rejected? If not, add the missing field before adding more sensors. Good evidence starts with a small path that tells the truth.

6.3 Start With the Permission Story

The first mobile sensor result may be “denied,” “unsupported,” or “not fresh enough.” Treat that as evidence, not failure: the API path, permission state, sampling behavior, and accuracy fields are part of the measurement story.

6.4 In 60 Seconds

Mobile phones can act as sensing nodes because browsers and native apps expose controlled access to location, motion, orientation, camera, microphone, and nearby-device signals. The access path matters: each API has a permission model, availability limits, sampling behavior, data format, and evidence requirement.

For IoT work, the goal is not to call every phone sensor. The goal is to choose the smallest API surface that supports the measurement question, explain what the reading means, handle permission denial, record data quality limits, and document when a native app is needed instead of a browser-based approach.

Phoebe’s Field Notes: What “9.8 m/s²” Actually Started Life As

The mathematical gist. A MEMS accelerometer balances $F=ma$ against $F=kx$, giving $x=ma/k$. With the chapter’s illustrative $m=0.1\ \mu\text{g}$, $k=1$ N/m, and $a=9.8\ \text{m/s}^2$, the proof mass moves only 0.980 nm. That motion changes an 88.5 fF plate capacitance by about 0.0868 fF; the chip inverts that tiny electrical change to report the familiar acceleration value.

Math Bridge · guided foundationsHow does a phone turn gravity into an API number?Let Phoebe trace 9.8 m/s² through a proof mass, spring, and capacitor. Learn the maths

6.5 Learning Objectives

By the end of this chapter, you will be able to:

• Identify common mobile sensor API families and the measurements they expose.
• Explain the permission and secure-context checks that gate mobile sensor access.
• Compare browser-based sensing with native mobile access for an IoT use case.
• Review mobile sensor data for timestamp, units, accuracy, context, and failure states.
• Choose an API path and record the evidence behind that choice.

6.6 Quick Check: API Access Path

6.7 Minimum Viable Understanding

Mobile APIs mediate sensor access; an app never owns the physical sensor directly. Permission, browser support, secure context, and foreground state can all determine whether a reading is available. Even a successful API value needs units, timestamps, accuracy fields, calibration context, and validation before it becomes trustworthy evidence. Browser APIs fit scoped collection, demonstrations, and lightweight field forms. Native APIs become relevant when the project requires deeper platform integration, richer lifecycle control, or access the browser does not expose.

6.8 Prerequisites

Review these chapters first:

• Mobile Sensors Intro: the main phone sensors and how their measurements are interpreted.
• Mobile Phone as a Sensor: the broader role of phones in IoT sensing systems.
• Sensor Applications: Domain Overview: how application context shapes sensor requirements.

6.9 API Access Model

Mobile sensor access usually follows a reviewable sequence. Before requesting a permission, inspect Figure 6.1 to see why the measurement question and support check lead the process: they prevent an available API from being mistaken for a suitable measurement path.

Read Figure 6.1 from the question into the platform-support check and permission request. Only a supported, authorised path reaches the reading stream. Units, timestamp, accuracy, and context then give that stream meaning before a stop condition closes the collection window. The failure branch is equally important: denial and unsupported states remain part of the record. This ordered path connects API selection to the quality evidence and lifecycle boundaries needed by the sensing claim.

6.10 Common Mobile API Families

6.11 Browser Or Native Path

The browser path and native path can both be valid, so the choice should follow the measurement need and review evidence. Before committing to either implementation, inspect Figure 6.2 to compare access and lifecycle constraints rather than treating “native” as an automatic upgrade.

In Figure 6.2, browser sensing fits a narrow, short-lived activity that needs quick access without installation, runs while the page is visible, and uses an API supported by the target devices. The design must still handle permission denial and unsupported states. Native access becomes relevant when the required sensor is not exposed to the browser, when collection must survive app-state changes, or when local storage, notifications, and device services need tighter platform integration. That benefit carries platform-specific maintenance and testing obligations.

Read Figure 6.2 by testing the browser branch first against support, visible-session lifetime, and the narrowness of the claim. Then test the native branch against missing sensor access, background lifecycle, and integration requirements. The deciding path is the first one that satisfies the evidence and operational boundary, not the one that sounds more advanced. This makes the implementation choice part of the measurement record and exposes when a browser page cannot meet the required lifecycle behaviour.

6.12 Data Quality Review

Mobile sensor readings should be reviewed before they are used as evidence. Start with the source—the phone API, external device, or derived signal—and keep its units and observation timestamp attached. Preserve accuracy or uncertainty when the API exposes it, especially for location, and describe how the phone was held, worn, mounted, or positioned. Permission state must distinguish granted, denied, unavailable, and unsupported outcomes. Close the record with the collection window and its stop reason, then add a known movement, known location, comparison reading, or plausibility check as validation evidence.

Common failure states include unsupported APIs, denied permission, stale cached readings, missing accuracy fields, sensor saturation, inconsistent sampling intervals, and readings that change because the phone position changed rather than because the measured condition changed.

6.13 Worked Example: Location-Aware Field Note

Suppose a learner wants a phone-based field note that records a rough location when they inspect a sensor installation.

Measurement question: where was the inspection note created?

API path: browser location API is acceptable if the page is visible, the user grants permission, and the record stores coordinate, accuracy, timestamp, and note text.

Review evidence:

• The user action that requests location is documented.
• Permission denial leaves the note usable with a manual location field.
• The record includes the accuracy field and timestamp.
• The note does not claim exact equipment position if the accuracy field is broad.
• A retest is required if the workflow changes from one-time notes to continuous tracking.

Decision:

The browser path supports a scoped inspection note. It does not support broad movement analysis, unattended tracking, or precise asset mapping unless additional evidence is added.

6.14 Common Mistakes

Do not start with a framework before stating the measurement question, and do not treat permission approval as proof of accuracy. Coordinates without accuracy and time are incomplete; motion values without phone placement are ambiguous. Browser support varies, so denied, unsupported, stale, and interrupted states must remain visible. Narrow phone data cannot justify broad activity, safety, or health claims. Every collection plan also needs an explicit stop condition and a retest trigger so changed access or setup cannot silently inherit an old conclusion.

6.15 A Phone Reports More Sensors Than It Has

A modern phone's sensor API lists a dozen or more sensors, but only some of them are physical chips. Beneath the API sit the real hardware sensors — accelerometer, gyroscope, magnetometer, barometer, light, proximity. Above them sit fused or virtual sensors that no chip produces directly; they are computed in software from the raw ones.

This distinction is not academic. When you read "linear acceleration" or "rotation vector," you are reading the output of an algorithm, not a transducer. Knowing which sensors are raw and which are fused tells you what a value actually means, which inputs it depends on, and therefore how it can fail.

Intuition: the accelerometer is a musician; the "linear acceleration" and "gravity" sensors are a sound engineer splitting that one recording into two tracks. Useful, but only as good as the original recording and the algorithm doing the splitting.

To distinguish a transducer reading from a platform estimate, inspect Figure 6.3 before naming the API output. The diagram exposes the processing stages that sit between physical chips and values such as gravity, linear acceleration, or a rotation vector.

Read Figure 6.3 from the raw accelerometer, gyroscope, magnetometer, and other inputs into preprocessing, then follow their combination through the fusion algorithm. The fused output is an inference whose failure modes include the inputs and the algorithm, not a separate physical chip. Only after that distinction should an application act on the value. This connects API selection to the chapter’s requirement to record signal type and provenance.

That is why an API review should name the signal type instead of only naming the JavaScript, Android, or iOS call. A raw acceleration event tells you what the accelerometer reported in the phone's device frame. A gravity estimate, linear acceleration estimate, or rotation vector tells you what the platform's fusion pipeline inferred after filtering and combining inputs. Those derived values can be the right evidence, but they are not neutral facts from a single chip.

For example, a browser orientation exercise might receive roll, pitch, and yaw-style values. The record should still say whether the page checked permission, whether the phone was mounted or hand-held, whether the platform exposed absolute heading, and whether nearby metal could disturb the magnetometer. Without those notes, two learners can see similar numbers while one is reading a stable mounted phone and the other is reading a phone that has been rotated in the hand.

Overview Knowledge Check

raw accelerometer = gravity + linear acceleration
  gravity sensor            -> the ~9.81 m/s^2 gravity component
  linear-acceleration sensor -> the motion component (gravity removed)
Axes are device-fixed: x = right, y = toward top, z = out of screen (right-handed)

Phone lying flat, raw accelerometer reads:
   (ax, ay, az) = (0.2, 0.1, 9.9) m/s^2

Gravity here is about (0, 0, 9.81). Subtract it:
  linear accel = (0.2, 0.1, 9.9 - 9.81) = (0.2, 0.1, 0.09)

The magnitude is ~0.24 m/s^2 -> essentially at rest.
The big 9.9 was gravity, NOT motion. Reading raw
acceleration as "movement" would be a beginner error;
the fused linear-acceleration sensor makes it obvious.

state:        x = [ w  phi ]^T        (gyro rate, rotation angle)
transition:   A = [ 1  -dt ]            (propagate angle using gyro rate)
              [ 0    1 ]
observation:  H = [ 1   0 ]             (correct only the rate term,
                                          against the accelerometer's
noisy-but-driftless angle)