SensorManagerService

While the framework exposes SensorManager, the heavy lifting for sensor hardware interaction occurs below the Java layer in the native SensorService (often referred to interchangeably as SensorManagerService in architecture discussions), written primarily in C++. It manages accelerometers, gyroscopes, light sensors, and more.

Sensor Registration and Event Delivery

Apps interact with SensorManager to register an EventListener. This request traverses through JNI to SensorService in the system_server process.

1. Initialization: SensorService queries the Sensors HAL (ISensors.hal) to get a list of available physical and virtual sensors.
2. Connection: When an app registers for a sensor, SensorService creates a SensorEventConnection for that specific client.
3. Activation: If the requested sensor is asleep, SensorService commands the HAL to activate it using activate(handle, true).

SensorEventQueue

Transferring high-frequency sensor data (like a 200Hz gyroscope stream) over Binder for every single event would cause massive CPU overhead. To solve this, SensorService uses an ASensorEventQueue backed by a BitTube.

A BitTube is a fast, unidirectional IPC mechanism built on top of Unix domain sockets (specifically socketpair). When the HAL produces a batch of sensors_event_t structs, SensorService writes them into the BitTube. The client app's SensorEventQueue (running in the app's process) polls the other end of the socket, reading the events efficiently without involving Binder transactions.

// Native snippet demonstrating writing to the BitTube
ssize_t size = mChannel->write(events, numEvents * sizeof(sensors_event_t));
if (size < 0) {
    ALOGE("Failed to write to sensor channel");
}

Sensor Fusion

Not all sensors returned by SensorService map 1:1 to physical hardware. Virtual sensors, known as Sensor Fusion, combine data from multiple physical sensors to provide higher-level insights.

For example, the TYPE_ROTATION_VECTOR sensor fuses data from the accelerometer, gyroscope, and magnetometer using a Kalman filter to determine the device's precise orientation in 3D space. While modern devices often perform this fusion in a low-power hardware Sensor Hub to save battery, SensorService contains fallback software fusion algorithms.

Batch/FIFO Sensor Delivery

To conserve battery, Android supports sensor batching. Instead of waking the CPU for every sensor event, the hardware accumulates events in a hardware FIFO buffer.

When an app requests a sensor, it can specify a maxReportLatencyUs. The HAL will collect events silently until the FIFO is full or the latency timer expires. At that point, the hardware triggers a hardware interrupt, waking the Application Processor (AP) to flush the FIFO and deliver the burst of events through the BitTube to the app.

You can inspect the active sensor connections and their requested rates using:

adb shell dumpsys sensorservice