8  Mobile Sensor APIs

Keywords

mobile sensor APIs, smartphone sensors, web sensor API, geolocation API, device motion API, mobile sensing evidence, legacy mobile web, WAP, WML

8.1 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.

8.2 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

Phoebe’s Why

An accelerometer API never touches acceleration directly. Inside the chip sits a microscopic proof mass on springs; when the phone accelerates – or simply sits still in Earth’s gravity, which pushes up on the mass exactly as hard as an upward acceleration would – the mass shifts by a tiny distance relative to the frame around it. That distance is what the chip can actually sense, through a matching change in capacitance between the mass and fixed plates on either side. Everything the API hands to JavaScript or Android – the “9.8 m/s² along one axis” this chapter’s own resting-phone example reports – is the output of a chain that first measures a capacitance, infers a displacement from it, and only then multiplies by a spring constant to recover a force and, through mass, an acceleration. The number looks direct; the physics is not.

The Derivation

Newton’s second law and the restoring spring set the proof mass’s displacement for a given acceleration:

\[F = ma = kx \quad\Rightarrow\quad x = \frac{ma}{k}\]

A parallel-plate capacitor’s value depends on the same gap the mass is displacing:

\[C = \frac{\varepsilon_0 A}{d}\]

so a differential pair straddling the rest position turns a tiny \(x\) into a measurable \(\Delta C\). The chip – and, one layer up, the API – inverts that whole chain to report acceleration:

\[a = \frac{k}{m}\,x, \qquad x \leftarrow \Delta C(A,\varepsilon_0,d_0)\]

Worked Numbers: This Chapter’s Own Resting-Phone Reading

Illustrative, catalog-typical order-of-magnitude MEMS values (proof mass \(m\approx0.1\ \mu\text{g}\), spring constant \(k\approx1\) N/m, plate area \(A\approx200\ \mu\text{m}\times100\ \mu\text{m}\), rest gap \(d_0\approx2\ \mu\text{m}\) – real parts vary by vendor and are not published per-chip):

• Force at this chapter’s own \(9.8\ \mathrm{m/s^2}\): \(F=ma=1\times10^{-10}\times9.8=9.80\times10^{-10}\) N.
• Proof-mass displacement: \(x=F/k=9.80\times10^{-10}/1=9.80\times10^{-10}\) m \(\approx0.980\) nm – smaller than a strand of DNA is wide.
• Nominal capacitance: \(C_0=\varepsilon_0A/d_0=(8.854\times10^{-12}\times2.0\times10^{-8})/(2.0\times10^{-6})=88.5\) fF.
• Differential change at that displacement: \(\Delta C\approx0.0868\) fF, about \(0.098\%\) of \(C_0\) – a change this small is why real chips use many interleaved comb fingers instead of one plate pair, multiplying the sensed area rather than trying to resolve a single tiny capacitor directly.
• The inversion, stated plainly: the chip measures that sub-attofarad \(\Delta C\), recovers \(x\) from the capacitor geometry, then reports \(a=kx/m=9.8\ \mathrm{m/s^2}\) – which is exactly why this chapter’s own knowledge check calls a resting phone’s reading “gravity in the raw accelerometer, not hard motion”: the proof mass is displaced by gravity’s pull just as it would be by an equivalent acceleration, and the sensor has no way to tell the two apart from a single reading.

8.3 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.

8.4 Quick Check: API Access Path

8.5 Minimum Viable Understanding

1. Mobile APIs mediate sensor access; the app never owns the physical sensor directly.
2. Permission, browser support, secure context, and foreground state can all affect whether a reading is available.
3. API data is not automatically trustworthy; it still needs units, timestamps, accuracy fields, calibration context, and validation checks.
4. Browser APIs are useful for scoped collection, demonstrations, and lightweight field forms.
5. Native APIs are considered when the project needs deeper platform integration, richer lifecycle control, or access not exposed by the browser.

8.6 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.

8.7 API Access Model

Mobile sensor access usually follows a reviewable sequence:

1. Define the measurement question.
2. Check whether the API exists in the target platform.
3. Request permission in response to a user action when required.
4. Start the reading or event stream.
5. Attach units, timestamp, accuracy, and context.
6. Stop collection when the measurement window ends.
7. Record failures, denials, and unsupported states.

Figure 8.1: Mobile sensor API access flow: measurement question, support check, permission, reading stream, quality check, stop condition, and record failures.

Use Figure 8.1 as a checklist. A mobile sensing plan is incomplete if it only names an API but does not explain permission, quality evidence, and stop conditions.

8.8 Common Mobile API Families

8.8.1 Location

Location APIs can provide position estimates and related metadata such as accuracy and timestamp. They are useful when the application decision depends on place, movement path, or proximity to a defined area.

Review questions:

• Does the task need a position fix, a movement trace, or only a coarse location category?
• Is the accuracy field recorded with the coordinate?
• Is the reading recent enough for the decision?
• What happens when the user denies permission or the position is unavailable?
• Is the claim limited to the available position evidence?

8.8.2 Motion And Orientation

Motion and orientation APIs may expose acceleration, rotation rate, and device orientation events depending on platform support. They are useful for activity cues, tilt, gesture review, and movement context.

Review questions:

• Which axes are recorded and in what units?
• Does the plan distinguish gravity, linear acceleration, and orientation?
• Is the sampling interval recorded or estimated?
• Is the phone placement described, such as hand-held, pocket, mounted, or table?
• What validation reading or reference movement shows that the signal is plausible?

8.8.3 Camera And Microphone

Camera and microphone APIs can support visual or audio sensing, but they carry stronger privacy and context concerns. The review should stay narrow: what signal is being collected, why it is needed, how the user grants access, and what is excluded from the claim.

Review questions:

• Is the application collecting a raw stream, a derived feature, or a one-time sample?
• Is the user-facing permission prompt aligned with the actual collection?
• Are background or passive collection assumptions avoided unless the platform path supports them?
• Is the stored data minimized to what the measurement question requires?

8.8.4 Nearby Devices And External Sensors

Some mobile platforms allow apps or browsers to communicate with nearby devices such as BLE peripherals. This path is useful when the phone is a gateway for an external sensor rather than the sensor itself.

Review questions:

• Which external device is in scope?
• Which service or data characteristic is required?
• How is pairing, permission, and disconnect handling documented?
• How does the app distinguish phone sensor data from external sensor data?

8.9 Browser Or Native Path

The browser path and native path both can be valid. The right choice depends on the measurement need and review evidence.

Browser-based sensing is often a good fit when:

• Learners need quick access without installing an app.
• The activity happens while the page is visible and active.
• The API exists on the target devices.
• The project can handle permission denial and unsupported states.
• The data claim is narrow and short-lived.

Native mobile access is often reviewed when:

• The project needs platform-specific lifecycle behavior.
• The required sensor is not exposed to the browser.
• The app needs stronger integration with local storage, notifications, or device services.
• The data collection plan must keep working through app state changes.
• The project team can maintain platform-specific behavior and testing.

Figure 8.2: Decision map comparing the browser sensing path and the native app path by when each one is a good fit.

Use Figure 8.2 to justify the path. Do not choose a native app just because it sounds more advanced, and do not choose a browser page if the required lifecycle behavior is outside browser support.

8.9.1 Legacy Mobile Web Protocols

Older mobile-web stacks such as Wireless Application Protocol (WAP) and Wireless Markup Language (WML) are useful mainly as historical architecture context. WAP 1.x commonly relied on a gateway that translated mobile-friendly markup and acted as a proxy between a small phone browser and web servers. WAP 2.0 moved closer to normal Internet protocols with IP, TCP, HTTP, XHTML Mobile Profile, and CSS support, so newer devices could communicate more directly with web services.

For an IoT review, treat a WAP or WAP2 path as a legacy integration boundary, not as evidence that a modern phone sensor API exists. Record whether a gateway or proxy can inject or observe phone number, location, billing, or handset information; where end-to-end TLS actually terminates; what markup and browser capabilities are available; and why the design cannot use current browser APIs or a native app instead. The lesson is the same as for sensor APIs: the access path decides the permission, security, and evidence record.

8.10 Data Quality Review

Mobile sensor readings should be reviewed before they are used as evidence.

Check that each record includes:

• Source: which phone API, external device, or derived signal produced the reading.
• Units: coordinate units, acceleration units, angular units, light units, or media format.
• Timestamp: when the reading was observed or received.
• Accuracy or uncertainty: when the API exposes it, especially for location.
• Placement: how the phone was held, worn, mounted, or positioned.
• Permission state: granted, denied, unavailable, or unsupported.
• Collection window: start, stop, and reason for stopping.
• Validation evidence: a known movement, known location, comparison reading, or plausibility check.

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.

8.11 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.

8.12 Common Mistakes

• Starting with a framework choice before stating the measurement question.
• Treating permission approval as proof that the data is accurate.
• Recording coordinates without the accuracy field or timestamp.
• Forgetting that phone placement changes motion readings.
• Assuming every browser supports the same sensor APIs.
• Ignoring denied, unsupported, stale, or interrupted reading states.
• Making broad activity, safety, or health claims from narrow phone sensor data.
• Leaving stop conditions and retest triggers out of the review record.

8.13 Knowledge Check

8.14 Matching Quiz

8.15 Ordering Quiz

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.

Mobile sensor APIs often expose a processed value, not just a raw chip reading. Review the raw inputs, preprocessing, fusion step, fused output, and action separately.

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

Splitting Gravity, and Minding the Frame

A raw accelerometer measures gravity plus motion together. The fused sensors separate them:

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)

Worked example: is the phone actually moving?

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.

One more trap hides in the axes: readings are in the device frame. To know motion in the world (north, up), you must rotate device-frame vectors using the orientation, or the same physical push reads differently just because the phone is held at an angle.

Apply that frame rule to the API choice. If the lab only asks, "did the phone tilt after the user tapped start?", device-frame orientation may be enough. If the lab asks, "did the user move north along a route?", device-frame acceleration alone is not enough; the app needs orientation, timestamps, drift controls, and usually location or another reference. The measurement question decides how much platform machinery must be trusted.

A useful review record therefore has three rows: the API requested, the physical or fused quantity returned, and the quality field used to accept or reject the reading. For location this may be accuracy and age. For motion it may be placement, sampling interval, and a known movement check. For media it may be permission state, collection window, and whether only derived features were stored. If one of those rows is missing, the result may still be a demo, but it is not yet reliable evidence.

Practitioner Knowledge Check

Batching, Sensor Hubs, and Inherited Weaknesses

How events reach your code — and what the fused values depend on — decides both battery life and correctness.

Mobile platforms do not usually wake the main processor for every tiny sensor change. A low-power sensor hub can sample physical sensors, buffer events, run simple fusion, and deliver a batch later. That saves battery, but it changes how software should interpret time. The event timestamp is the measurement time; the callback time is only when the operating system delivered the batch. Treating callback arrival as the sampling interval creates drift in integration, speed estimates, and windowed activity features.

Batching via a sensor hub

A low-power sensor hub buffers events in a hardware FIFO and delivers them in batches, letting the main processor sleep between deliveries. For continuous sensing this is a large battery win, traded against added latency.

Trust timestamps, not assumed rates

You request a rate, but delivery is best-effort and batched, so intervals jitter. Integrate and window using each event's own timestamp, never a hard-coded dt, or accumulated timing error corrupts results.

Fused sensors inherit input flaws

The rotation vector needs a calibrated magnetometer for absolute heading; near metal or magnets its heading drifts. The game rotation vector drops the magnetometer for immunity, but then gives only relative heading.

Availability is not guaranteed

Budget phones may lack a gyroscope or barometer, and magnetometers need figure-eight (hard-iron/soft-iron) calibration. Query what exists and its calibration state; never assume every sensor is present and trimmed.

Fused sensors also inherit the weakest input in the pipeline. A rotation vector can be excellent when accelerometer, gyroscope, and magnetometer data are stable. It can be misleading near a laptop hinge, speaker magnet, vehicle frame, or steel bench. A game rotation vector may avoid magnetic heading error by dropping the magnetometer, but then it gives relative heading and can drift over time. The API name alone does not tell the whole truth; the dependency list and operating context do.

The through-line: a phone sensor value arrives through a power-saving pipeline and, if fused, through an algorithm with its own dependencies. Reading it well means using event timestamps, rotating into the frame you care about, and knowing which raw sensors a fused value leans on so you can predict where it will drift. The review record should therefore include the requested rate, observed timestamp pattern, device placement, API availability, calibration state when exposed, and the fallback behavior when one dependency is missing.

Under-the-Hood Knowledge Check

8.16 Summary

Mobile sensor APIs turn phones into useful IoT sensing tools when the API choice is tied to a clear measurement question. Browser APIs are valuable for visible, permissioned, scoped collection. Native mobile paths are considered when the measurement requires platform behavior or sensor access that the browser path cannot support.

A clean review record names the API, permission state, units, timestamp, accuracy or uncertainty, phone placement, validation evidence, failure handling, exclusions, and retest trigger.

8.17 Key Takeaway

Mobile phone APIs are sensor interfaces with permissions, sampling limits, privacy implications, browser support, and device-variation constraints.

8.18 Concept Relationships

• Measurement question determines which phone signal matters.
• API family exposes the signal through a controlled access path.
• Permission state determines whether collection can proceed.
• Platform support defines which devices can run the feature.
• Data quality evidence explains what the reading can support.
• Lifecycle choice determines whether browser or native access is appropriate.
• Decision record preserves exclusions, failure handling, and retest triggers.

8.19 What’s Next

Continue with:

• Participatory Sensing: review phone-based sensing when many users contribute data.
• Mobile Web Sensor Labs: practice browser-based mobile sensor workflows.
• Mobile PWA & Audio Labs: apply offline and audio-oriented mobile sensing patterns.
• Mobile Sensors Assessment: check your understanding of phone sensor choices.

Previous: Mobile Sensors Intro

Return to: Mobile Phone as a Sensor